I've registered my program to the WIA_EVENT_SCAN_IMAGE event. Ideally, when I press the physical scan button on my scanner, my program will begin scanning without need for prompt.
However, because other programs like Epson Scan might be installed, what ends up happening is that Epson Scan may start before my program can start scanning, and seems to claim use of the device before my program can.
Ideally, I'd like to unregister all other callbacks on load, and reregister them on closing.
Related
I am trying to run a .PS1 script on my Windows 11 Surface device every time the computer connects to a Surface Dock. I am attempting to figure out if I can use Task Scheduler to detect an event every time the Dock connects, but I can't seem to figure out which event it is (or if this is the wrong way to do this).
Any advice you have would be very welcome!
I tried going through the Event Monitor to find events for the connection of the Dock or something else that also connects at the same time (like a USB device), but I can't quite figure it out
On Windows, what are all the possible creation entry points for user objects? I have been trying to isolate a handle leak in a .NET application for quite some time now. Here is what baffles me:
• Leak only occurs in window management objects (aka. USER objects - not kernel, not GDI).
• Leak only occurs when the application has focus. Clicking on another application "pause" the leak until we click on the application window again.
• Leak occurs even if process is suspended (through task manager or debugger).
I've been trying to intercept any and all object creation methods, but my Visual Studio debugger remains suspiciously silent. I do get the occasionnal call to some user32.dll methods (as described in https://learn.microsoft.com/en-us/windows/desktop/sysinfo/user-objects), but nothing that would account for the leak or come close to the system limit of 10 000 objects.
Any suggestion? Does anyone knows if some hidden system thread remains active even when my application is suspended? Thank you.
Ok, our team has been able to find one probable cause for the issue. Turns out that Microsoft's documentation tells only half the story. If at some point user and kernel objects were completely separate, recent versions of Windows have blurred the line.
As such, DDE transaction, monitor, keyboard layout, keyboard file, event hook, timer, input context, device info, touch data, gesture data and HID data should all be added to Microsoft's list of user objects. Some kernel methods may rely on user objects to provide services to apps.
To be specific, calls to RegisterRawInputDevices will result in the application receiving WM_INPUT messages. Those messages are backed by HID data and must be processed in a timely manner. If the process is suspended, unresponsive or otherwise fails to process incoming messages, there will be an accumulation and an exhaustion of system resources. This can quickly escalate into the problem described above and lead to an application crash.
Working in a plugin architecture (specifically, Sparx Systems Enterprise Architect), which does not forward either raw or cooked keyboard events, keyboard shortcuts for the plugin can be defined using RegisterHotKey(). These hotkeys are global, and the registration call fails if the specified key combination is already registered.
Since the application within which the plugin executes can be run in multiple instances, the hotkeys need to be repeatedly registered and unregistered based on which instance is in the foreground. An event hook for EVENT_SYSTEM_FOREGROUND can be set up for this purpose, but the question is: is there a guaranteed delivery order?
I need the instance that is losing focus to be told first so that it can unregister the hotkeys before the instance gaining focus tries to register them.
Is this possible? Or will I have to implement synchronization to be sure?
Windows DevCenter WM_ACTIVATE message says
..Sent to both the window being activated and the window being deactivated. If the windows use the same input queue, the message is sent synchronously, first to the window procedure of the top-level window being deactivated, then to the window procedure of the top-level window being activated. If the windows use different input queues, the message is sent asynchronously, so the window is activated immediately..
So if all of your windows come from the same application sharing the same input queue then it should be guaranteed. I guess that the EVENT_SYSTEM_FOREGROUND is built on top of the older code following the older logic (at least the implementation in ReactOS at http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/focus.c?view=markup (see EVENT_SYSTEM_FOREGROUND inside co_IntSetActiveWindow) does it)
Your problem might be easier if you'd monitor only keyboard events in your original hosting process (no global side effects) using the Windows DevCenter SetWindowsHookEx function, filter WH_KEYBOARD
In that case your code would exist once in one exe having one global variables, no cross-process synchronization would be needed
I am working on a client-server application where the server will depending on buttons clicked, would fire all the events of a keyboard. It is limited to the keyboard as well.
I am making a custom keyboard for my left hand. A friend has only 1 hand so it similar would benefit him. They keyboard will be some sort of touch device, possibly a large tablet, which will through networking and port connections establish a connection with my server.
My server applcation (written in anything really, python, C, C++, java, I know a LOT of languages) will accept a flag, and then execute a set of commands.
Essentially i want to do something like:
if(key_pressed == 'f1')
execute the 'F1' key in focused window.
Server application is NOT focused and will be hidden, or minimized on screen.
Is there a way to go that without building custom drivers or something?
Edit:
Client is like having a keyboard
Server is like the driver. I want the server to fire off things as if it is a character device being manipulated. The thing i was looking into is that i was reading a post or 2 which said only focused applications receive presses, which is fine, i want them to execute in the focused window, but in the background, be a process which will catch and then carry out the signal wanted like in the key_pressed above
I'm using a low-level keyboard hook (WH_KEYBOARD_LL) to disable certain input, such as Alt-Tab. I create the hook on a thread with a message pump, so I can properly handle the notifications.
The hook's callback function is able to process keyboard events whenever I'm not focused in the window that created the hook (i.e. my main window), but as soon as I activate that window, no events show up in the hook until I deactivate the window again and the input instead propagates to the window's WindowProc.
Does anybody have any clue what's going on here?
UPDATE: So, it turns out this behavior is caused by also registering for raw input in the same process. Apparently, using raw input causes my low-level keyboard hook to be disabled whenever my process’s window is focused. Does anybody know why and how to work around this?
Windows doesn't call low-level keyboard hooks if the most recently registered hook (aka the first hook to be executed) comes from a process that registered itself for raw keyboard events.
So a workaround is to create a second low-level keyboard hook in another process afterwards. Yes, this will cause both low-level keyboard hooks to be executed even when the focus is on a window from the first process.
Bad for performance, and who knows what Windows will bodge next - so I'm not really endorsing it - but it works.