Hi Dave, > Thanks for that Walter, I had no idea this was possible.
No problem ;) > However, what it has yielded doesn't help me much which is certainly > down to my ignorance. With your advice I got to the point where my 2nd > instance of Delphi had gone into CPU eating mode but I'd hit no > exceptions in the first. When I hit Program Pause in the first Delphi > it did indeed stop the second and presented me with the CPU window. > Stepping through this I found that it was indeed in a tight loop (5051F9 > - 5052D8). The bad news is that all I see there are a bunch of > addresses and assembler (?) - I don't know how to get from that to some > Pascal source where I may have some hope of nailing the problem. Hmm... well. That's unfortunate, as it implies that the code it gets stuck in apparently doesn't have debug information included. If you have the source of all your third party components, then the next step would be to recompile and reinstall all the component packages with all debug information turned on, and then retry the experiment, to see if this will coax pascal source location out for you. Also was there anything interesting on the call stack when you paused the application? Another approach one might try is to see if you can get the behaviour to re-occur inside a test harnass. The idea is to write an app which "fakes" just enough of the delphi state of the components (more or less dsDesignTime in ComponentState) to try and reproduce the bad behaviour in a normal debuggable application. HTH Walter ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [EMAIL PROTECTED] Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/delphi-en/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
