When can a BluetoothLE operation prompt for consent on Windows 10? - c++

I developed a command-line program that connects to a BLE device (a motion sensor), subscribes to motion notifications, then prints the coordinates to stdout around 60 times per second. The data is consumed by a legacy Adobe AIR desktop application (which handles running of my "driver" program).
I have used Microsoft's Bluetooth Low Energy code samples as a reference.
I've found the following in one of the code samples:
// BT_Code: BluetoothLEDevice.FromIdAsync must be called from a UI thread because it may prompt for consent.
bluetoothLeDevice = co_await BluetoothLEDevice::FromIdAsync(SampleState::SelectedBleDeviceId);
Those samples are UWP apps, but my program is C++/WinRT console program, and naturally has no UI thread. So I am guessing that in case of consent prompt it will just fail.
I've finished writing the program and it's working, but this comment got me worried about some situation where this consent prompt topic will become an issue. Or perhaps it can work now, and break with some future Windows update if they introduce more widespread consent dialogs.
So far I found that pairing a device requires consent (link). My device doesn't require pairing.
I would like to know if there's a well-defined list of cases when a Bluetooth LE consent prompt might be required?

Related

Detect existing idle application

I have a problem and I need a approach for the next problem:
Lets say there is an application "A". This application "A" can be used only if you have a license. There are couple of users that use this application and "reserve" the license for them, if the license is free. But, sometimes the user who "reserved" the license, forget to "unreserved".
The main question: How can I detect if a user is not using the application for X minutes (the application is in idle state)?
It doesn't mean that the user is not active on the computer - he is using another applications on the computer, but he doesn't use this particular application "A" . (The user have to login so he can use the license. That means that even he exits the application, minimizes the application or simply the application is in the background of other applications, he still poses the license)
I read about GetLastInputInfo, but I don't believe that it's going to help me in my situation. All I want is to get info if the user is interactive with the application.
I'm using C++.
OS: Windows 10 x64bit.
How about your application hooks the input queue and filters on the messages that YOU think are applicable to the application being used (probably keyup/down/mousemove probably not WM_TIMER or WM_PAINT) and then when you decide it's been long enough since you received one of these messages (set a timer each time one of the selected messages has been received), that's when you release the licence key.

Will Windows always allow hooks and/or the journal record?

