I am new to Installshield and I want to display the banners displayed in the dialogs during installation to be fetched dynamically from an external folder which resides in the path of the setup.exe (not part of the installation) using Installshield Basic MSI project.
I tried specifying the “File Name” for the banner bitmaps in the dialog as <SETUPEXEDIR>\MyLogo\Test.bmp. But this gives an error as “File not found. Error streaming file to binary table.” when the project is built.
Is there a way possible to achieve this?
Windows Installer requires that the images are baked into the .msi file in order to display them (it saves the bits, not the name, in the Binary table), so it's very reasonable to summarize this as not supported.
As a possible workaround (one I'm uncertain whether it can work), it's feasible that a custom action could write temporary records to the Binary table or Control table that containing the image found at run time. Note that this sort of custom action is somewhere between admitting failure and a semi-custom action. Furthermore finding the image, dealing with incorrect image sizes, determining which dialog boxes need the added image Binary or Control record, and possibly deleting an existing Binary or Control record, are left as exercises for an eager reader.
Related
As far as I understand, APEX 5.1 does not support Excel files to be loaded into tables.
I found this package that seems to make it possible to SELECT from Excel files, but it does not show how to use it with, for example, files loaded via the "File Browse" Item.
Now, I am very new to this environment, so please explain it from the beginning.
What I did is I upload the package script to the SQL workshop and executed it, without errors. But now?
APEX 5.1 doesn't support it out of the box, but you can use the EXCEL2COLLECTION plugin (available here).
It is very straightforward, just create a file browse page item with an upload button which calls an onsubmit process (e.g. CreateCollection) of type Excel2Collection[Plug In] - specify the file browse item, a collection name and the CSV separator, then you can do as you please with the data (e.g. you may want to run some validations on the data then insert it into a table where you can access it as normal).
I am currently trying to expand our installation program with an option for the user to specify the name of the program group where shortcuts are created under the start menu. (I am aware that this is a somewhat outdated concept)
I am using InstallShield 2015.
I created a localizable property named [PROGRAMGROUP_NAME]. This has automatically created an {ID_STRING46} which I've set to the desired default value. So far so good.
I managed to create a custom dialog with an edit control, which is linked to the above property.
Now comes the tricky part: Under Shortcuts, under "Programs Menu" I first want to add a folder with the program group name, under which to place several shortcuts.
If I enter [PROGRAMGROUP_NAME] that is literally what the name becomes. If I use {ID_STRING46}, it uses the default value, and not what I've entered in the dialog.
Incidentally, when I tried to rename ID_STRING46 to something more meaningful, other things started going wrong so I've left that as is.
What is going wrong here? How do I get the value of the property to be used for the folder name?
EDIT
I am trying to use a custom action now, but I have trouble defining it. My Dialog that sets the property is after CostFinalize, so I assume I have to use SetDirectory - but I have trouble defining it. I get an error stating "could not access network location "
EDIT
I've managed to progress a step. I have manually added a directory with key DIRECTORY_PROGRAM_GROUP (important that it's all caps to make it public) to the directory table. Then, I use a custom action to set that directory to the desired value [ProgramMenuFolder][PROGRAM_GROUP_NAME] after I've run my dialog, and I've modified the shortcut to be created in that folder.
Seems to work great, however, now the program group is no longer removed when uninstalling...
Shortcuts are installed to folders, and the name of the folders below ProgramMenuFolder become the program group as you describe it. So you will need to either build up the Directory table (either directly---note that the DefaultDir column is localizable, and there may already be a string you can update---or through the Files and Folders view) to do what you want, or use custom actions (set property, if before costing; set directory, if after costing) to adjust the location to which your shortcut is installed.
As for the problems renaming ID_STRING46, odds are you didn't update a reference after you changed the name of the string. The simplest way to track down where these are may be to examine differences in the built installer (perhaps using InstallShield's MSI Diff) and then update the relevant references using the direct editor if you can't find them in the normal views.
I am creating an installer for a 64 bit application that includes thousands of 3rd party DLLs (~2000)
According to InstallShield best practice, each DLL must be in a different component.
(from the doc)
"Each component should contain only one portable executable file (an .exe, .dll, or .ocx file) or WinHelp file (.hlp file)."
So I have thousands of Components that I need to change the "64-bit component" property from "No" to "Yes".
The component wizard does not let me do this when I create the components.
Question: Is there a way to do a multi-selection of all the components to be able to change the property for all components at once ? or do I have to manually select each component and change the property ?
Note: I know that if 1 component is marked as 64-bit, then the installation will be "64-bit" aware.
Thanks.
There is no support for multi-selecting the components and editing them. However there are at least three workarounds with varying levels of ease.
Modify the Attributes column of the Component table in the Direct Editor. In the common case you will be replacing a series of components with the value 8 (msidbComponentAttributesSharedDllRefCount) with one that also includes 256 (msidbComponentAttributes64bit). If that is the case, you can just modify them in bulk to 264.
Use the automation interface property ISWiComponent.Attrib64BitComponent to modify your components by using a script.
In InstallShield 2016 or later, before creating the components, set MsiComponentAttributes in the InstallShield table to a value such as 264.
Note that before taking the time to modify all the components to be 64-bit, you should make sure that you need to do so. If these components only install a DLL to a 32-bit file location, and do not install registry keys to any 64-bit registry locations (that includes COM extraction; if you're using COM extraction on these files, they likely do have 64-bit registry keys and thus need to be 64-bit), there would be no need to mark them 64-bit.
Once you've confirmed you need to change them, note that if you've previously released the package with a 32-bit variant of the component, you also need to create a new GUID for the component, as part of following component rules.
Note as well that (as you mention) once you mark any component as 64-bit, you are required to mark your entire package as 64-bit, and it will no longer install on a 32-bit machine.
I have created an application and associated on registry a file extension on Windows 10, so when you double click a file associated with my extension, it opens my app with the file as parameter.
Now, I want the files associated to my application to behave in Windows 10 just like images - I mean, having a thumbnail preview, so when the user selects "large icons", he would be able to see a preview of the file.
I wonder how can I do it. What kind of metadata my file should have so Windows would recognize it and show a preview. Of course, I don't want just large icons, I want a file preview just like image files.
It isn't hard for me to generate a preview bitmap and integrate it to the file format I created (or even to change the file format completely, since I didn't publish anything yet), but how would windows recognize it? Is this even possible?
Thanks in advance
After some research, I found a sample code that does exactly what I need. It creates a thumbnail provider, which have access to the file's contents (binary), and then I can use it to generate the thumbnail of the file.
The sample that creates a IThumbnailProvider can be found here:
https://code.msdn.microsoft.com/windowsapps/CppShellExtThumbnailHandler-32399b35/view/SourceCode#content
The project should generate a dll, that we should register on Windows. It might be done using the following lines:
system32/regsvr32 ThumbnailProviderx64.dll
syswow64/regsvr32 ThumbnailProviderx86.dll
unregistering is like this:
system32/regsvr32 /u ThumbnailProviderx64.dll
syswow64/regsvr32 /u ThumbnailProviderx86.dll
Another nice sample could be found at:
http://www.codemonkeycodes.com/2010/01/11/ithumbnailprovider-re-visited/
We have Installshield 2009 for our product. I am trying to muddle my way through it to make some updates (obviously, I am not the original author).
Within, there is a fairly complex arrangement of components and files, plus, there is a script section for some custom work.
I need to accomplish the following, without creating a blank object in the repository.
One of the components needs to create a directory tree (two folders deep).
Within that tree (deepest folder), I need to create a blank file.
Questions:
Do I need to create two components, one for each directory level, or will the tree be created if I specify [INSTALLDIR]folder1\folder2?
I am thinking that the installscript would be the place to create the empty file, based on the CreateFile example in the help. I notice that, in the components page, that, once I typed the value for the Destination property, that a little "tag" of sorts appeared at the start {FOLDER2}. Can I used that tag as an argument to CreateFile and how would I reference it?
Regardless of the project type, I would probably suggest creating the folder structure in the Files and Folders view, and adding the empty file there. It's just simple and you'd be done with fewer chances of error.
As to the questions you asked, neither Basic MSI nor InstallScript projects require components for every folder level on the system. Note that if the folder isn't already there when it executes, the CreateFile approach is unlikely to create the folders for you.
In a Basic MSI project, {FOLDER2} indicates that FOLDER2 is the name of the directory entry, and after CostFinalize there will be a property of the same name that contains its run-time location. You can retrieve it in an InstallScript custom action with MsiGetProperty. In a pure InstallScript project the approach would be a little different, worst case it would be something like TARGETDIR ^ "folder1" ^ "folder2" (my InstallScript is rusty).