Things you might like to know about InstallShield Developer (version 8.0) before you break your head on it.
This is the knowledge I accumulated in the past three days of intensive shielding from installation. One of the nice things about InstallShield, and with it InstallScript, is that it has a great deal of functionality. This is probably why it gives people so much trouble. Basically, having come close to mastering InstallScript (with little choice in the matter), I found myself developing more and more complex algorithms. Often I would be missing other programming language features only to discover they were in there somewhere. It's got what you want. You just need to weed out what you don't. The only really useful thing it seems to be missing is Regular Expressions. Short of that it's got just about everything. One of its best features is that there is a lot in the help files, it isn't always organized and linked as thoroughly as it might be, but everything is there if you look around with just a little ingenuity.
InstallScript itself is a strange mutation of VB and C-like syntax. For someone who is familliar with both, you can pretty much guess how to do what you need, a glance at the help files every now and again will go a long way. One of the things which is most difficult to accept is that you can't return strings from functions.(Not with the return statement anyway, though you can return them ByRef.) I imagine you could use pointers (which InstallScript has) to do that, but really people, we're just installing files here. In that particular sense the language is surprisingly unabstract. It's lower lever than VB, but nothing like C. There are also many convenient functions, especially VerCompare which lets you compare version numbers.
It's not all fun and games. It took me a whole day to figure out how to properly add Custom Dialogs. Once you find the right help page (CtrlSetText example code) you know how the code is supposed to look, but there was no nice walkthrough that explained what settings needed to be set to make a Dialog which you could use with such example code. The example cops out and loads a standard dialog so it can teach you how to manipulate it. In this rare instance the help file is not your friend. This is why my agony lasted the better part of a day. Here are some of the secrets:
- If you aren't loading a Dialog from some strange DLL you've created because you are already a super-guru master installshielder, then you can ignore the DLL argument in the EzDefineDialog function. (Oh, side note: if you aren't a super-guru-master installshielder, no need to use the non-Ez functions when there are nice simple Ez- functions that can simplify your life. One big caveat: If you need the not-so-Ez functionality, use away. (Of course))
- Also ignore trying to use the szDialogID parameter, stick to the nDialogID, it actually seems to work. Here is the big secret: How do you set a custom Dialog's ID? there's no option to do so in the UI-Editing area which InstallShield provides. Instead, you need to go to one of the bottom tools on the left-side menu, named the Direct Editor. Sounds like that is the Nexus, the place where anything and everything is at your finger tips, right? Not so. There's a lot of stuff there which you can manually configure, but what ends up there and what doesn't seems arbitrary to this humble user. But, before you start to feel daunted, guess what can be found there: The Dialog's numeric ID. So, we go to the Direct Editor, set the Dialog's ID, and then...
- We can use the magic phrase:
EzDefineDialog("WhatYouWillCallYourDialogFromNowOn","","",TheNumberYouTypedInTheDirectEditor);Lo and Behold, your dialog is now defined. Now it is a simple matter of plugging it back into code provided in their friendly examples, namely using this function:WaitOnDialog("WhatYouAreCallingYourDialog");
- The last secret catch to implementing custom dialogs in the midst of your installation is this: the dialog is secretly modal(and or Popup) which might be okay for some, but it claims the foremost place on the screen, so if you pop up any little MessageBoxs which are smaller than your dialog, you don't see them, but your dialog has now lost focus and is blocking on the little MessageBox which it is occluding. It's really funny when you think you have accidentally introduced an infinite loop into your Installation code. For about a minute, and then it is infuriating until you finally realize how to force the dialog not to be modal and always on top. The secret lies in the Dialog Editor under the property "Other Windows Styles". You want to make sure to turn off anything that says Modal and/or Popup. This solves that little frustration.
That concludes our brief discussion on how to alleviate some of the agony involved in working with InstallShield. Any New discoveries will be added in due time.
I wrote this under the influence of the addictive feeling of sudden eureka-like euphoria at having gotten something to work. Corrections/Clarifications would be appreciated, or any other useful tips that could be included.