Okay, so I set about a variant of approach 2, and I've hit another snag. Perhaps that comes from trying to do everything in the plugin. This one should be a quick question :-)
I have a HIDManager class, which manages all connections to DirectInput and provides devices and device elements when requested. My approach is to add two functions to this class: RegisterWindowForHIDEvents(inWindowHandle as integer) UnregisterWindowForHIDEvents(inWindowHandle as integer) The register function stores the current WindowProc pointer for the window, and installs its own WindowProc instead. What I need to do now is to make the old WindowProc pointer available to the new WindowProc, so that it can pass on any unwanted events to the usual RB window procedure. Here's my dilemma: how do I store these old pointers in a global way such that they may be retrieved by the custom WindowProc? (It could then identify the right one to used based on the window handle passed in.) If I store them in the HIDManager instance, I have no way to retrieve the instance from within the WindowProc. Is there anywhere else (within my plugin code) that they could be stored and be globally available? Dave. > From: Dave Addey <[EMAIL PROTECTED]> > Reply-To: REALbasic Plugins <[email protected]> > Date: Wed, 26 Apr 2006 13:10:14 +0100 > To: REALbasic Plugins <[email protected]> > Conversation: Callbacks and events on Windows > Subject: Re: Callbacks and events on Windows > >> Approach #1 is not gonna fly- you can't call into REALbasic code from that >> other thread. Bad Things Will Happen. >> >> Approach #2 is probably heading in the right direction. >> >> I must admit I've never attempted to do any HID work on Windows, so I don't >> know how it passes events to the application. What API are you using? >> >> You could create your own hidden offscreen window using the Win32 APIs and >> catch the HID events using your own WndProc. > > Hi James, > > Thanks for the advice! > > I wondered if that might be the case for Approach 1. Bah. Thanks for the > confirmation. I've used background threads in plugins before, but only > where there's no interaction with RB, so I wondered if this might be the > case. > > I'm using DirectInput for the HID support on Windows. It seems to *nearly* > do everything I need, with the possible exception of support for device > elements with big data values (i.e. "more than a DWORD"), which is > unfortunately the case for a lot of interesting devices. I think this > should be possible to implement, however, as soon as my Windows Driver > Development Kit CD turns up. I've got device and device element discovery, > information gathering, and event polling all working nicely on Win32 and > MachO. But the killer feature is to be able to be notified when events > arrive on Win32 too. > > So approach 2 it is, then. I'm very intrigued by your suggestion of > creating a hidden offscreen window. Would this window need to be frontmost > window to receive events? I've not really got my head round Windows' > reliance on windows (if you see what I mean) in order to receive events in a > GUI application. Are the concepts of 'my application is active' and 'one of > my windows is frontmost' one and the same thing in Win32? > > I know I can set the cooperative level for a device: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/ > IDirectInputDevice8__SetCooperativeLevel.asp > > ...and the most useful scenario is when the application is frontmost. But > what if the app has many windows? How does this affect my use of a window > as the event handler? > > The hidden offscreen window approach is definitely worth exploring. Any > pointers as to how one would go about doing this? Sorry to ask - but this > particular part of it is all new to me... > > Thanks again for the help, > > Dave. > > > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives of this list here: > <http://support.realsoftware.com/listarchives/lists.html> _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
