I am told, that the program that handles the ALT+TAB input is called task switcher. But I am not happy with the task switcher that is provided from stock.
Could anyone give me a push to the right direction so I get an idea how I could write one on my own and replace the old with the new one?
It's not that I have no programming experiance, I just don't know where to begin on this special one. :D
Thank you!
There are three essential ingredients for writing a replacement switcher in Windows (these were tested under Windows 7):
Capture Alt+Tab: For this I would use SetWindowsHookEx and a low-level keyboard hook (WH_KEYBOARD_LL).
Enumerate the windows you could switch between: Two options for this are EnumWindows or the UI Automation Framework (managed code can use System.Windows.Automation).
Perform the switching: You can use SwitchToThisWindow or SetForegroundWindow, but in either case you will need to set uiAccess=true in your manifest. This will additionally require you to sign your executable and install it in Program Files. You do not need to call AttachThreadInput or perform other such shenanigans.
For a more thorough discussion, see this blog post.
We have answered your question in this link:
How to focus on last activated program?
By using this code instead of that one you can have the list of open windows,
string name = GetWindowTextRaw((IntPtr)hwnd);
if (name.Length > 0)
{
windowArray.Add(hwnd);
}
Now you can use the following code to switch between windows:
SetForegroundWindow((IntPtr)windowArray.sth);
Related
My custom Windows shell context menu handler works like a charm, for all Windows versions from XP to 7, but on Windows 8, 8.1 and 10, installing it breaks the Win+X menu (sometimes called "Power user menu", or "Quick Access menu", or "WinX menu"): when hitting Win+X, the menu is displayed as expected, but its items do not work anymore (nothing happens when I click on them), except for the last four items at the bottom which still work as expected ("Search", "Run", "Shut down/Sign out", "Desktop"):
I quickly found out on Google that it was a well known issue for a great number of shell extensions that were not "compatible" with Windows 8/10. But sadly, I only found application users talking about this issue and its "solutions", and no developer talking about this. And the two "solutions" proposed by these users were:
Unregistering this shell extension
Uninstalling the app that registered this shell extension (which leads to solution 1...)
See for example this, this, or this to read people talking about this issue.
Note: my shell extension is applied for the * file type, which means all files.
Several days later, I found the cause of this issue in the shell extension source code, so I thought it would help other developers to share it on StackOverflow, as a self-answered question (I didn't find this question). See answer above.
I first looked at the shell extension sample code provided by Microsoft (which doesn't cause this issue), compared it with my code, and progressively replaced parts of my code with Microsoft's code and testing it after each replacement.
I found out that what prevents power-user menu to work is what you return in method InvokeCommand() from IContextMenu interface: if your extension cannot handle the given verb, it shall always return E_FAIL so that Windows tries with other implementations of IContextMenu (see Microsoft documentation for more details). It seems that when a power-user menu item was clicked, Windows first called my extension (* file type), then since it didn't return E_FAIL for this unknown verb, Windows thought that my shell extension has processed this event, so it didn't process it through the nominal power-user menu callback.
By the way, three things seem very weird to me:
Why does Windows even try to process this power-user menu event with a shell file extension? Is this menu coded using the same design/mechanism as any other Explorer's file contextual menu?
Why does this bug didn't produce more side-effects yet? I mean this should have broken the whole shell extension system right from the beginning, no?
Why do so many applications has this bug? (meaning why so many applications do not return E_FAIL as expected?). It's been a while now that I've written this code, I can't really remember where it comes from, but I guess it comes from a Microsoft sample or any Microsoft employee tutorial (far too Microsoft-oriented to be coded by yourself). If it's the case, that may answer the question why so many shell extensions cause this issue...
I would be interested if someone has some ideas to share about this subject!
By the way, I hope my post can help other developers. When looking at the new Microsoft example that works like a charm, I was first afraid having to rewrite all my shell extension from their sample without knowing what was wrong in my code!
I ran into a reproducible bug which doesn't really make sense to me. Hopefully someone knows more about the internals of keyboard input under Windows (I'm using Windows 7) and can point me in the right direction on how to solve it. As it stands now I don't really know where I should start to look.
My application creates a global keyboard hook, using the MouseKeyboardActivityMonitor library. This was working fine for me, but I quickly received bug reports from people using different keyboard input languages. When they write letters with accents, e.g. ë and ê, they show up as ¨¨e and ^^e respectively. This bug is also reported on the library's website, but hasn't been resolved yet.
To try to reproduce the bug I set up an alternate input language 'Dutch (Belgium)' next to my existing 'English (United States)'. After some toying around I discovered the following:
The bug doesn't occurs when the application which installs the hook has focus, and language is set to 'English (United States)'. Writing in any other application (e.g. notepad) and using 'Dutch (Belgium)' to write the special characters work. The bug does occur when the application which installs the hook has focus, and language is set to 'Dutch (Belgium)'.
I am looking for any clue as how the two are related. Perhaps I need to introduce some extra checks in the keyboard hook library? The source code of the keyboard hook is available on line.
It seems that the input language is not updated in your application. Looking at the source code of the library that you are using, it seems that they use this call to get the correct keyboard layout:
internal static extern uint GetKeyboardLayout( int dwLayout );
The documentation of this method however emphasises:
The input locale identifier is a broader concept than a keyboard
layout, since it can also encompass a speech-to-text converter, an
Input Method Editor (IME), or any other form of input. Since the
keyboard layout can be dynamically changed, applications that cache
information about the current keyboard layout should process the
WM_INPUTLANGCHANGE message to be informed of changes in the input
language.
However, based on a quick glance at the code, the library does not seem to respond to this WM_INPUTLANGCHANGE message, which might cause this behaviour
Also, here is a useful link to an explanation how the Keyboard is handled by Windows
I'm working on a little macro record/replay tool which can automate a few very old Visual Basic 6 GUIs we have. To do so, I'm identifying the controls by their name (the value of the name property of a control, that is).
One part of this tool needs to determine the name of a control given its HWND. For newer Visual Basic applications which were done using VB.NET, I can use the WM_GETCONTROLNAME window message. This works nicely.
However, this message is not understood by older windows. Is there any way to do this for controls of Visual Basic 6 applications? A solution which does not require being in the process of the GUI would be preferrable, but if I had a solution which only works inside the GUI process then that would be acceptable as well (since I can do the injection myself).
UPDATE: One thing I just tried, this moderate success: I used the AccessibleObjectFromWindow to check for implementations of the IAccessible interface of the object which shows the given HWND. In case I get an implementation (it seems that many [all?] Visual Basic controls implement this interface), I use the accName property to read out the "accessible name". Sometimes this does yield a useful string, but usually it doesn't.
I believe the only way would be getting inside the process and obtaining a pointer to the Form object, yet I have no idea how to do it from outside.
Is it possible you add support for the WM_GETCONTROLNAME to those older applications?
Or maybe, you could identify the controls by some other, natively-available properties?
Other that that, as Raymond is saying, there isn't much you can do.
Can you modify the vb6 apps? if so in each form load event you could iterate me.controls and use the SetProp(ctrl.hwnd, "MYNAME:" & ctrl.name, 0) api to add the name to the window's own property list, then in your other app you can EnumProps(ctrl_HWND) looking for the one that begins with MYNAME: and parse out the value.
Hy everybody,
I'm wondering if it's possible to add a new button via C++ or C# to windows 7 explorer "context strip"(don't know if this is correct name) - like on picture below.
My reason for this is because a lot of times I'm switching on&off "Show hidden files, folders and drives" functionality under Tools->Folder option->View. Therefore i want to simplify this process with a click of a button.
I was looking into ShellExecteEx function, but I am not sure I can do that. Can Anybody direct me in right direction?
thanks,
regards
I highly recommend using AutoIt for this task. Second URL comes complete with examples of how to insert buttons in various programs - however, be sure to read complete topic for misc. updates to the provided code.
See:
http://www.autoitscript.com/forum/index.php?showtopic=9517
Btw: I misread topic to begin with; gui 'context' related material in Windows is often taken to deal with right-click menus
Edit: limit on urls for new users on Stack Overflow mean I had to cut out some of less essential links - google away.
To answer part of the question, I think it is possible as for quite some time we've seen small programs to add a "New Folder" button to the explorer. I think those still works with Win 7.
Look at http://tools.tortoisesvn.net/StExBar for example
[Edit] Forgot to clarify that Source Code for StExBar is on Google Code
In a windows version with tablet support, a small keyboard icon appears when an edit control gets focus. If you touch it the touch keyboard pops up.
Is there a way to disable this? It's rather inconvenient if you have your own touch keyboard.
I want to disable it for certain edit controls in code, ie. I'm not looking for a Windows setting.
Giel
Well, I guess a late answer is better than no answer, so here it comes:
You can disable the Windows onscreen-keyboard for your application.
To do so, start Regedit and navigate to the Key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TabletTIP\DisableInPlace]. There you create a new String Value, set its name to the full application Path (e.g. "C:\Progam Files\My App\MyApp.exe") and set its value to "1".
Edit: Recently I had to rethink my solution... By setting the Registry value, you disable the onscreen-keyboard for the whole application. But should you need a keyboard for some seldom used function of your program and just happend to forget including an onscreen-keyboard, you have to control the Windows TextInputPanel via SDK / API. See this link: Disabling the Input Panel Programmatically.
Use the PenInputPanel for handwriting and the TextInputPanel for an onscreen-keyboard.
For all those Delphi programmers out there: import the Type Library "Microsoft PenInputPanel" and FIX A BUG in the imported *_TLB.pas: change the parameter type of the two methods of IPenInputPanel:
function Get_AttachedEditWindow: SYSINT; safecall;
procedure Set_AttachedEditWindow(AttachedEditWindow: SYSINT); safecall;
Disable the "Touch Keyboard and Handwriting Panel Service"