Has anyone actually implemented any code successfully with these functions? ... View more

Unfortunately, I cannot prototype the necessary windows API functions successfully in InstallScript. They don't work. Two are required, plus a struct. Installshield seems to be inadquate to the task of implementing the Windows API in this instance. As someone else pointed out, it does not understand string pointers. prototype BOOL Advapi32.LookupAccountSidA(POINTER, POINTER, POINTER, POINTER, POINTER, POINTER, POINTER); prototype BOOL Advapi32.ConvertStringSidToSidA(POINTER,POINTER); And the second function’s second parameter is a pointer to a SID structure. ... View more

Here is the Windows API function that is needed. I was having trouble finding it on the Microsoft site, but eventually (with the help of someone else at work), it turned up: http://msdn.microsoft.com/en-us/library/windows/desktop/aa379166%28v=vs.85%29.aspx ... View more

This is not quite what I am looking for if the files still "have to be in source." What we are looking for is the ability to PULL some of the files OUT of the uncompressed source folder (deliberately) and NOT have the installer complain that they are missing. We want our users to be able to decide which of the "knowlege base" files they want to include in their installations. Our kbases configure default project type estimates based on historical data. Some types of kbases apply to some customers, others to other customers. ... View more

I guess what I am looking for is a THIRD option to set in the File table attributes. There are only two options. One is file critical, in which case the installer quits if it is missing. The other is file missing but not critical, in which case a dialog pops that allows you to IGNORE. A third option would be file missing, but intentionally, and NO error dialog appears. File Table, Attributes column: Constant Hexadecimal Decimal Description msidbFileAttributesVital 0x000200 512 The file is vital for the accurate operation of the component to which it belongs. If the installation of a file with the msidbFileAttributesVital attribute fails, the installation stops and is rolled back. In this case, the Installer displays a dialog box without an Ignore button. If this attribute is not set, and the installation of the file fails, the Installer displays a dialog box with an Ignore button. In this case, the user can choose to ignore the failure to install the file and continue. ... View more

It must have had something to do with migrate feature states during minor upgrade. The installer was not migrating the APPDATA directory value; it was resetting it as default INSTALLDIR. I don't know why. It might be because the one component that used that directory had only one file (the raw INI for the program, which the program then configures for individual users when they start up from their profiles). In any case, I did not notice that we had a problem migrating the directory in InstallShield 2008. The solution here was to just let the installer do what it wanted and then RESET the DIRECTORY as INSTALLDIR ^ "AppData" (this is always the value) with a directory custom action after MigrateFeatureStates. ... View more

Here's the verbose log entry where the error is occuring. MSI (s) (0C:24) [20:13:51:148]: PROPERTY CHANGE: Modifying APPDATA property. Its current value is 'C:\Program Files\SEER\SEER-H 7.1\AppData'. Its new value: 'C:\Program Files\SEER\SEER-H 7.1'. My question is what action is that associated with? It Occurs after CostFinalize, when there are a bunch of property change actions. MSI (s) (0C:24) [20:13:51:148]: Doing action: CostFinalize Action ended 20:13:51: IsolateComponents. Return value 0. But nothing in the InstallScript actually SETS the APPDATA directory property to the application's ProgramFiles directory. It just seems to be "happening." ... View more

That's good to know. As you can see, we skipped Installshield 2010, or I would have found out about this earlier. Now I can see all the old dialog scripts in ISRTScriptDialogs.rul I notice that CONVERTED 2008 projects give the following error when you try to select the drop-down option for cloning (?) dialog scripts: "This Project does not define support for adding dialog sources from the InstallScript Editor. Attempting to add dialog source throught the event list may result in compile errors. Support for dialog sources can be added by adding _ISSCRIPT_NEW_SYLE_DEFS to the preprocesor defines in Build-> Settings." I guess that means that InstallShield Engineers figure that the presense of new custom dialog scripts in a converted project COULD cause compile collisions. So, it sounds like either you should dump your custom dialogs and recreate them using the new method, or you should keep the old method and save the old scripts and/or copy the new dialog functions to your own scripts and create new defines if you have trouble. But it sounds like the preferred method is to redo all of your custom dialogs using the event list functions. ... View more

Okay, here's what's up. "Run once" doesn't really mean "run once." It means "run once if you find the action scheduled in more that one sequence . . . but don't run at all if you find it scheduled in one sequence" (the retarded part). So, if you configure an action in only one sequence, watch out for leaving it configured to "run once." Your human logic will stare at it and say, "Okay, nothing wrong with that." But some idiot MSI programmer at Microsoft who lives in Wonderland, invented his or her own conception of logic in which "run once" doesn't really mean "run once." ... View more

MSI (s) (90:CC) [13:34:32:366]: Doing action: WriteSEERMetricsXMLFile Action 13:34:32: WriteSEERMetricsXMLFile. Action start 13:34:32: WriteSEERMetricsXMLFile. MSI (s) (90:CC) [13:34:32:366]: Skipping action due to msidbCustomActionTypeFirstSequence option. Action ended 13:34:32: WriteSEERMetricsXMLFile. Return value 0. What is msidbCustomActionTypeFirstSequence ? That seems to be what is derailing the action. I have not encountered that before. http://www.ureader.com/msg/1653396.aspx http://msdn.microsoft.com/library/en-us/msi/setup/custom_action_execution_scheduling_options.asp This SHOULD NOT BE OCCURING. The action is scheduled to execute ONCE, but it exists ONLY in the Execute Sequence. It is NOT configured for the UI sequence and clearly ISN'T running there. And the fact that it ran okay during uninstall should be indication enough that it is NOT erroneously configured for execute only once. This looks suspiciously like a BUG in MSI. OR: I don't NEED "Execute only once" since it is already ONLY in one sequence. It seems like that may be what is confusing the MSI engine. But you can see WHY one would want to "execute only once," since you don't want to try to overwrite a file that you just wrote. ... View more

I'm starting by using a "Not Installed" condition because I want the file to be written only during installation anyway. Perhaps having a condition will "wake up" the custom action from its lethargic sleep (it is like my pothead nephew in Northern California, who smokes weed all day, refuses to look for a job, and never pays his bills . . . a worthless dysfunctional parasite). Then if that doesn't work, I'll generate and and check out the verbose log. Sometimes that isn't very helpful, I have found. But I need to check it. Thanks ... View more