Hi how can i implement "switch to" functional in my app like in windows task explorer, can any one give me useful link or response how to do it?
Tnaks a lot for all
SetForegroundWindow is the normal way to change "current task", for "task switcher" apps, SwitchToThisWindow is a better solution since it does not require your app to be "foreground" (But please, don't abuse SwitchToThisWindow just to bring your own apps to the foreground)
If this is a alt-tab like application, you can use RegisterHotKey to register for a special key press, and EnumWindows to enumerate top-level windows...
Use the SwitchToThisWindow() Windows API function in User32.dll. Get a handle to the window using EnumWindows() or FindWindow(), then pass it to SwitchToThisWindow() to switch to the app.
Related
Given a program process (say Visual Studio 2012), how can I access it's menu items programmatically?
I'm not at all sure what APIs I would use or how to even Google this.
Thanks in advance.
Start with GetMenu(): http://msdn.microsoft.com/en-us/library/windows/desktop/ms647640(v=vs.85).aspx and over on the left are all the other menu functions. (Assuming you're talking Win32 API.)
Since it appears you have the process ID, you can find the main window's HWND from here: Win32 - Get Main Wnd Handle of application
unfortunately, more and more programs don't use the traditional "menu" subsystem. The answer given by Graham will work for some simple application, as calc.exe and notepad.exe, but not for VS2012.
I suggest using UIautomation.
The Windows SDks come with an "accessibility" tool, Inspect, that will show you if you can expect good support of UIAutomation by applications.
Microsoft now recommends using Accessibility Insigths instead:
https://learn.microsoft.com/en-us/windows/win32/winauto/inspect-objects?redirectedfrom=MSDN
Normally user is doing it by clicking right-mouse into console title bar then selecting "edit" and finally "mark". -> http://www.megaleecher.net/Copy_Paste_Text_Dos_Window
So is there a way of doing it from a console application either by sending a message/api call/keyboard sequence to its own window ?
If this is your own application and you want the richer behaviour and flexibility of a windows app rather than a console app, then use a windows app. Otherwise, you can try to automate the steps by simulating the input via SendInput. I would advise against doing this because it requires two steps (once for right-click, once to select 'Mark'). This means if someone clicks something else between these two events, your sequence will be broken. Furthermore you are really relying on the automation of an implementation detail which is prone to change at any point.
Looking through the Console Functions, it doesn't appear as though anything exists for setting the selection. The closest is going the other way with GetConsoleSelectionInfo.
If you want to process the information that is within a console application, a better alternative is to pipe it to your own process and deal with it there.
Found: PostMessage(GetConsoleWindow(), WM_COMMAND, 65522, 0);
Is it possible to develop win32 UI application for Pocket PC with multiple dialogs
we need to display each dialog based on user input and hide previous dialog when current dialog is displayed on window.
Thanks in advance
Sure, that sounds a lot like standard application behavior, which is supported. The only thing not supported is MDI. Programmatically it's going to work just like on the desktop, so examples using calls to CreateWindow or CreateDialog will be applicable.
I'm developing an application for debugging purposes. I want the user to be able to select the process to be debugged using the mouse. Process Explorer does a great job of this with the "Find Window's Process" feature. What I can't figure out is how it does this? Does anyone know the Window's API that provides this functionality?
Thanks, Grant
I haven't tried this, but it should work: Use WindowFromPoint to get the window handle, then use GetWindowThreadProcessId to get the ID of the process that created the window.
Alternatively, you could use EnumWindows to enumerate all top-level windows on the screen, filter them by some criteria (e.g. position) and then use GetWindowThreadProcessId to get the process IDs.
If I understand you correctly you are looking to enumerate all Windows and perform some action when the target Window in question is found. You can do this by enumerating all current windows and then performing some action when the user is over the window in question. You will have to associate that window handle with a process.
This is not a simple task as it requires going through a lot of hoops but it is possible, just have to put all the pieces together.
I'm looking for a way to programmatically detect hotkeys in the system. My app supports configurable hotkeys to do different things, and I'd like to be able to tell if another app has snagged one already or it's a built-in Windows hotkey (like Win-L to lock the workstation).
And if it is another app that owns the hotkey, I'd like to be able to show that to the user. At least the name of the exe.
I'm aware of three ways to do hotkeys:
System hook using standard API's
Using the hotkey feature in the properties dialog for a shortcut
Polling async key state and responding
I doubt I can detect the third type, but what about the other two? And are there any other situations I need to know about?
I can think of three ways to do it with Standard API:
RegisterHotkey
SetWindowsHookEx(WH_KEYBOARD)
SetWindowsHookEx(WH_LL_KEYBOARD)
With the first approach, you will get in the return value whether another application already registered the very same hotkey (or whether a shortcut uses this hotkey, or Explorer.exe registered the hotkey because it is Win+E or win+R). You don't get the application name this way, though.
Using Windows Hooks or async key states for "hotkeys": I don't think it is possible to detect hotkeys there, since you might use hotkeys in a context (like replace "t" by "irst" if the last four keystrokes were "Fris") that way. You could inject the hotkey using keybd_event (with your window focused) and test if the event "gets through"; on the other hands, some cases of "hotkeys" that are implemented via hooks do not consume the keystroke so it will still get through.
The approach I would use: First make sure that for entering a shortcut, you have to type that exact shortcut into your shortcut box (if that fails, the user will see which application uses it). Then use RegisterHotkey, so you will notice (in future sessions) if another "well-behaving" application tried to steal this shortcut from you.