Jeremy White wrote:
So in my last analysis I missed the 3rd way not to get the OEM event
fired: returning 1 from the NEM handler.
I personally don't see anything wrong with this logic, so long as you
believe that returning 1 from an event handler means 'pass the event
to the next handler', regardless of whether this is another event
handler, or defwindowproc. Although I note that DoHook doesn't
implement such logic if you have multiple hooks for the same event.
I see your point. The problem is that most handlers don't explicitly
return anything, which means we would always return 1. This in turn
forces OEM logic to be run for any NEM event created by SetEvent.
But only if the object was created expecting to use OEM, so that the OEM
flag is set, and as I have pointed out there are a number of way to
ensure the OEM flag is not set at object creation time; if you do this,
then OEM events are never looked for.
So, we come back to whether the SetEvent logic is right. Currently
SetEvent replaces any NEM coderef for the event passed, or creates one
if there wasn't one there before, and ensures that the NEM flag is
set. As in my previous email, the only alternative I see is to get
SetEvent to choke if the NEM flag is not set.
I would argue that the logic in SetEvent is wrong. My rational is as
follows:
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.
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.
I guess I'm arguing that what's there is correct. Comments?
Regards,
Rob.
