I'm using Microsoft Visual Studio 2010 to create a simple .MSI installer for my simple .EXE application.
Trouble is, things go wrong (until a reboot) if you install an upgrade while the .EXE is still running.
I'd like for the .MSI installer to terminate my process before installing/upgrading.
Please could someone tell me how to do this in Orca?
EDIT: I've seen this occur due to my .EXE being in use, but I've also seen it because the .CHM help file was open at time of upgrade as well, so any process termination alone is not enough to solve this problem.
You should ad the MsiRMFilesInUse Dialog to your installer.
You can try creating a custom action which stops your application (a custom EXE or DLL written by you). For example you can send WM_CLOSE to the main application window (your application should handle this message).
This custom action should be scheduled before InstallValidate action in InstallExecuteSequence table.
You could write a custom action that closes your application as well as your help file.
You should be able to find the window handles for both of these by using FindWindow:
http://msdn.microsoft.com/en-us/library/ms633499(v=vs.85).aspx
For the executable, you should be able to use the appropriate Window Class or Title for FindWindow.
For the help file, you should be able to use the appropriate Help Window Title for FindWindow.
I hope this helps!
Related
I created an MSI installer project in VS2015, set up everything, then added a file extension associtation with the "File Types Editor", assigned my extension to my application, as an Open command.
The COMMAND was the application from the "application folder", the EXTENSION was set, then the &OPEN was set as NAME=&Open, Arguments="%1" VERB=open. Nothing else.
I generated the .msi file, then started. At the end of the installation, I found out that in the registry Computer\HKEY_CLASSES_ROOT\\shell\open\command key there were two item, one is (Default) REG_SZ with value "myexe" "%1" as I expected
Unfortunately there was another item: "command", "REG_MULTI_SZ" and the Data was something weird, for example "LZ*a!t4(v=++Tt$)tOk_>[1jfrS!,nB`L6ciHLW!, "%1"" which I don't know what it is. When I delete the .msi file, and double click on a file with my registered extension, a popup dialog appears as "network resource cannot be found" and Windows wants my .msi installer back (browse dialog comes in)! I don't know how to prevent this unwanted situation. :( Any help would be highly appreciate!
Windows Installer uses so-called Darwin Descriptors to implement resiliency, wherein a corrupted installation can be repaired automatically. Your attempt to delete the .msi rather than to uninstall it acts like a corrupted installation, so the system attempts to fix it. However, since the .msi itself has been removed, it has to ask for help.
The short answer here is to suggest that you not worry about the exact values in the registry key. Since you're using an Extension table instead of a Registry table entry, the registry is an implementation detail; you should prefer to ignore such detail. Instead, if after a successful installation your program launches as expected upon double clicking the associated file, and it stops doing so after properly uninstalling your application, all is well.
We have a VB6 application here that automates the process of opening drawings and printing them with a specific printer that turns them into TIFF files.
I'm in the process of testing the application as we upgrade from V8 to V8i and I'm running into some problems just launching the application.
If I open the Microstation normally via the exe file everything works ok. But when I do:
Set msApp = CreateObject("MicrostationDGN.Application")
It opens a blank microstation window with no menus or anything (basically what the window looks like behind the file open dialog)
And then I do
msApp.OpenDesignFile ("dummy.dgn")
that looks like this: imgur.com/A5rc4.png
Is there something new with v8i where it doesn't bother loading the gui when opened as an object?
Did your application depends on some user preference of Microstation? I think you can debug your aplication step by step.
You can call the ustation.exe with the parameter -debug. This creates a file called debug.txt in the current working directory.
There you might find some helpful info.
We have an installer wizard (written in .NET) which configures and kicks off a series of standard Windows installers. The installers are run silently. Right now, clicking "Cancel" on the wizard's dialog stops further installers from running, but does not stop whatever installer is running silently in the background.
Is there a way to send a installer running silently the equivalent of pressing the Cancel button on a non-silent install? (I could kill the installer process, but I expect that that will leave a half-installed (and probably non-uninstallable) mess behind.)
I'm not sure if you're creating new instances of these installers within your own installation wizard so I don't know how applicable this solution is going to be, but if you do have access to the actual (derived) System.Installer objects that correspond to the installers, calling the overridden System.Installer.Rollback() method of those objects should achieve the desired result. Let me know if this doesn't work and I can try helping you further.
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
I am working on a Windows application which needs to be able to update itself. When a button is pressed it starts the installer and then the parent application exits. At some point during the installer, the installer attempts to rename the directory that the parent application was running from and fails with "Access Denied" If you run the installer from the desktop it works.
I am using CreateProcess to start the installer, is there some way of using this or another API to create the installer completely independantly from the parent application so that it doesn't retain some attachment to the directory.
I'm not convinced that launching the installer separately will solve your issue. It sounds more like a permissions problem that you might be able to solve using ACL manipulation. If the app doesn't already have permissions to mess with that folder, you might be able to write a custom action to remedy the problem by adding the necessary permissions to your process.
Another way of doing this is to make sure that the directory deletion is happening within a custom action that you control (as in, you own/maintain the code that performs the deletion, rather than rely on MsiExec to do it for you). Then, set that custom action to run in the System context so that it will have the same permissions as a service. That should provide your installer with sufficient rights to remove the folder.
You should use the normal update system within the windows installer.
your access denied message appears because file/directory is in use.
renaming directories isn't also not a good idea.
what happened if the user clicks "repair" or "uninstall" ?
you can start the msi with shellexec. after that terminate you app immediately.
you should check that in the msi that your app is NOT running anymore.
do the update. if a file is in use the installer automatically wants to reboot to replace the stuff.
CreateProcess should work if you are passing it the right parameters. Don't reference the parent process in any way and set most things to NULL. If that doesn't work, then you can try WinExec().