I'm writing a keylogger/mouse tracker for use in an opensource input heatmapping application basically identical to Razer's newest heatmapping software, but for use with any hardware/OS (using Qt's amazing cross platform SDK). As you would imagine, this involves intercepting keyboard and mouse messages from the kernal when the application is not the main process.
For Windows I was drawn to GetAsyncKeyState, but there's a note on the return value from MSDN about this function returning zero if "the foreground thread belongs to another process and the desktop does not allow the hook or the journal record."
Barging ahead regardless, I wrote a method for getting the keyboard state (that triggers every set interval of time via Qt's QTimer methods) and it just worked:
//The following executes every 100th of a second:
for (int i = 0; i < 256; ++i)
{
keyboardArray[i] = GetAsyncKeyState(i);
}
As I watch this array in the debugger, I can see the values in the array change as I type even when the application is not the main process. So, for my computer at least this function works at monitoring key states when the main thread is not focused on my application.
My question is: In what instances does Windows not allow hooks or the journal record? In other words, are there some versions of Windows and/or privileges a user could have/not have where this method could fail? I don't really have access to a bunch of different machines to test this on.
My specs are Windows 7 Home Premium 64 bit, Intel i7 930 (2.8 GHz, quad core hyper threaded), 12 GB DDR3 1333 MHz memory, 2x Nvidia 460 if any of that helps.
Best Regards,
Weikardzaena
EDIT:
Hans Passant gave me an example of situations where this type of implementation would fail: mainly applications on Windows that include User Interface Privilege Isolation (UIPI). Basically if an application is really important to the operating system (like a command prompt) then this type of message intercept will not work. I even tested it and it's true: my application stops updating the keyboard array when a command prompt is the main thread.
This and what LoPiTaL said suggests that only specific applications will not allow this type of intercept to occur. I'm mainly aiming this application toward gamers who (like myself) would like to see key presses and mouse clicks for their gameplay, so maybe I don't care about this issue as much, but if I want to expand this to general use (including people who use CMD a lot) then it seems like there's actually no way to intercept key messages for those types of elevated applications.
Is that true, or can methods like SetWindowsHookEx still intercept messages to UIPI applications? I was trying to avoid implementing hooks directly because that might be viewed as a virus on people's home machines, and capturing and re-emitting every input message just slows down everything, which in gaming is pretty big deal.

How can I detect keyboard and/or mouse input on Windows Mobile?

I'm working on a small C++ project which involves a launcher application that does a bit of setup work and then invokes the real application. To be precise, I'm working on the launcher application - the real application is done by a separate team. These programs are both deployed to Windows Mobile devices. Now, I'd like to be able to get notified of all keyboard and mouse activity in the real application (which my launcher starts) - and I cannot modify the real application to do this.
On Windows desktop machines I'd do this using the SetWindowsHookEx API. However, this is unavailable on Windows Mobile.
I also considered subclassing all windows in the process so that I can handle the relevant window messages for keyboard and mouse input - but I don't know how to get notified of new windows which the real process creates.
Does anybody have some thoughts on how to achieve this?
You can use SetWindowsHookEx, it is only undocumented. This is a good post about hooks and subclassing on Windows Mobile.

how do i prevent screen-savers and sleeps during my program execution?

In a c++ program run on Win7, is there a way to fake a mouse movement or something like that, just to keep the screen saver from starting and the system from going to sleep? I'm looking for the minimal approach and I prefer not to use .NET.
Thanks,
-nuun
Don't mess with the screensaver settings, use SetThreadExecutionState. This is the API for informing windows on the fact that your application is active:
Enables an application to inform the
system that it is in use, thereby
preventing the system from entering
sleep or turning off the display while
the application is running.
, and
Multimedia applications, such as video
players and presentation applications,
must use ES_DISPLAY_REQUIRED when they
display video for long periods of time
without user input
That's not a bad idea, any decent media player does it... Look for SystemParametersInfo(SPI_SETSCREENSAVEACTIVE ...) function in Win32 api, it should do the trick.
Before Windows starts screen-saver, it sends SC_SCREENSAVE notification in WM_SYSCOMMAND message to applications. If application wants to prevent screen-saver from starting, it should set "handled" flag to true and return zero during message processing. There is also SC_MONITORPOWER to prevent display from going to low power state.
https://learn.microsoft.com/en-us/windows/desktop/menurc/wm-syscommand

Off screen rendering when laptop shuts screen down?

I have a lengthy number-crunching process which takes advantage of quite abit of OpenGL off-screen rendering. It all works well but when I leave it to work on its own while I go make a sandwich I would usually find that it crashed while I was away.
I was able to determine that the crash occurs very close to the moment The laptop I'm using decides to turn off the screen to conserve energy. The crash itself is well inside the NVIDIA dlls so there is no hope to know what's going on.
The obvious solution is to turn off the power management feature that turns the screen and video card off but I'm looking for something more user friendly.
Is there a way to do this programatically?
I know there's a SETI#home implementation which takes advantage of GPU processing. How does it keep the video card from going to sleep?
I'm not sure what OS you're on, but windows sends a message that it is about to enter a new power state. You can listen for that and then either start processing on the CPU or deny the request to enter a lower-power state.
For the benefit of Linux users encountering a similar issue, I thought I'd add that, you can obtain similar notifications and inhibit power state changes using the DBUS API. An example script in Python, taken from the link, to inhibit power state change:
#!/usr/bin/python
import dbus
import time
bus = dbus.Bus(dbus.Bus.TYPE_SESSION)
devobj = bus.get_object('org.freedesktop.PowerManagement',
'/org/freedesktop/PowerManagement')
dev = dbus.Interface (devobj, "org.freedesktop.PowerManagement.Inhibit")
cookie = dev.Inhibit('Nautilus', 'Copying files from /media/SANVOL')
time.sleep(10)
dev.UnInhibit(cookie)
According to MSDN, there is an API that allows an application to tell Windows that it is still working and that Windows should not go to sleep or turn off the display.
The function is called SetThreadExecutionState (MSDN). It works for me, using the flags ES_SYSTEM_REQUIRED and ES_CONTINUOUS.
Note, however, that using this function does not stop the screen saver from running, which might interfere with your OpenGL app if the screen saver also uses OpenGL (oder Direct3D).