[DUG] Debugging on TS

[Leigh Wanstead]

>>So where do we download it? ;-)

I want to download that too.;-)

Regards
Leigh
http://www.salenz.com

-----Original Message-----
From: delphi-bounces at ns3.123.co.nz
[mailto:delphi-bounces at ns3.123.co.nz]On 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: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz] 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
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi

_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi