>>So where do we download it? ;-) I want to download that too.;-)
Regards Leigh http://www.salenz.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Brennan Sent: Saturday, 30 July 2005 7:07 p.m. To: 'NZ Borland Developers Group - Delphi List' Subject: RE: [DUG] Debugging on TS So where do we download it? ;-) I take it the standard windows events (ie Mouse Down, Mouse Up, Mouse Click) are still occurring but your code attached to these events just puts the instruction to run something into your delayed events handler (if appropriate). Or have I got this wrong - have you somehow replaced/augmented the standard windows messages too? David. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Max Nilson Sent: Friday, 29 July 2005 9:36 p.m. To: 'NZ Borland Developers Group - Delphi List' Subject: RE: [DUG] Debugging on TS Stephen Barker suggested: > Maybe you could change the btnclick to not close the form but > post a wm_close message to it? After Rohit complained: > > One of the major flaws in windoze... where the btnclick > > closes a form the btnup event can go to some other form. Another variation on this theme is that you have two related events on the queue, call them event1 and event2, and event2 relies on event1 having been fully handled. If you event get a situation where the processing for event1 is reentrant into ProcessMessages you can get event2 being processed before event1 has completed. Instant nasty stuff happens. After having this problem in so many different guises in our application I finally gave up and created a delayed event handler. You send place a class on the delayed event list and eventually when the application is idle and at the highest level process message loop it take the event class of the list and processes it. I uses classes on the list so that I can create various different specialisations that can contain enough context to know what to do. This works around the problem of only having 64bits of user data in a PostMessage/SendMessage call (that is the total of wParam and lParam). And it provides for type safe parameters into the delayed events, rather than having to do weird casting on the wParam and lParam. This totally solved the issue of Windows event dispatching destroying forms and components, but it does leave open the window for an event related to an destroyed object to be sitting on the list waiting for its turn. So the delay event mechanism also handles various notifications for the different classes of objects in the list, so that events for any object being destroyed are removed before execution. After getting that sort I now have a bullet proof delayed event mechanism, and all of our buttons, speed buttons, other clickable objects pass their actions through the delayed event handler. This has removed all of the AV's, exceptions and other timing wierdness from the application by making the events serialised and predictable, and debuggable. Something that can't be seid for the Windows event queue. Cheers, Max. _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
