This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Suite: Browse for Folder can leave empty directory path
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 10, 2014
01:21 PM
Suite: Browse for Folder can leave empty directory path
In the wizard page for the suite package the user can click on browse and if they somehow manage to click just on Computer, click OK, then they end up with an empty path. Of course I can prevent the user from continuing by looking for the empty path. However, is there a way to prevent the user from entering this state in the first place?
In InstallScript and MSI world I would simply hold the original path in a property, then check to see if the property coming from the browse dialog is a valid path, if not then use the original path. I am not sure that I have this level of flexibility here.
In InstallScript and MSI world I would simply hold the original path in a property, then check to see if the property coming from the browse dialog is a valid path, if not then use the original path. I am not sure that I have this level of flexibility here.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 13, 2014
03:16 PM
That is unfortunate, and I think it'll be a pretty easy fix in our code. The biggest question there is (if both are possible) whether it would be better to allow selecting paths without filesystem representations (and have them act like clicking Cancel), or to disallow such selections. Any thoughts?
In the meantime, I think you can get the desired effect by adding two additional Set Property actions:
In the meantime, I think you can get the desired effect by adding two additional Set Property actions:
- Set Property - copy original to a temporary property
- Browse for Folder - modify the temporary property
- Set Property - copy temporary back to original, conditioned to run only if the temporary property is not empty
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 14, 2014
05:59 AM
Is there anyway to validate that anything that they have selected is a valid path and prevent them from clicking OK until a valid path is selected? I am not sure what the limits are with the Browse for Folder system dialog.
As a user I would want some type of feed back that I had messed up and selected an invalid path for installation instead of just being pushed back to the Current Destination Folder page.
As a possible scenario, for instance. I am a user and I am thinking Ok, I just want to install this to 'my computer'. Yes, I am not thinking clearly but the option is there and that is what I want to do, so I select it.
I go to click OK and you just cancel the choice without alerting the user to an invalid selection and the path reverts back to default. Without any feedback the user is unaware that something went wrong and further action may be required.
In this instance they truly may have wanted a path different from the default, and they wanted to install it to MY COMPUTER - but not realizing the full consequence of that selection, that MY COMPUTER is not a path or destination but an organizational unit, a descriptor for their local system.
Now I agree, my scenario is highly hypothetical and most unlikely. 🙂
Now the next question is, what is a valid path?
An empty path is not a valid path. But is the root of a drive a valid path? I guess in these cases you are going to have to leave filtering up to the InstallShield developer because there just may be instances where install to a root drive is allowed for whatever reason.
An improperly formed path - I do not know how this could be formed with the type of browse box presented to the user, as the user has no ability to type in values, but if the value is not formed correctly, [A-Za-z]:\\|\\\\ then the path should not be valid.
So if the path is invalid, then I would prefer that the user be alerted to the problem and that their selection is canceled and they are not allowed to continue with their selection within the Browse For Folder environment.
Thanks for the response Michael.
As a user I would want some type of feed back that I had messed up and selected an invalid path for installation instead of just being pushed back to the Current Destination Folder page.
As a possible scenario, for instance. I am a user and I am thinking Ok, I just want to install this to 'my computer'. Yes, I am not thinking clearly but the option is there and that is what I want to do, so I select it.
I go to click OK and you just cancel the choice without alerting the user to an invalid selection and the path reverts back to default. Without any feedback the user is unaware that something went wrong and further action may be required.
In this instance they truly may have wanted a path different from the default, and they wanted to install it to MY COMPUTER - but not realizing the full consequence of that selection, that MY COMPUTER is not a path or destination but an organizational unit, a descriptor for their local system.
Now I agree, my scenario is highly hypothetical and most unlikely. 🙂
Now the next question is, what is a valid path?
An empty path is not a valid path. But is the root of a drive a valid path? I guess in these cases you are going to have to leave filtering up to the InstallShield developer because there just may be instances where install to a root drive is allowed for whatever reason.
An improperly formed path - I do not know how this could be formed with the type of browse box presented to the user, as the user has no ability to type in values, but if the value is not formed correctly, [A-Za-z]:\\|\\\\
So if the path is invalid, then I would prefer that the user be alerted to the problem and that their selection is canceled and they are not allowed to continue with their selection within the Browse For Folder environment.
Thanks for the response Michael.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 14, 2014
07:41 AM
Michael,
I tried your example for managing this.
On the Change button I added the above events:
However, my testing still leaves the SuitePath property empty. My condition for the test above is to check that originalPath does not equal ""
I tried your example for managing this.
On the Change button I added the above events:
- Set Property - copy original to a temporary property, named 'originalPath'
- Browse for Folder - modify the temporary property, set to 'originalPath'
- Set Property - copy temporary back to original, conditioned to run only if the temporary property is not empty, property SuitePath set to [originalPath]
However, my testing still leaves the SuitePath property empty. My condition for the test above is to check that originalPath does not equal ""
1-14-2014[08:30:38 AM]: UI DLL: Executing Actions on IDC_FOLDER_DLG.Click
1-14-2014[08:30:38 AM]: UI DLL: Executing action .
1-14-2014[08:30:38 AM]: Engine: property 'originalPath' value now 'C:\Program Files (x86)\Amazing Charts'
1-14-2014[08:30:38 AM]: UI DLL: Executing action .
1-14-2014[08:30:42 AM]: Engine: property 'originalPath' value now ''
1-14-2014[08:30:42 AM]: UI DLL: Executing action .
1-14-2014[08:30:42 AM]: Engine: property 'SuitePath' value now ''
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 14, 2014
04:17 PM
I researched the dialog we're using, and it's possible to tell it to disable the OK button when ephemeral locations such as Computer are currently selected. We'll do that in the future. As far as preventing real but "invalid" locations such as folders in which the user cannot write, I think we'll leave that to custom "extension" actions for now.
What condition did you set on the second Set Property action? It looks like it failed to prevent the blank property from being propagated.
What condition did you set on the second Set Property action? It looks like it failed to prevent the blank property from being propagated.
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)