Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Error -2732 in InstallChangeFolder Sequence?


4 replies to this topic

Dave I

Dave I
  • Members
  • 195 posts

Posted 06 June 2001 - 16:20

In order to use the responses from my UI interface I moved my dialogs in the UI Sequence before CostFinalise.  This way I have access to the Properties selected by the user.

My problem is that I am now getting "Error 2732" = Directory Manager not initialized.  when I attempt to return with OK from the InstallChangeFolder dialog.  I pressume this is occuring because the call to SetTargetPath is take place before file costing.

How can I "Initialize the Directory Manager" and obtain the UI properties?  


SteveP

SteveP
  • Members
  • 126 posts

Posted 07 June 2001 - 20:55

I am not following you 100% here ... what is it that you are getting from your UI?  If you are attempting to redirect your install in any way, it won't work that way.  Path resolution is accomplished by the CostFinalize action, and until you have resolve the initial paths for your directory structure, you can't effectively change anything.

If you absolutely simply MUST have some of your UI run prior to CostFinalize, then you will need to split your dialog sequence.  Call the first dialog in the second set from the InstallExecuteSequence (just as you do WelcomeDlg).

Two things to keep in mind:

1.  You can't dynamically change anything in the database.  The best you can hope for in that regard is to redefine a property through the use of a Edit control.  (Actually, you can make temporary changes, but not persist them.)

2.  Exercise extreme caution when defining something in the UI sequence and then attempting to use it in the Execute sequence.  In my expreience, if you want to do that kind of thing, don't put default values in the Property Table.  If you do, the Execute sequence will fairly consistently use the default rather than the value you entered through the UI.  Apparently, the UI and Execute sequences run as parallel threads, and the sharing of information across the thread boundaries is rather ... um ... fuzzy.

Please drop me an email if you would like to get down to specifics on this issue.

(Edited by SteveP at 1:53 pm on June 7, 2001)


Dave I

Dave I
  • Members
  • 195 posts

Posted 08 June 2001 - 08:41

Ok, heres an example.  I have a radiobutton in my dialog attached to a property "EXAMPLEDATA"; Yes="TRUE", No="FALSE."

I then place a condition on the ExampleData component "EXAMPLEDATA="TRUE", so obviously it is only installed by if the option is selected.  My dilema is that if the CostFinalize action is before my UI the component conditions are determined before the user has chance to make the selections.  If I place CostFinalize after my UI, the PROPERTIES are set in response to user selections and then the component conditions are determined allowing an install tailored to the user selections.

Splitting the dialog sequence seems like a reasonable idea but I would want to give the user the option of changing the directory early on in the dialog stream, again this would leave me with the same problem of the component conditions being evaluated prematurely.

By placing the CostFinalize after my UI then I know that my problem is due to the directories not yet being resolved.  But how do I get around this?

I would like to know everyone else is handling component activation based on UI Properties.

Obviously there is the CustomSetup to set options, but this just does not meet our needs.  Our product is highly configurable and Radiobuttons and checkboxes are more suited.

Thanks,
Dave


SteveP

SteveP
  • Members
  • 126 posts

Posted 12 June 2001 - 20:26

One possibility might be to associate your ExampleData with a Feature.  Then include a dialog with your radio buttons prior to CostFinalize.  Have the radio buttons set Property values that are used in the evaluation of Conditions (which determine whether Features are installed).  This gives you your ability to select components, because each component to be installed has to reference a Feature that is marked for installation.  

One component can be associated with several different Features, according to the documentation, so you could predefine your install configurations as Feature sets (lots of components) or retain the maximum flexability by having lots of selectable features (few components per feature).

Then schedule CostFinalize to resolve the Conditions and set which Features are in the install set.  Use the CustomizeDlg to specify path changes.

Another possibility is to schedule your UI after the CostFinalize action and abbreviate the sequence that leads to the CustomizeDlg.  During parts of our development cycle I had a developer install that went directly from the PrepareDlg to the CustomizeDlg.

Other than that, you might want to try a CustomAction prior to CostFinalize to set up your conditions as temporary changes to the MSI database.  The problem I see with that approach might be difficulty accomplishing a "repeat last install" function.

Hope that helps.