I'm trying to change the input mode to a given window.
Searching i found the Edit_SetInputMode function, but when i run it, it always returns 0 ( fails) .
The MSDN documentation doesn't seem be to revealing... Any ideas anyone
Thank you
Dan
The correct terminology is probably focus: See SetFocus
Oh! I see where you are coming from. There is no such thing as Edit_SetInputMode - unless you are developing for embedded Windows that is.
Win32 "Desktop" applications get to use this set of Edit_xxx messages.
Related
I need a solution for this error
Before using UFT 14.x , I wrote my code on UFT 12 (on windows 7) for copy/paste function. (It worked 100%)
When I upgraded UFT to 14.x , that function respond with an error . The code and the image are the following :
Function WritingFast(strDataTable)
set objCB=createobject("Mercury.Clipboard")
objCD.Clear()
objCD.SetText (strDataTable)
Window("Internet Explorer").WinObject("Internet Explorer_Server").Type micCtrlDwn + "v" +micCtrlUp
objCB.GetText
End Function
The error says that WinObject("Internet Explorer_Server") is not unique, what are you trying to refer to by this object?
Please examine the description of the object in the object repository in order to see why the description there isn't enough to make it unique.
Alternatively you could take a step back and think about what you're trying to do, perhaps UFT's web support allows you to do it directly and not by trying to access the underlying Win32 objects.
Can't add a comment, rules, sorry. Gonna put has an answer but its more a tip.
If you don't have a duplicate, try capture the object again. See if UFT recognize that object exists or not at your repository.
At least you can see what he is capturing whit the upgrade and compare (if different).
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!
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
I've got a code that lists the running application on a win32 box, and then displays theirs icons.
So far so good, I get the hwnd of the app, then call for GetClassLong(hwnd,GCL_HICONSM), and everything's fine.
But the case of a java apps is a pain to deal with, as the process answering to my calls is javaw.exe, and not the shiny-pimpy java application, who's got a so beautiful icon...
I gave a shot at GetWindowThreadProcessId also, but alas, it's the PID of javaw that's returned...
There's a way to do this though, as the task manager (alt+tab) displays the good icon.
I answer to my own question, thanks to PhiLho who put me on the right track: an article from Codeproject with the right algorithm to get a window icon (wether it's java or not):
//first, try:
SendMessageTimeout(WM_GETICON)
//if no icon found, try
GetClassLong(GCL_HICONSM)
//if still no icon, try
SendMessageTimeout(WM_WM_QUERYDRAGICON)
//if still no icon, you're doomed, return an error, or a void icon
For some reason a java app answers to the first call, but not to the others, which seems to be handled by javaw.exe.
Thanks again PhiLho.
Mmm, it can be done, because Process Viewer has a Show Applications button which does that (even if the main view shows the Java's icon). Alas this freeware isn't open source, so it won't tell its secret... :-(
Sysinternals' ProcMon doesn't do that, alas.
I will dig a bit more... :-)
[EDIT] Both a MS KB article and a Code Project article recommend using WM_QUERYDRAGICON if GCL_HICON fails...
I'm writing a DLL that is automatically injected on load in a specific application. Because I'd like to run the program while working on it, and my users might want to load the program without it in specific cases (e.g. bug hunting), I sometimes want to prevent loading the DLL.
Currently I do this by checking GetKeyState for VK_LCONTROL, VK_LSHIFT , and VK_LMENU on load, and if all are down, I silently unload myself.
However, it can take quite a few seconds for the program to load and to see if the DLL was loaded or not, so I want to inform the users when we're unloading. I've considered a MessageBox, but that's too disruptive. I've tried MessageBeep, but that didn't seem to do anything on my setup. Currently I'm using a simple dual beep (Beep, Sleep, Beep) to indicate unloading, but that will probably become rather annoying to my co workers. I've also considered a system-tray icon, but that would introduce a lot of code and bug potential, while I'm aiming for a minimal notification as to not introduce any subtle bugs.
Would anyone else know a subtle way (preferably visual) to inform the user that their input has been succesfully received?
Given the limited scope of your goal, this might actually be an appropriate use of a taskbar notification balloon tip.
Edit: Added link the Joe posted in his concurring answer. Thanks, Joe! :)
If your app has a status bar at the bottom, you could place some message text there...
Have you considered a timed messagebox that closes itself?
http://www.codeguru.com/cpp/misc/misc/messageboxhandling/article.php/c203
You could open a window with a short message and close it automatically again after 0.5 seconds or so. It doesn't need user interaction so I don't think it's very disruptive.
Change the window title, then change it back afterwards. Then you can see the change even if the user has Alt-Tabbed over to some other program in the meanwhile, without stealing the focus from the user.
Concur with Greg D.
Look here: http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/15cbdc8d-fde3-44ab-bbbc-e50cb2071674/
Two ideas:
Turn it around. Have a visual indication when the DLL is loaded, and have the absence of the indicator let you know that the DLL has been unloaded. Perhaps a suffix in the title bar. That way, you can tell at any time, not just during startup.
FlashWindowEx.