Subject: Deferred events and ugly pointers [was: Win32 & timer]
From: Mike Nordell (tamlin@algonet.se)
Date: Tue Nov 14 2000 - 08:51:09 CST
Martin Sevior wrote:
> On Sun, 12 Nov 2000, Sam TH wrote:
> > This has to do with the whole idea of modeless dialogs, which I actually
> > like quite a lot.
They are not something I would want to be without. But there's nothing that
can't be improved. :-)
> This is the reason in a nutshell. The preview window displays the
> characteristics of the list the cursor currently resides within. When the
> cursor moves rather than setup a listener to the cursor motion change I
> setup a timer to update the dialog if the cursor has moved.
>
> I think that doing things this way (with the timer) is a defensible way of
> working around not running a background thread. Tacking a list update to
> every cursor motion could really slow down performance.
That seems like a good reason. But, since it's not multi-threaded, it still
(at some point in time) interrupts the "main" thread to update the dialog.
Well, even if it was multi-threaded it would need to lock the main data to
prevent the input thread from changing stuff while the dialog did read it.
Since this "idiom" is used in more than one dialog, I was playing with the
idea of moving this behaviour into a more self-contained entity. A
deferred/bundling event generator.
I use the lists dlg as example here.
The lists dlg subscribes to deferred/bundled events of (at least) type
AV_CHG_MOTION and AV_CHG_FILENAME.
The main execution context (the one handling cursor movements and so on)
fire deferred events like "OK, we have made a change to the document, and we
had no input for n ms. It's time we fire an event". When this time comes, it
only broadcasts the last change event (of each specific type).
I see some benefits with this approach.
The mechanism could be implemented in XP code.
The code to do this only exists in one place.
The code is giving the explicit promise that it is run in the context of the
document the update belongs to, and that the document can't change for the
duration of this callback.
The update messages will only be broadcast in case the document really have
changed (current implementation polls at fixed interval).
The possible drawback I see is that with the current implementation every
modeless dialog can itself decide its update frequency. With my proposed
implementation this time will have to be the same for all listeners to this
deferred/bundling event generator (not really true, but let's assume it for
simplicity). Would this be a problem?
> However Mike, I'm surprised you haven't yet bitterly complained about the
> really ugly way I construct the unique (void *) pointers needed for the
> fake list elements used in the preview. Feel free to explain the right way
> to do this :-) Remember every pointer must be unique.
I just haven't come to see it yet. :-)
If the code is the one in AP_Dialog_Lists::generateFakeLabels(), the first
thing I noticed was that we apparently have an array of four app objects.
Also, they are compatible with the type PL_StruxDocHandle. That was
something of a surprise to me! :-)
However, if the only reason to do this is to get unique pointers (that are
never dereferenced I'd hope), what about
m_pFakeSdh[i] = reinterpret_cast<PL_StruxDocHandle>(new char);
? :-)
/Mike - please don't cc
This archive was generated by hypermail 2b25 : Tue Nov 14 2000 - 08:51:58 CST