I am trying to populate a combo box in Installshield with a list of network adapter names on the local machine. I'm trying to use a vbscript custom action which I modified a bit from here : http://community.flexerasoftware.com/showthread.php?t=188130
MsiRecord.StringData(1) = "REGION" 'The Name of the Property
I seem to be getting an error on this line, and the installation crashes. Any suggestions?
Since your talking about updating windows installer tables using VBScript custom actions this really has everything to do with Windows Installer and not much to do with InstallShield per say.
I don't think that example posted on the forums was correct. I'd suggest reading the following page to get a better understand and take a look at the Combobox and ListBox sample projects provided.
Using Dual ListBoxes as Replacement for a Multi-Selection ListBox
Personally I suspect the problem with the sample you quoted is missing a Set statement when creating the record. As I recall, and it's been awhile since I touched VBScript, you have to use the Set command when creating an object. But I really advise against using VBScript in Custom Actions. C/C++, InstallScript and C# ( using DTF ) are far more robust solutions.
Related
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.
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.
When automating excel using the Excel Interop API, I can easily do a range search using the method Range.Find. I am passing through the LookIn, LookAt, SearchOrder, SearchDirection, and MatchCase options for the Find. This as noted by the MSDN documentation, persists the values passed into this method into the user settings, so the next time that the user opens the find form, the options will be selected which I used in the Range.Find method.
I need to persist the values of the find options before and after I do the programmatic find. So I want to capture the current find options, then do the Range.Find, and then set the find options back to the options that were set before my search. However, I do not see that the find options are publicly accessible. Any ideas on how to get these?
I'm basically looking to retrieve current find option values for LookIn, LookAt, SearchOrder, SearchDirection, and MatchCase.
Update
The most interesting thing I could find so far is that you can access the Excel Application dialogs - Dialogs Interface. So here, I can get access to the FormulaFind dialog, which is slightly different than the Find and Replace dialog, though may lead to some of the properties I'm looking for. I haven't had any luck, but perhaps there's a way to access the properties through this form using reflection. I'll keep trying something with this.
// xlDialogFormulaFind, xlDialogFormulaReplace
Excel.Dialog dialog = this.Application.Dialogs.Item[Excel.XlBuiltInDialog.xlDialogFormulaFind];
Well, I am not sure if you'd consider this approach, but I'll give a shot here in case it might be helpful.
What I would do is, I'd create a registry key holding the values you wanted to persist. I could then call RegistryKey.GetValue(valuename) to retrieve values, provided that there's no exceptions thrown.
As long as that registry key stays there, unchanged, and you have enough privilege to access registry key, you should be able to always get the same values.
Wish we could really use application settings here, which would make it easier, but, well, as you might have known, vsto add-in doesn't like it, according to this article.
You cannot use application settings in an unmanaged application that
hosts the .NET Framework. Settings will not work in such environments
as Visual Studio add-ins, C++ for Microsoft Office, control hosting in
Internet Explorer, or Microsoft Outlook add-ins and projects.
Hope this helps.
I want to create setup for my window application in .net,in which i want to asked user to input custom connection string at time of installation.how can I do it.
after digging in the matter. I have created set up project for this. now i stuck up in it.
how to move further.
any tutorial on it.
If you are using Visual Studio setup project, you can try creating a custom dialog through which you get the connection information. Perhaps this tutorial will help:
http://www.codeproject.com/KB/install/vsSetupCustomDialogs.aspx
If you are using another tool, mention it in your post and I will edit my answer with some suggestions.
I'm working on a little macro record/replay tool which can automate a few very old Visual Basic 6 GUIs we have. To do so, I'm identifying the controls by their name (the value of the name property of a control, that is).
One part of this tool needs to determine the name of a control given its HWND. For newer Visual Basic applications which were done using VB.NET, I can use the WM_GETCONTROLNAME window message. This works nicely.
However, this message is not understood by older windows. Is there any way to do this for controls of Visual Basic 6 applications? A solution which does not require being in the process of the GUI would be preferrable, but if I had a solution which only works inside the GUI process then that would be acceptable as well (since I can do the injection myself).
UPDATE: One thing I just tried, this moderate success: I used the AccessibleObjectFromWindow to check for implementations of the IAccessible interface of the object which shows the given HWND. In case I get an implementation (it seems that many [all?] Visual Basic controls implement this interface), I use the accName property to read out the "accessible name". Sometimes this does yield a useful string, but usually it doesn't.
I believe the only way would be getting inside the process and obtaining a pointer to the Form object, yet I have no idea how to do it from outside.
Is it possible you add support for the WM_GETCONTROLNAME to those older applications?
Or maybe, you could identify the controls by some other, natively-available properties?
Other that that, as Raymond is saying, there isn't much you can do.
Can you modify the vb6 apps? if so in each form load event you could iterate me.controls and use the SetProp(ctrl.hwnd, "MYNAME:" & ctrl.name, 0) api to add the name to the window's own property list, then in your other app you can EnumProps(ctrl_HWND) looking for the one that begins with MYNAME: and parse out the value.