I have tried two installers - Setup2go, and Installmate Builder, and I have the same problem. At the last window of the install, I select the option to "Open program after installation finish", and sometimes (about 10% of the time?), my (Winforms) app's main window will open behind the Windows Explorer directory window I used to open the installation exe from.
The frustrating thing is - I am having trouble reproducing the problem reliably (the problem seems to occur around 10-20% of the time). I am using Windows 7 if that makes any difference. To clarify, if I open up the executable directly (rather than from the installation exe), the problem never occurs.
My knowledge on this kind of thing is limited - I recall a similar frustration happening with the MessageBox from this question
Any ideas?
It does not happen when you launch the app directly from installer because the shell allows it to “steal” the focus. When you launch it from the installer, the last interaction happens in the installer app. The system prevents the new window from stealing the focus from your installer. If installer window closes, then the explorer window which you used to start the installer is activated. Since the switch of the foreground window happened recently, the system does not allow to change the foreground window.
On the other hand, if your application window is shown before the installer window disappears from the screen, the the app will be placed below the installer in the Z-order; and when the installer window is finally hidden, the application window is activated.
So it's all related to timing between showing and hiding windows.
Although I am not expert in this area. You can use message tracers and WinAPI calls tracers like Spyxx which can give you more details on what happens in the system and why the new window of your application is placed below the Explorer window.
Make sure the window's title isn't changed, until the last possible moment. I moved the Text = "blahblah" line out of the Form_load event, and into the Form1_Shown event, and now the hidden taskbar icon problem has vanished. Also, the window doesn't flicker when it's loading.
Related
How to write a WinForms application that would not have any visible element except from a tray icon and at the same time allow the application to be closed by Windows Installer if the file is in use? As I understand it the Windows Installer sends a WM_CLOSE message to application's main window. I assume that the "main window" is indicated by MainForm property of ApplicationContext. Also it seems to me that for this mechanism to work the form must have been shown at least once.
I found some workarounds like creating an empty form and setting its opacity to 0 (to minimize flicker) then showing and hiding, but describing this as a nasty hack would heavily underestimate its ugliness.
Windows Installer does not send any WM_CLOSE messages. This might help:
http://haishibai.blogspot.com/2010/02/complete-tutorial-patch-restart-your.html
It's a slightly different scenario but might get you started if you want Windows Installer to tell your app when it should close down.
On recent operating system versions with Restart Manager a tray app will be detected. Back on Windows XP it wasn't detected.
In the WiX world there is a CloseApplication utility custom action that will send WM_CLOSE to the app window.
I'm developing a program in c# im stuck with this issue.
I want to show dialog box which refers to a particular directory.
I know that there is OpenDialogFolder and SaveDialog, but I don't want to save or open any files what I want is just to open a specific directory dialog box.
Like this screenshot:
It looks like you just want to open a copy of Windows Explorer. You can do that by simply calling Process.Start() and specifying just a folder path with no filename:
Process.Start(#"C:\Temp\");
The default behavior of the Windows shell, given a command like this on the command line (or a shortcut or a Run command) is to open Windows Explorer to show the contents of the specified path.
Now, Windows Explorer is an external process, which you are launching and then letting it do its thing. It therefore won't behave exactly like a modal dialog box, like preventing the dialog losing focus to another window. However, you can mimic the "can't do anything else with the application" behavior of a dialog by assigning the result of Process.Start (a Process) to a variable, then calling the WaitForExit() method on that Process with no parameters. This will block the application's main thread until the user closes the Explorer window you opened. It's not perfect; by blocking the thread, the application will not respond to any requests to draw itself or do any other basic things that even a dialog-interrupted window will still do, and you can still technically "activate" the window you used to launch Windows Explorer which will bring it in front of Windows Explorer. The Explorer window can also be minimized (something dialogs don't normally allow) and there isn't much you can do to prevent that.
I've written a relatively large application with lots of dialog boxes and forms, etc.
I'm opening them with Form.ShowDialog().
A lot of the time, the forms open behind existing windows, e.g. yesterday I was testing it on a machine with several other programs open: many Windows Explorer windows, a few Excel windows, etc. A lot of my forms, open/save file dialogs, etc were supposed to open but didn't. I was twiddling my thumbs until I pressed alt+tab and realised that they were, in fact, behind another window.
Why is this happening, and how can I stop it in future? Thanks.
Use the ShowDialog override which takes an owner window as a parameter.
By passing in your main window as the dialog's owner, you guarantee that the dialog always pops in front of it, and stays in front of it.
And it won't annoy the user if they were using some other application.
When the user clicks the window title/button in the taskbar, what .NET event (or Windows API message) is sent to the window?
I'm using C#/.NET 2.0/Windows Forms.
Thank you
To discover the messages that are send to a window at various points you should consider using Microsoft Spy++. On my machine it is located at the following path
"D:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\spyxx.exe"
Note I am using 64bit OS hence the (x86).
The type and number of messages is quite big and I am sure varies slightly between OS versions like XP and Windows 7. However the key events/mesages would probably remain pretty constant.
WM_ACTIVATE (When activating and deactivating)
WM_WINDOWPOSCHANGING
WM_WINDOWPOSCHANGED
etc.
Another good tool is ManagedSpy, but I have not tried it on anything other than XP, it does not seem to run on Windows 7 64bit, but I have not done much investigation (Yet!).
http://msdn.microsoft.com/en-us/magazine/cc163617.aspx
The Activated and Deactivate events usually occur when you click on the taskbar button, but not always. They also occur when you just click on the window or click away to another window.
The one time I found that they don't occur is when the window is active, you click on the taskbar button to minimize the app, and Deactivate occurs as well as Activated. Then when you click on the taskbar button to restore the window, the Activated event doesn't fire. This seems weird to me.
I have to stop applications when the window is closed. The window stays in the memory when click the (x) button. How can i remove the app in memory? Also another question is that i want the application to be installed when hard restart the pocket pc, how can i do it?
Thanks
By default the form will just hide when you click the X in the top right. You need to set the "MinimizeBox" property of the form to "False" for the application to close instead.
Installing the application on hard restart (often referred to as cold boot) requires that you put a CAB file for the application on the flash (persistent) memory of the device. You will then normally have to write a script and place that somewhere to call the CAB. This can vary from device to device so you'll have to look that one up.
Setting the form's MinimizeBox property to False causes the OK button to appear.
The Ok button is for closing the application instead of minimalizing
To prevent to application from minimizing which is the default behavior for PocketPC applications, set the MinimizeBox option to false on the form.
As for your second option that might be trickier because it depends on the PDA. If it has persistent memory you could put it there, and find a way to run the CAB file during initialization.
[Update]
It would appear that there is a Startup Folder in the windows menu. Perhaps you could write a utility that checks if your application is installed and if not launches the CAB installer.
The default behavior is indeed minimizing the application. Using a custom task manager which replaces the [x] you can tune this behavior. Some vendors (for instance HTC) include a custom taskmanager exactly for this purpose.
A generic but good task manager is WkTASK, here is the relevant feature description:
X button
Using the X button, you can
use some actions as follows:
Tap: really close
Tap&Hold: show context menu
Drag: some gestures (To show a program launcher, drag toward down. To
show Today, drag toward left.)
WkTASK offers a lot more, but you can fine tune it to do only what you want.