I'm creating an installer at work that must open a file browser. There is no file browser in wix, so I built a custom vbscript action that uses the Shell.BrowseForFolder method. It's working fine, but the file dialog shows up behind the main wix window. Does anyone know a wix/vbscript approach I could take to solve this problem?
Locate the HWND for the MSI UI and pass this into Shell.BrowseForFolder. I see a few example solutions that use FindWindow("MsiDialogCloseClass", vbNullString). Be careful about launching UI from a custom action: you need to consider silent installs/repair/uninstall, etc to make sure you get it right in all cases.
It looks like you're trying to allow the user to pick a directory. MSI has native support for this. I reccomend you use that. For an example see http://wix.codeplex.com/SourceControl/latest#src/ext/UIExtension/wixlib/BrowseDlg.wxs.
Related
I am using WiX and want to know if we can disable a control in a built-in dialog. My requirement is to disable the "Browse" button in the "CustomizeDlg".
This became too long for a comment. I might "evolve" it as an answer if we get more information about your scenario. Just a couple of heads-ups for you.
If you are trying to prevent the setup from being installed to a non-standard path, then you should account for the fact that the installation directory can be set at the msiexec.exe command line when the setup is installed in silent mode. Sample (untested by me - first thing I found :-) ).
I suppose a custom action could be used to abort the setup if it is installed in silent mode to a non-standard path? An immediate mode custom action before InstallInitialize somewhere I guess, but after costing actions (CostInitialize, CostFinalize, FileCost, InstallValidate, etc...) - but frankly, why do this? Perhaps you could illuminate your use-case?
Oh, and please don't leave the standard action RemoveExistingProducts to run before your custom action (in the InstallExecuteSequence). This would remove the existing, related installation on the box (if any) and then abort the major upgrade operation leaving no install left on the box.
And don't add your custom action to the user interface sequence - there is no need. This sequence is entirely skipped in silent installation mode, and if there is no way to set a custom path in the GUI, it can't be changed there anyway (and the InstallExecuteSequence's custom action would catch any changes should they be set anyway - it will do).
Per this thread which discusses how to enable the button, what you need to do is the reverse: ensure your Feature elements do not specify a ConfigurableDirectory, or that it is not public by using some lowercase letters in the identifier.
I am looking into adding a link to my app to the Explorer (windows) context menu. I've looked around for how to do this. I have done it and it works just fine by adding a key to
HKEY_CLASSES_ROOT\*\shell
Searching the web I found this:
http://www.codeproject.com/Articles/441/The-Complete-Idiot-s-Guide-to-Writing-Shell-Extens
But this seemed so simple (the *\shell method)
http://www.howtogeek.com/107965/how-to-add-any-application-shortcut-to-windows-explorers-context-menu/
HOWEVER no app(on my computer) does this (HKEY_CLASSES_ROOT*\shell) and I wonder if this is not the best solution. I think most apps I have use an inproc dll to work with Explorer. I don't know if that's why they don't go with the *\shell method or there's some other reason why this is not the best way. I could convert my app to an inproc dll if I had to but that seems unnecessary to me if I can use the *\shell method.
OF COURSE the big reason is that I have to logged in as Administrator to do this (*\shell). I was thinking of adding a separate little file that the admins would run. Which seems like a better way in a corporate environment (or any where users are not logged in as admins).
I am a bit of a beginner at InstallShield (in the sense that this is the first time I've used it!).
I have some code that I am packaging up in a .net DLL to check for the existence of anti-virus. The installer I am attempting to create must check for anti-virus (by calling a custom action using my DLL?) and cancel the install if none has been found.
The way I seen it working, was the user would see a dialog that is informational ("about to check for anti-virus"), the user would press "Next" it would call the custom action and then show a success screen with a "Next" button, or a failure screen with "Finish" button.
Is this sort of thing possible with InstallShield? Are there any good tutorials out there for doing this sort of thing?
Do you really need a custom action? Do you have more detailed requirements with regards to what products and versions you are looking for?
InstallShield / Windows Installer has a built in search pattern that can look for registry entries, files, et al.
If you really do need a custom action, how long do you expect the execution to take? If it's only a couple seconds, just schedule it to run after AppSearch. You don't need a UI to say "now doing blah" just do it.
Since you want to do this in .NET, you need to look at Windows Installer XML (WiX) Deployment Tools Foundation (DTF). You can use this to author/compile custom action DLL's that InstallShield can then consume. Generally the custom action should do it's search and then set a property based on it's result. Then use that property in evaluating whatever business rule you are trying to implement.
I am developing a WiX installer (I am very new to this) and want to implement a method (like launch condition) which check if a particular application is running or not. If it's running then a warning message will popup displaying close the application message. I want this check before the welcome screen.
How can I implement this? Some working example will really help me a lot.
Windows Installer already has a FilesInUse and RMFilesInUse (Restart Manager) support. Does this not meet your needs? With these patterns you'll get a dialog telling the user that they need to exit a program or risk needing a reboot.
This can be done only through a custom action. Here is a tutorial for a C++ DLL native custom action: http://www.codeproject.com/Articles/1747/MSI-Custom-Action-DLL
Your custom action can perform the check and then show a message to the user if necessary. It
can return 0 to continue the installation or 1602 to stop.
To show the message before Welcome dialog, you can try scheduling your custom action right after CostFinalize action in InstallUISequence.
Here is my app status:
Purpose - download multiple list files from internet
Approach - created a simple "download form". After a while, I just needed more forms because I had more than one list of files to download. Just solved that by adding a MDIform to my project, add a button to create another "download form" instance and voilà. Apparently, my problem was solved. But no :(
When I press my "download" button in my form-instance3, the other form instances (2 and 1) hangs on downloading the contents (I get a timeout sometimes) until the form-instance3 terminates all the downloads and so on, for all the other forms. So, even though I know my app is not multi-threaded, the multiple instances of the same form are in conflict (Inet component, presumably) and I can't download multiple files at the same time.
Inet and my download function are defined in the form.
What can I do to solve this? how can I download multiple files at the same time?
edit:
I'm trying to use the "wqw" suggestion, but I'm facing some problems:
In the download_form, I have a MSHFlexgrid, with 2 columns: one with the URL and the other with the file destiny. I was iterating throw all rows to download the files and save them. With the approach suggested by "wqw", how can I distinguish each download so that I can save it with the properly name indicated in the grid?
What do you use for the actual http download? I would try Simple Asynchronous Downloads and forget about the MDIForm. Really!
VB6, on its own, is single threaded. So breaking out downloading to different forms won't help you.
What I've used in the past is the Timer object in conjunction with an ActiveX EXE. This approach will give you an ability to localize all the downloading logic in one place, control it like you control a regular object and have it run in a separate EXE, thus by default making it multi-threaded.
So the way this works is like so:
You call the Download method on the ActiveX EXE object
In the download method, you instantiate the Timer and have it kick off almost immediately.
You get out of the Download method, thus giving control back to the entity that called it.
Then you communicate back to the main app via Events (e.g. DownloadProgress or DownloadComplete, etc...)