Hi Paul,

some SWAG's:

Working with the VFP GUI sometimes it is necessary to "force the issue".
Even simple "doevents" don't always get the job done - in elements bound to a control source just accessing the control source with a

luDummy = Control.Source

sometimes clears things up. To be sure I'ld insert a

Wait Window "lets just pray" + str(set("datasession")) + alias() timeout 1

into my debugging attempts before changing the work area. Gremlins...

>This code works fine when compiled as an EXE, it works fine inside of the VFP development environment, and works fine when I call this APP from the VFP command prompt (eg. DO MyApp.APP). It doesn't work when being called from within our EXE which calls this APP.

When it is running in the exe, is the form included in the exe or the whole app ? When it is NOT running in the app (called by the exe), is the form included both in the exe and the app ? VFP is fragile if it encounters duplicate names, at least for functions and programs [verified], and class names [hearsay from a usually very reliable coworker]. Might be a similar mechanism working for forms, even if the compile/version status is identical.

What happens if you build MyApp.Exe and call this from VFP or run not from the IDE ? What happens if your main.Exe calls it via "Do MyApp.Exe" ?

You would probably have mentioned it:
I remember getting unexpected behaviour with nodefault when experimenting with Bindevent().

HTH

thomas