I am having trouble writing a program that I want to be active always.
I wrote code on keydown to do something, but when form1 is minimized or in tray keydown event does not response. How can I get my application to respond to keyboard events even when it is not in focus?
addition :
its window app , and lang is c#.NET ,
If I can assume that this program is for Windows, you cannot do that. Once you application window is closed, it will not raise KeyUp/KeyDown. Nearest to what you want is either hotkeys (to activate program once specific key is detected) or keyboard hook (if you wish to have overview of every key press).
However, what you will use depends on which exact scenario were you thinking about.
Related
I'm having a hard time figuring out how to simulate mouse clicks and such in a window that is minimized or not currently active. In case it's not clear, I want my mouse to be able to click and stuff without actually using the mouse.
For example, while I'm browsing the web I would like my program to be able to be clicking inside of another application at the same time.
How can I accomplish this? All I can find is the same old movemouse and setcursorpos stuff... as we know that requires the use of your actual mouse/Cursor.
You are looking to automate applications. This is done not by faking input but by using an automation API. These days, the preferred one is UI Automation. This is perfectly accessible from Delphi: How to use MS UI Automation in Delphi 2009.
Here's what I would like to do in Delphi XE:
Capture a double-click in another application such that when it occurs and the text underneath the mouse is highlighted, this triggers a series of events in my application based on what the text highlighted was.
I am aware of ways to do this using a system-wide mouse hook but... Since my application and the other application will in many circumstances be hosted in a terminal service or citrix environment, I am rather reluctant to do this with a mouse hook as I'm concerned about the resource cost. (I'm picturing the server hosting hundreds of mouse hooks, one for each user... shudder). Am I being too cautious? How much is the performance and stability hit of a mouse hook? What about under the TS or citrix environment? If my gut is correct and the cost of multiple hooks would be too high, is there another way to do this?
I do not have access to the source code of the other application and the 3rd party richedit control wherein the text is found has been modified beyond all recognition and doesn't respond to the API when used as published. Help?
This isn't possible without using a system-wide mouse hook, AFAIK.
You're right to be concerned about overhead. The mouse hook (MouseProc) is called every time a window calls PeekMessage or GetMessage and there's a mouse message to be retrieved, and it will be called for every window of every application running. Even if your hook simply passes the event along to the next handler using CallNextHookEx(), it will have an impact on the system. I'd suspect that multiple sessions running under TS would be pretty nasty.
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.
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.
I have noticed a strange piece of behaviour when using MessageDlg and attempting to close my application via the Taskbar close all/group command.
My application is as follows:
There is a hidden main form which doesn't do anything other than handle some Windows Messages and pass them onto the child windows (if necessary).
Each child window has its parent set to the desktop (in order to get it displaying on the Taskbar).
Each child has an OnClose event which pops up a MessageDlg to prompt the user whether they want to save their session (if any content has been modified in anyway)
The issue seems to be it will continually close any windows that haven't been modified, however, when it hits a window that has been, 1 of 2 things are happening intermittently:
Regardless if I select "Yes/No" the Close All process seems to stop after that particular window is closed.
The dialog is not displayed and mrCancel is the result. Again the close all process stops after this window is closed.
A change I made was to use the WinAPI MessageBox function in replace of MessageDlg and this did seem to resolve the issue. However, I would really like to know why MessageDlg is acting like this?
My initial thought was when the dialog is being launched in the middle of the Close All perhaps the OS is sending a WM_CLOSE message to the dialog as it is technically part of the group (this would explain the dialog not appearing and defaulting to mrCancel as this is the equivalent of pressing the X). However, that doesn't explain why after I dismiss the dialog the Close All process does not continue to close any other windows in the group!
Any thoughts/idea's on this?
Windows doesn't send WM_CLOSE messages to these windows, it posts WM_SYSCOMMAND with the SC_CLOSE request. This in turn leads to the sending of WM_CLOSE messages if the standard Windows message box is used. If the MessageDlg() function is used instead, only the first posted WM_SYSCOMMAND leads to a WM_CLOSE, the others do not. It's hard to say for sure, but maybe this has something to do with the DisableTaskWindows() and EnableTaskWindows() calls that the VCL uses to "fake" modal dialogs. If you replace the Windows function with Application.MessageBox(), a wrapper that does use DisableTaskWindows() and EnableTaskWindows(), then it doesn't work either (which IMO supports this reasoning).
I think I can explain why switching from MessageDlg to MessageBox made things different. MessageDlg in turn calls the MessageDlgPosHelp which creates a Delphi form to look like the Windows MessageBox, and this form is called shown with ShowModal. This locks the entire application until it is closed.
MessageBox, on the other hand, defaults to MB_APPLMODAL which means you have to close it before the window it is attached to can be used. If you have nothing specified in the uFlags parameter then this is the default. This only prevents you from getting back to the window specified in the hwnd parameter, so other windows in your application are still accessible.