While that is useful it does not cover his implications. He implied there is "No way" to connect to a Bluetooth device on RT if it is not one of the standard items (headset etc.) regardless of the Bluetooth integration (i.e. can be USB).
But interesting to note... I have a laptop that has integrated Bluetooth. This implies that internally the bluetooth is actually landing on the USB. I would have expected I²C...
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
I'm trying to handle mouse wheel events in the WndProc function and wrote c++ code that works fine with one mouse that has a fly-wheel. I tried the same code with another mouse and I get endless WM_MOUSEWHEEL events when I move the mouse wheel just one notch. Anyone know why this is happening?
You haven't posted any code or shown what any of the "extra" WM_MOUSEWHEEL events you are getting look like and unfortunately, my crystal ball is in the shop, so you might want to post that kind of information. My guess is that its something in your code, but until I see the messages or your code, I can't really give you any advice beyond that. Darn crystal ball shop, they are taking FOREVER to get my ball fixed.
The idea is to replace the clock with one that is driven by UDP packets. The videos will be silent (the audio turned off, preferably not even decoded).
I have stubbed out what I think is a clock replacement, but what I can't figure out is why my calls to GetCorrellatedTime seem to only occur at the start of playback. I expected GetCorrellatedTime to be called by the playback engine repeatedly.... but that's just not happening. Here's the cpp code for my timesource. Note that it doesn't do much of anything yet... it is just a stub.
I am using ExtTextOut to print unicode characters in memory DC. We create font using CreateFontIndirect to print characters in different orientations. When we use GB2312_CHARSET (chinese character set) with lfEscapement/orientation set to 270 degrees the characters are printed in reverse order. If the character to be printed is 'Chinese', it is printed as 'esenihc'. The same character set works fine if lfEscapement/orientation is set to 0 deg. The issue is present only in WINCE. The same code works fine in a Win32 application. I have written a sample application.Find below the code from sample app