InstallAware

How is the entry [Written Variable Value] in the "Object behavior" Of a dialog control supposed to work?
My naive assumption based on the text and the narrow portion of the help file, was that the control is initialized with the value of the variable, where the value is written to afterwards. But that doesn't seem to work like that.

In our Application we need four directories. The first one is the main one ($TARGETDIR$) and three additional ones $USERDATDIR$, $LIBRARYDIR$ and $DOKVDIR$. The default values of the latter three is $TARGETDIR$\\userdat and simillar for the others. But of course the user can change these.
In the Installshield App, I'm converting, we had a dialog with four DireectoryEditBoxes. With the logic to set the defaults for the later three when the first one changes (only if they were not previously set.)
I didn't see a DirectoryEditControl in InstallAware and no means to put logic like this on a dialog, so I created three copies of the destination dialog. One for each. In the loop the destination dialog for $TARGETDIR$ comes first, and the remaining variables are initialized accordingly. Now here comes the problem: Instead of displaying the directory where the variables got initialized, the tree controls of the remaining destination dialogs start on the desktop folder.
In another thread (http://www.installaware.com/forum/viewt ... f0729652de) I read that one should only use the $TARGETDIR$ variable for things like this, make a backup, and copy the values back and forth.
But I thought that can't be true that I have to hack a cludge like this. What for is the entry in the entry [Written Variable Value] in the "Object behavior" if not for initializing the control with the content of the associated variable?

With some further testing, I found out that the Edit control gets sometimes correctly initialized, but never so far the tree control.
And more important, if I change the tree control, the edit control does not reflect the change.

http://www.installaware.com/forums/viewtopic.php?t=3450

you might check out this post. Having problems with the destination directory as well. We seem to be having different one but it might get you started in the right direction.

Also the [Written Variable Value], be sure that you have the variable decleared before the dialog is shown.

I found out that the TreeControl can only display existing directories. And of course my additional three default directories didn't exist at the time of the dialog. So the TreeControl started at the desktop folder.
If I create the default folders in the file system using call dll kernel32.dll CreateDirectoryA prior to displaying the destination dialog, and delete it afterwards if a different directory was chosen, the controls behave as expected.
It is somehow a workaround, but I understand now why it behaves as it does. And I prefer this solution over the one proposed in another thread abusing the $TARGETDIR$ for all different directories.

One problem with the above Solution remains.
If the folder, the variable points to is hidden, then still the tree control initializes to the desktop folder, even if the hidden folder exists, and can be selected with the tree control.
In my case the folder in question is "C:\\documents and settings\\richard.ulrich\\application data\\PointLine"
Is there another solution to this than calling some win32 api to unhide the application data folder?

Now I call the kernel32.dll function SetFileAttributesA for all directories in the row from
C:\\documents and settings\\richard.ulrich\\application data
To my newly created filder underneeth. I can doublecheck with explorer, and the directory really exists, and the directory and all its parent directory are really not hidden (temporarily).
But still the tree control on the destination dialog doesn't initialize to my directory, but to the desktop directory instead.

Under exactly what circumstances does the tree control ignore the variable value and initialize to the desktop folder instead?

I got a reply through InstallAware support :

Richard,

I found the problem. When you use a "Get Folder Location" command, the value return comes with a leading \\. For example:

Get Folder Location System->Program Files Directory into PROGRAMFILES

returns C:\\Program Files\\ and not C:\\Program Files

You were calling dll functions with parameters containing a double back slash. Attached is the sample project you sent us modified.

Regards,

Alejandro Ronquillo
InstallAware Support

---------- quote end --------------

Ok, thanks. That solved my problem. But I'm a bit cunfused.
The dll functions didn't have a problem with the double backslash. They performed correctly as was checked with the message box. I didn't worry about the tree control handling the double backslash, because I read a statement somewhere, that IA would convert these double backslashes automatically and the user wouldn't have to care. Honestly I was more worried about the dll functions. That's why I doublechecked that they worked as expected. And after I saw that the dll functions work, I blindly expected the tree control could handle that as well.
So, I'm sure if you apply your standard filename/folder logic to the tree control, that could also save other users some hassle.