I'm aware there is an idle timer and event in Windows that we can hook onto.
Is there an event for the opposite of this?
i.e. i.e. an event that fires when there is activity on one of the HID devices?
I'm aware of GetLastInputState, but that is polling.
Global hooking is also an overkill.
My interest is in that the monitor switches on when the keyboard/mouse has activity, is there a way to hook into that?
Thank you.
Related
tldr Why don't I receive PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMESUSPEND, and PBT_APMSUSPEND as the payload to service events of type SERVICE_ACCEPT_POWEREVENT?
I'm trying to detect when a windows device as woken back up from sleep. I have a constellation of processes that interact via IPC, which includes both UI applications with an event handler function provided to RegisterClassEx and services using RegisterServiceCtrlHandlerExW.
My preference is to receive these events in a service. My understanding is that I can get SERVICE_ACCEPT_POWEREVENT in dwControlsAccepted, and can then distinguish specific kinds of power event by looking at the dwEventType parameter, as per these docs https://learn.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex. However, I only ever receive PBT_APMPOWERSTATUSCHANGE, corresponding to fiddling with the power cord on the laptop. I expected to also receive some combination of PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMESUSPEND, and PBT_APMSUSPEND.
When testing on the UI side, I do get WM_POWERBROADCAST events of any kind. Obviously I've missed some part of setup there. Again, the process that actually needs this info is a service, so I would have to IPC the event to a service if this is what ended up working.
For full credit, I also experimented with SERVICE_CONTROL_CONTINUE and SERVICE_CONTROL_PAUSE (enabled via SERVICE_ACCEPT_PAUSE_CONTINUE), but never receive these events at all. I had expected those to correlate with sleeping the laptop but apparently not.
My app needs to keep receiving data from BLE devices when the user hits the side button and "kill" the app or it simply run in sleep mode. How can I save the state of my app and his listeners so I can keep receiving the data?
I've read some approaches but I want to know what is the one more indicate.
Launch a service as the center of my app?
Launch pendingIntent so the user can re-enter the app after sleep mode? In this case how can I keep my listeners for receiving data?(service?)
Your app can implement a WearableListenerService; framework will instantiate it when you have a message/data and calls its appropriate callbacks with the message or data that has arrived.
The solution I've implemented was the first one!
I've completely detached the center of my app from the UI activity and implemented a service as the "brain". The service and the activity are in constant communication through a broadcast channel. When the smartwatch is in sleep mode I launch a pendindIntent (card) so the system can recover to the main activity.
That's how I've done it, hope it helps someone else!
I am using global event listener in my application. The event capture perfectly works in my code. The problem is the event seems to be fire multiple time. I have followed this tutorial link.
If your app is listening to global events generated by system, then these events may fire several times according to conditions you do not know. On my experience to get a univocal signal from the system I had to analyze a sequence of global events and the signal was recognized as received only when this sequence of events occured one after another in expected way.
If your app is listening to global events generated by your application, then it is fully under your control. Check your code that fires global events. Use EventLogger to log every moment when you fire and when you receive fired event. Then inspect your log to find out what is going on. Seems that your app fires the global event more times than expected.
I've got no idea how window hooks work at the "system level". MSDN only touches what's going on very briefly:
A hook is a point in the system message-handling mechanism where an
application can install a subroutine to monitor the message traffic in
the system and process certain types of messages before they reach the
target window procedure.
My best guess is something like below:
Before each message is added to the message queue for a window, it'll first send the message to the global/local hooks, which may do something, depending on their hook procedures. After all global hooks and local hooks, the message is finally added to the window message queue.
However, MSDN says that for some of the types of hooks, it will monitor events, notifications etc.
An example is the WH_MOUSE_LL hook:
Installs a hook procedure that monitors low-level mouse
input events. For more information, see the LowLevelMouseProc hook
procedure.
When they say events, are we talking window messages, or do they mean something else?
Am I all wrong?
Yes, this is a mechanism for windows messages, you can process this data (messages) before they reach target window procedure (message loop).
If you want hook other process windows you can simply do this in DLL, and use DLL injection for inject your library to other process.
I am in support of an application that involves serial port communication.
There are 32 MSComm controls (control array) on the form.
Suppose data arrived at one of the com port while some other code of the same thread is running (say database access etc.). will the Oncomm event procedure queed for execution or the current execution point is queed and Oncomm event handler is executed?
VB6 is single threaded. Basically (excepting ActiveX controls for a second) there's just the GUI thread.
It's sitting there waiting for an event. You get data, so it enters the event handler for your MSComm control and starts doing some database access. It blocks waiting for the database to respond. Another MSComm control receives data and fires off an event. This event just sits in the Windows event queue. The GUI thread has to exit the event handler before it can process the other MSComm event.
Of course, in the middle of an event handler you can call DoEvents. I highly suggest you rarely, if ever, do that. It's the source of many difficult bugs, in my experience.
There are ways to queue the long running database work onto a background thread (using a call into .NET managed code, in that case). That will allow your event handler code to continue almost immediately without blocking, allowing it to process the next message. To my knowledge, there's no native VB6 way to do that.