I've got a presentation pointer (Kensington Wireless Presenter), and as mentioned in this issue (that is for the rest unrelated, but it is the only mention of the same problem I could find), the back and forward keys work properly, but when I press the laser pointer key, along with turning on the laser, the receiver interprets this as a key press of the F5 button, which is rather annoying since this also triggers the going in or out of presentation mode.
I'm on Windows, and I'm curious whether there is a way to bind the laser key on my pointer to another button (or none at all) on my pc.
There is software like KeyTweak to rebind keys overall. Problem is, that you would rebind F5 but that might be a temporary solution until you find a better one
Related
When pressing the F1 key, the win32 API first sends the appropriate key message then sends a WM_HELPmessage to the control that has the focus.
As it does not process it, it gets sent up the parenting chain all the way to the form which reacts to the message.
In Delphi (XE7) this happens because of calls to CallWindowProc inside Vcl.Controls.TWinControl.DefaultHandler
While this works fine in pretty much all locations inside my applications, there is one place where WM_HELP never reaches the top form.
Trying to reproduce it, I came up with a test application that you may find here:
http://obones.free.fr/wm_help.zip
After having built the application and started it, place the focus inside the In SubLevel or Level 1 edits and press F1.
You will see that WM_HELP is caught by the form.
Now, if you do the same inside In SubLevel2 or Level 15 edits you will see that nothing is logged, the form never sees WM_HELP
Tracing in the VCL I found out that for those deep levels, the calls to CallWindowProc inside Vcl.Controls.TWinControl.DefaultHandler immediately returns on one of the controls in the hierarchy, thus preventing the form from ever receiving the message.
However, I couldn't figure out why the Win32 API code thinks it should not propagate the message anymore, except for one thing: If I remove the WH_CALLWNDPROC hook, then everything is back to normal.
You can see the effect of disabling it if you uncheck the Use hook checkbox.
Now, one will argue that I shouldn't have such deep hierarchies of components, and I agree. However, the structure in the center with two frames inside one another is directly inspired by what's in the application where I noticed the issue.
This means that it can be quite easy to trigger the problem without actually noticing it. Hopefully, in my case, I can remove a few panels and go back below the limit.
But did anyone encounter the situation before? If yes, were you able to solve it? Or is this a known behavior of the Win32 API?
This is caused by a "Windows kernel stack overflow" that happens if you send window messages recursively. On a 64 bit Windows the kernel stack overflow happens much faster than on a 32 bit Windows.
This bug also caused the VCL to not resize deeply nested controls correctly before it got fixed by changing the recursive AlignControls code to (my) iterative version (more about the stack overflow: http://news.jrsoftware.org/news/toolbar2000/msg07779.html)
Good afternoon all!
I'm experiencing a rather annoying issue with one of my current projects. I'm working with a hardware library (NVAPI Pascal header translation by Andreas Hausladen) in one of my current projects. This lib allows me to retrieve information from an NVIDIA GPU. I'm using it to retrieve temperatures, and with the help of Firemonkey's TAnimateFloat, i'm adjusting the angle on a custom-made dial to indicate the temperature.
As FMX defaults to Direct 2D on Windows, i can monitor the FPS with any of the various "gamer" tools out there (MSI Afterburner, FRAPS, etc).
The issue i'm having is that when i put the system into sleep mode (suspend to RAM/S3), and then start it up again, the interface on my application is blacked out (partially or completely), and nothing on the UI is visibly refreshing. I'm calling the initialization for the NVAPI library regularly and checking the result via a timer, but this doesn't fix the issue. I'm also running ProcessMessages and repaint on the parent dial and it's children controls (since i can't seem to find a repaint for the form or even an equivalent).
I tried various versions of the library, and each one presents the same issue. The next paragraph indicates that this was in fact NOT the issue, and that it's actually the renderer at fault.
I have one solution, but i want to know if there's something more... elegant, available. The solution i have involves adding FMX.Types.GlobalUseDirect2D := False; before Application.Initialize in my projects source. However, this forces FMX to use GDI+ rather than Direct2D. It works of course, but i'd like to keep D2D open as an option if i can. I can use FindCmdLineSwitch to toggle this on/off dependant on parameters, but this still requires me to restart the application to change from D2D to GDI+ or vice-versa.
What's weird about it is that the FPS counter (from FRAPS in my case) indicates that there's still activity happening in the UI (as the value changes as would be expected), but the UI itself isn't visibly refreshing.
Is this an issue related to Direct2D, or a bug with Firemonkey's implementation? More importantly, is there a better method to fixing it than disabling D2D? Lastly, also related, is it possible to "reinitialize" an application without terminating it first (so perhaps i can allow the user to switch between GDI+ and D2D without needing to restart the application)?
This is may be of the issues with FM prior to the update 4 hotfix - 26664/QC 104210
Fixes the issue of a FireMonkey HD form being unresponsive after user unlock - installing this might resolve the issue for you.
The update should be part of your registered user downloads from the EDN (direct link http://cc.embarcadero.com/item/28881).
sorry for this little bit strange title, didn't found a better one..
I've got the following situation:
I have a PC with an RFID reader connected via USB.
I now need a program which pops up when ab transponder was scanned the the RFID reader and shows the scanned value. (The reader just simulates keystrokes)
Problem: the value of the transponder is something like 0001230431, and I can't change it. (To prefix a hotkey combination or so)
So I have thought about using a global keyboard hook, check if three zeros where typed in, capture rest of data and when the 10 digits are complete, call the application through an automation object and show the number.
But I'm not very exalted about using a global keyboard hook. Many AV programs don't like them very much, they are not so easy to handle with Delphi and I guess that's not very resource-friendly for such a little task...
So I'm looking for an alternative solution...maybe somebody has an idea?
Big thx!
ben, you can use the RegisterRawInputDevices and GetRawInputData functions.
first you must use the RegisterRawInputDevices function to register the input device to monitor and then you can retrieves the data from the input device using the GetRawInputData function.
Check theses functions too
GetRawInputDeviceList retrieves the list of input devices attached to the system.
GetRawInputDeviceInfo retrieves information on a device.
Why not make sure the Delphi app with a text edit control has focus before the scan is done? Then the keystrokes will go straight into your Delphi app.
I've written some BlackBerry apps, but now i'm trying to write one that must access the hardware (keyboard) in some low level way, and I can't seem to find a way to do it, nor any help to it in the 'official' boards.
The thing is, I need to know when, at any time, the '$' key is pressed in the blackberry keyboard, so my app (or resident service) can catch it, stop the '$' char from displaying, and if the user presses a vowel next, then add an accent to that vowel... and if it presses another key, just send back the '$' char + the other char.
i.e. '$' + 'a' = á
In other words, I need to create an app or service that converts the '$' key into an accent key, just like typical non-US PC keyboards works.
Now here's the problem: The whole Blackberry OS works under a Java Virtual Machine (Kind of making the JVM the actual OS). So as you can imagine, every app written for it is written in Java.
There's obviously a set of special blackberry api libraries into their Java implementation so the developer is able to access particular Blackberry functions and features... however there doesn't seem to be a thing that I can use to achieve my particular task.
But then maybe there is, and I haven't found it, since I'm still new to Blackberry Programming.
So, in that note, any help or comment will be greatly appreciated.
-Gabriel Alonso.
A screen need to have the focus to be able to get key Event.
RIM dosen't allow low level access to their hardware for security reason.
Press and hold a letter key and roll the thumb-wheel to scroll through international/accent characters, equation symbols and other marks.
Here is the source
Blackberry do not allow execute applications, if they use certain API, not to mention the low-level programming.
All that you can use in your applications for keypad handling - it is possibilities of Java. Like KeyListener interface and Keypad class.
This is a very late reply, however...
You can use keyChar (member of screen, and of KeyListenerInterface) to intercept any key - for the first letter, capture the key pressed. If it's "$" hold onto it and don't call super.keyChar. On the next keyChar (or after a delay with no input) perform your mapping if $ was previously pressed, and send your designed character code to the super.keyChar call. keyDown and keyUp can be used similarly if keyChar presents implementation issues.
When I try to set the width of a multiline EditBox widget, it flickers for a moment, then gets set.
Is there a way to get rid of the flickering? Or, alternatively, is there a workaround?
It might be a problem with the way the UI rendering is optimized. Try changing your UIFaster setting as described here: http://www.wowwiki.com/CVar_UIFaster
I've usually seen this as a result of multiple calls to :SetWidth() occurring in quick succession. There are two ways this can happen — (a) it's genuinely getting called multiple times, or (b) it's been hooked/replaced with another function which is internally causing multiple calls. As a quick test, try running the following command (or equivalent) via the WoW chat window while your edit box is visible:
/script MyEditBox:SetWidth(100)
If the size changes without flicker, you've got scenario A — go over your addon's logic paths and make sure :SetWidth() is only being called when appropriate (and only once). If it does flicker, you're probably looking at screnario B (or, of course, the UI issue Cogwheel mentions). This may be harder to debug, unless you're hooking/replacing SetWidth yourself, but a good first step would be to disable all other addons and see if the problem resolves itself. If not, my first guess would be a library issue (assuming you're using any).