Jeremy White wrote:
There are two main reasons to use SetEvent:
1) To add NEM events to windows/controls after they have been created
- perhaps by a 3rd party tool (such as Loft) which isn't NEM aware.
2) To change the event handlers during runtime.
In both cases, the expectation should be that the control is now
running under NEM only - just as if the control was created with NEM
event handlers in the first place.
I don't follow this logical step. If a tool that is not NEM aware
generates code, that presumably relies on OEM events being fired, and
then I add so code that uses SetEvent(), your proposal would stop any
existing OEM event handlers from being fired, even if for a different
event.
My poor explanation. The tool wouldn't be responsible for generating the
event handlers, just creating the window. For example, if you wanted to
use Loft (or any GUI builder) and NEM, then you would use Loft to create
the window and add the events later. Basically, I would have thought it
would be valid to separate the step of creating a window, and
associating events to it?
OK, I'm with you now.
If these assumptions are correct - and I could be wrong - shouldn't
the approach be to simply turn off the OEM for a control that uses
SetEvent?
Even if the object was created with -eventmodel => 'both' ?
I can't see that that is the right approach. If the object is created
to use OEM, then SetEvent can have no idea whether there are actually
OEM event handlers that need to be called. It does, however, know
that after it is called there is at least one NEM handler to call. So
all it can do is turn on the NEM flag. If you don't want OEM events
fired, then ensure they are turned off when the object is created by
setting at least one NEM handle, or by using the -eventmodel option.
Ok - if this is correct, then adding an event with SetEvent, shouldn't
first call the NEM handler and still call the OEM handler for a single
event. This is a bug. Returning 1 from the added NEM handler to stop
this happening would be none standard.
I guess I'm arguing that what's there is correct. Comments?
I can understand your point of view - and to some extent I agree with
it. The issue is how to control the event model of a object post it's
creation - there is no way to do this at the moment. I would have
thought that using SetEvent would have explicitly changed event modes.
As a compromise how about this:
* SetEvent logic stays the same
OK
* The bug where 2 events are called for the same event when using
SetEvent is fixed
I don't know how to fix this. Within the event handler we don't know
whether the OEM and NEM flags have been set explicitly or not. Are you
suggesting that we shouldn't be testing the return value from the NEM
handler before looking for the OEM handler?
* A new method is added, which when called forces the object into NEM mode
(untried) Doesn't
$window->Change( -eventmodel => 'byref' );
already do this?
Regards,
Rob.
