Hi, I recognized something strange and wanted to find out if this is intended or not: The constructors of global object instances (allocated outside any function) seem to be called during compilation of the script already rather than during an outside call to the Execute method of the script context. This actually causes problems in my application scenario (as described below) and I wanted to ask if this is going to be changed (if possible at all) or if I will have to change my approach. Here's my problem: My application compiles the script(or rather scripts since I now use the ScriptBuilder that allows for #include to be used) from within the main UI thread. If everything works fine then the UI thread starts a worker thread (let's call it 'scripting thread' here) which calls the Execute() method of the script context. There are registered functions that can be performed by the scripting thread on its own, no problems here. However, there are other registered functions that send messages to the UI thread instead which does the actual work. Once the UI thread has finished executing the corresponding function it sets an event the scripting thread is waiting for. Certainly this concept breaks if the UI thread is busy compiling the script and if one of the script classes' C'tors performs a call to such a function already during compilation: The UI thread sends a message to itself and will get stuck while waiting for the event to be set. Certainly I could go and move the compilation to the scripting thread, too. It's just quite a bit of re-work and regression testing I would have to face and I wouldn't do that if my observation is not an intended behaviour... Regards

Thanks very much, that's great!

Cheers...