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?
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?
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
* The bug where 2 events are called for the same event when using SetEvent
is fixed
* A new method is added, which when called forces the object into NEM mode
Cheers,
jez.
