The Qt documentation for QWidget::activateWindow() states:
On Windows, if you are calling this
when the application is not currently
the active one then it will not make
it the active window. It will change
the color of the taskbar entry to
indicate that the window has changed
in some way. This is because Microsoft
does not allow an application to
interrupt what the user is currently
doing in another application.
However, Skype appears to defy this rule. If Skype is running but is not the active application, I can launch it from the start menu and it brings the existing instance to the foreground, activates it and grabs input focus.
And how can I do this?
(NOTE: This is specific to how QtSingleApplication works)
The solution is stupidly simple for my issue. Simply call AllowSetForegroundWindow(ASF_ANY); at the beginning of the application, and the original process will thus be allowed to bring itself to the foreground by use of SetForegroundWindow(). No strange hacks, just one line of code to add and no need to modify QtSingleApplication either.
I don't think you can do it reliably with the Qt API alone.
There are multiple solutions for windows. E.g. here, and here, and here.
The method I've used before is to declare a shared memory section, and write the application's window handle there. Later, when a second instance of your program is started, you can find the window handle of the first and activate it.
I don't think you have the issue of windows preventing you from doing this in this case, because your second instance is the active application, so it is allowed to 'pass focus' to other windows.
Use Single Application in Qt Solutions
For some applications it is useful or
even critical that they are started
only once by any user. Future attempts
to start the application should
activate any already running instance,
and possibly perform requested
actions, e.g. loading a file, in that
instance.
you can set the setWindowOpacity from 0 to 1 .the only thing is you may open it all the time
Related
I have added a .Net windows form inside a saleslogix windows plugin, every thing is working fine but on pressing the "Tab" key inside this control, instead of going on the next textbox the control goes to next plugin.
I have searched it a lot and can not find a work around for this, when I added a browser control in another saleslogix windows plugin, the page inside this textbox has multiple text boxes in it. To my surprise on pressing the tab key it worked perfectly and control goes to the next text box.
Any help is much appreciated.
That's an entirely normal mishap when you use Winforms (and many other UI class libraries) in a host application. Navigation keys, like Tab and the cursor keys as well as shortcut keystroke keys, need to be recognized regardless which control has the focus. One way to do so would be to implement the KeyDown event handler on every single control. That's excessively painful of course.
So it doesn't work that way, the keystroke is recognized when it is received by the message loop, before it is dispatched to the control with the focus. Overriding the ProcessCmdKey() method is the general way to do this. The base method takes care of navigation and recognizing menu and button mnemonics.
Problem is, it isn't the .NET message loop that is receiving and dispatching messages. It is the host application that has the loop. And it doesn't know beans about ProcessCmdKey(). So it doesn't get called and navigation doesn't work.
It tends to work in a WebBrowser because it is an ActiveX control. Which is designed to interact with its host. In particular it negotiates to decide which one gets to process the key. The IOleInPlaceActiveObject::TranslateAccelerator() method does this. Not the kind of plumbing available in .NET and host apps are rarely written to provide an alternative.
You could consider the "excessively painful" solution but pretty unlikely you like the sound of it. There's only one other decent way to fix this, you must call ShowDialog() to display your form. Now it is the .NET loop that dispatches and the Tab and cursor keys work fine. That tends to be unwelcome advice, dialogs can be pretty awkward. If you are lucky and know what you're doing and the host can deal with it (usually not) then using a thread can take the sting out of the modality. Asking the vendor for advice, particularly the threading aspect, would be wise.
I'm doing an automation script for installation wizards using AutoIt. I'm trying to handle window changes in some way.
Can some one explain how these GUI's work?
When I click on the Next button it looks just like the components in the GUI is beeing changed. Is this tha case? Or is a new window created and the old destroyed?
I've noticed that the process ID is the same for all windows.
I'm sure there is some way to know which "state" the GUI is in, or which step?
By the way. All the windows has the same title.
Thanks
/Anders
This will be dependant on the program you are automating.
The easiest approach would be to look at what changes in the GUI between stages, likely candidates are if there is a label that is giving instructions for that step, or a button that has text changing (e.g. if the button says "Finish" then you know your at the end).
Most installer programs have child windows for grouping the controls of each stage. These are typically implemented as dialog resources (as can be seen when using something like reshacker on them). So although the window remains the same, the panels are being created/destroyed as appropriate. This is a very neat method of doing it, for the obvious reason that you don't need to have to code to create/destroy a lot of controls. Resource created dialogs don't have nice class names like windows sometimes do though, so this may not be a reliable way to check the state.
I know it's possible to take a dialog that you built yourself and parent it on another form. But is it possible to parent a standard Windows system dialog on a form that you designed?
Specifically, I'm trying to set up a form with multiple tabs that provide different ways to obtain a reference to data used by the program. One of those tabs should represent the file system, and the ideal way to do this would be with the standard Open dialog that can be instantiated with the COM identifier CLSID_FileOpenDialog.
Is there any way to take a system dialog and cause it to appear parented on another window, without the border, title bar, etc?
There are ways to use a hook, either via SetWindowsHookEx() or SetWinEventHook(), to grab a system dialog's HWND, then you can do whatever you want with it, such as call SetParent(). But just because you CAN does not mean you SHOULD. System dialogs are designed to run as their own windows, not embedded in someone else's window. A better solution might be to use the same Shell display components that are used by Windows Explorer (and system dialogs) via IShellFolder::CreateViewObject() or SHCreateShellFolderView(), or find a third-party solution that does the hard work of interacting with the Shell for you.
This is a very general question:
I was wondering whether it is possible to find out whether an application (any kind of application no matter if it a delphi-application or java or whatever) was started by a user or by another application? And if it is possible and I see that an application was called by another one, can I find out what the "father" application is, that called the new programm?
Thnx in advance!
EDIT: Maybe it is too general - How can I see whether a Delphi application has a parent application with Delphi itself, e.g. one application was started by a service and I need to find that service?
Every single running application has a parent application, which launched it (except for root system process).
It is not possible to tell, whenever it is user who directly clicked on application to lauch it or not.
Example: take Explorer shell (not Internet Explorer).
You can double click on any application to launch it. The parent process will be explorer.exe.
You can right-click on any file and a bunch of context menu extenders will load. Some of them may launch external applications to, say, create a preview of video-file (I saw this, swear!). The parent process will be explorer.exe, but user didn't indended to lauch any application. He just wants to view file's properties. He didn't even know, that applications were lauched!
Example: take Total Commander or any other two-panel file managers, which supports plugins for archives.
You can double click on any
application to launch it. The parent
process will be totalcmd.exe.
You may enter archive file and copy
(extract) few files from it to your
Documents folders. Corresponding
plugin may handle extraction by
itself or run invisible process to
handle all work. All you see is
progress bar in Total Commander. But
there is a new proces and its parent
is totalcmd.exe again.
There are no differences between cases 1 and 2 in both examples.
BTW, the definition "started by user" is unclear. You even may say that nothing can happen without user's command. All those background processes in cases #2 were launched because user asked for it. Well, user didn't asked for lauch explicitly, but he asked for operation itself.
You don't mention if you want to do this programmatically or if you're looking for a tool to just show the information.
If you just want to view the information, you can use Process Monitor, part of SysInternals:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
In the Tools menu, there is a 'Process Tree' view that shows you a tree with parent / child process relationships and as well as the owner of each process.
If you want even more detail about processes, look at Process Explorer:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
if it started by the user from windows so the parent will be explorer.exe, otherwise the parent will be the application which run the process.
to check the parent of a process by using tool check Ander Miller reply.
Did you see this question?
I'm not sure that I see problem right now.
I am currently working on a program to immediately clear the list of previously-run-commands which appears in the Windows Start -> Run dialog. The procedure for clearing this list by removing the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU key is well documented; however, before these changes take effect, it seems to be necessary to do one of the following:
Restart the computer
Select Start -> Shut down, and then select Cancel.
Neither of these is ideal for the task I am trying to accomplish: #1 is extremely disruptive to the user, and #2 appears to require additional user interaction.
Does anyone know how to immediately (and programmatically) force a reload of this information without requiring any user interaction, while also minimizing disruption of the user's other activities? I would like for the user's Run history to be cleared out immediately after executing my program, without requiring any further action on their part (such as using the "Shut Down" -> "Cancel" trick in #2 above) or forcing a reboot.
Or, to approach the problem from a different angle: When clicking Start -> Shut Down -> Cancel, Windows Explorer reloads the RunMUI key. Is there a way to force a similar reload without having the user select Shut Down and then Cancel?
Things I have already tried:
Monitoring the explorer.exe status using procmon while selecting Shutdown and then Cancel. I see Explorer writing to the RunMRU key, but have not been able to determine what triggers this.
Numerous Google searches along the lines of "reload runmru without reboot". Most results still recommend method #1 above, although a few suggest #2.
Limited MSDN API examination. The RegFlushKey call appears promising, but I haven't ever used it before, so I don't know if it will apply to registry information cached by different processes.
Any suggestions or other information would be greatly appreciated.
Have you tried ccleaner?
http://www.ccleaner.com/
Not a full answer to your question, but I did find a third way to trigger the clearing of the run command from this article in PC Mag.
Killing explorer.exe and then restarting it will also clear the run list after the registry modification.
I have a nasty hack for you. Show the window programatically, hide it immediately (programatically) and click cancel on it (well, you guessed, programmatically).
You might try looking for the icon cache flush API, or other ones, I wouldn't be too suprised if they had side effects like the one you are looking for.
I've seen instances where it actually works, even the F5 key doesn't work? Try this, ctrl>alt>delete then go to task manager, processes tab...end explorer.exe. Then click on file new task and type explorer.exe, then check...does that work?
Windows XP
Right click on the taskbar
Properties menu option
Start Menu tab
Customize button
Programs pane
Clear List
Click on OK
This calls a Windows API function that refreshes the explorere.exe taskbar process and also clears the list (no need for registry edits).
As far as I know, it relies on the explorer.exe process that hosts the start menu/taskbar/desktop being closed and reopened. There is no "clean" way to do this that I am aware of.
If you really need to do this without user interaction, you need to close all explorer.exe processes and relaunch one.
Here's a rudimentary C# program to do that;
using System.Diagnostics;
Process[] procs = Process.GetProcessesByName("explorer");
foreach (Process proc in procs)
{
proc.Kill();
}
Process.Start("explorer.exe");
Note that this will close all "Windows Explorer" windows open, and may or may not open an additional "Windows Explorer" afterwards.
I just tested that on Windows XP 32bit, and it did indeed clear the Run command cache.
HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ RunMRU\