I'm looking for a line of code in Delphi which can disable sending keys to an application. For example I have a game.exe, I want to disable sending keys to it, so you can not play it.
How to do that? Please Guide me step by step :)
Hiding and blocking input should be separate questions. Your question is so vague that I'm tempted to vote to close it, but here are some general ideas instead;
If you want to block all input from getting to an application,you can simply grab the focus away from that particular application, or keep your window on top and make it full screen. This is often called "Kiosk mode".
You could also forcibly hide all the application's windows.
You could intercept the window messages that are bound for that application and handle them yourself. See the link from Johan on Keyboard hooking.
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)
During load of my application I am loading settings and other things, and want to be able to show a message to the user. However this does not work on my Delphi XE6 FireMonkey application targeting iOS (iOSSimulator).
When I call ShowMessage or MessageDlg during program load, it locks, and nothing is shown. It is probably entering the modal state, but since the message is not shown, it is not possible to continue.
Even in the main forms FormActivate, calling ShowMessage does not show anything.
How can I show a message while loading the application?
You can use loading symbol along with Message. It will serve your purpose. You can use "MBProgressHud", you not need to give any extra effort, just pass parameter and it will display loading image along with text. Enjoy!
I am surprised that no one have written about this before and that no Firemonkey users have answered my question.
That you are allowed to call Showmessage during program load, but the app locks if you do it, is not appropriate behavior. In a desktop app, it is quite normal to show a message during program load, in case something fails.
I am converting a 500k line project from VCL to FMX, and since I cannot show a message on iOS, I will have to restructure the create and load code.
The solution I plan to implement is to make failsafe solutions that will allow the app to load no matter what happens, then when the app is running, I can show whatever messages have come up during load (those that the user have to consider).
If anyone have more information or suggestions for a better solution, please comment.
As nice as debuggers have gotten these days, sometimes the best way of finding out what is going on in an app is still ye olde NSLog. Doing this is easy when you're tethered to your computer; Xcode helpfully pops up the Log Viewer panel and there you go. Not so easy to do when you're away from your desk, as you sometimes have to be when testing an app (for example, when you are testing CoreLocation functionality). Sure you can pop open Xcode and check the Console section of the Device Organizer as soon as you get back from a testing run, but then you have to wait, and by the time you can get back to view the logs you forgot what was going wrong with your app; also odds are that by the time you are able to do this, the log messages you are looking for have scrolled off into oblivion.
Is there any way of checking the console logs on the device itself? I'm guessing the answer is "no, unless you jailbreak" (IIRC there are at least one or two terminal apps in jailbreak-land that I could use to do this sort of thing). Unfortunately jailbreaking is not an option for me.
Alternatively, is there some sort of Objective-C framework or library or whatnot that handles log collection and on-device displaying? Ideally this would come in the form of a drop-in replacement for NSLog, whereby I could simply do a search-and-replace and change all occurrences of NSLog to SomeFancyPantsLoggingTool or whatever and be done with it.
A good example of the kind of functionality I am looking for can be found in the podcast client Downcast. If you tap the "More" tab, then tap on the version number string at the bottom of the screen, a new view slides up that contains a scrollable view of accumulated log messages. It even has an easy way of mailing said logs to a support e-mail address.
Take a look at LibComponentLogging which you can configure to output logging at different levels and to different destinations.
There is a file for the SysLog. You can simply open it and read from it. The file is at /var/log/syslog. If the file does not exist there are instructions on how to set it up here.
Further to my post on custom format clipboard, I am considering the possibility of writing my own custom clipboad monitoring component.
Prior to the statement:
ClipboardWindow:=SetClipboardViewer(Form1.Handle);
I have seen in a sample code I studied the following snippet:
OpenClipboard(Form1.Handle);
EmptyClipboard;
CloseClipboard;
whereas others don't include a cleaning code at all. I am confused.
I believe Clipbrd.TClipboard.Clear just does the same the VCL way.
My question is:
When clearing the clipboard before joining the clipboard chain is mandatory ?
No, there is no need to clear the clipboard. Indeed, you shouldn't. Other clipboard monitors will needlessly react to the update, and the user may want to paste that thing that you just destroyed.
Additionally, there is a lot more to clipboard chain monitoring than just adding yourself to the chain. You must pass the events along to the next window (result handle from SetClipboardViewer), and you must, without failure, remove yourself from the chain when your app exits. Also, you need to avoid blocking the clipboard unnecessarily. Typically, this means waiting to register for the clipboard events until you're ready to actually process events. For example, don't make it the first thing in your startup, if you're going to subsequently open a dialog asking the user where he wants to store the data, if he has a license key, etc..
I have tips, as well as common pitfalls here:
http://www.clipboardextender.com/developing-clipboard-aware-programs-for-windows/6
The rule is as simple as possible: if you want to delete the clipboard content (so other apps can't use it) delete it. if not, keep it.
You don't know if your use wants to keep the data OR You want to implement something fancy?
Do you know those applications (Paint Shop Pro is one of them) that are asking: "You left a large image (10MB of data) in clipboard. Do you want to keep it or clear it?"
You could do something similar. :)
I am working on porting an XNA game to another platform. Some of the items in the compliance check list involve making sure the game remains in full-screen mode, cannot be minimized and that the windows key, win - m, and alt-tab are disabled. The only way to exit the game is supposed to be through the platform API (think exiting an Xbox or PS3 game by pressing the home or guide buttons).
It been difficult to find any information on this since most responses to previous questions are "never remove system functionality" but in my case specifically, those are requirements.
So is there a way to handle forced full-screen and disable minimizing? I haven't been able to find a way to get WndProc to work. Likewise for key events I need to disable. I can't find a way to intercept and handle the windows messages that control these events.
This post seems to give the interop code needed for hooking into the window message loop and overriding the Windows key events:
Disable Special Keys in Win App C#
Will the .IsFullScreen = true property not solve your issue? It will help with the screen but not with the keyboard disablement.