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
- :
- ParsePath not working for UNC path in IS 2014
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 08, 2015
12:19 PM
ParsePath not working for UNC path in IS 2014
InstallScript Project
I have a piece of code where I'm pulling the share name of a UNC path using ParsePath. i.e.:
The result is an empty value for szShareName.
I've been using this piece of code in the same project since probably IS12 (that's 12, not 2012), and have upgraded versions of IS every year (except 2013), and this never presented a problem, szShareName would return "FolderName" in the value. Now, in IS 2014, it's not working.
I've tried passing other operators in ParsePath (DIRECTORY, FILENAME_ONLY, PATH), and the only one that returns a value is PATH, which is not helpful.
Also tried:
but got the same results.
I can bypass by using some StrFind and StrSub functions, but that's not what I want to do, and want to know why this isn't working all of a sudden.
Any thoughts?
I have a piece of code where I'm pulling the share name of a UNC path using ParsePath. i.e.:
szUNCPath = "\\\\MachineName\\FolderName";
ParsePath(szShareName, szUNCPath, FILENAME); //using FILENAME since IS just pulls the value after the last slash as the value
MessageBox (szShareName, SEVERE);
The result is an empty value for szShareName.
I've been using this piece of code in the same project since probably IS12 (that's 12, not 2012), and have upgraded versions of IS every year (except 2013), and this never presented a problem, szShareName would return "FolderName" in the value. Now, in IS 2014, it's not working.
I've tried passing other operators in ParsePath (DIRECTORY, FILENAME_ONLY, PATH), and the only one that returns a value is PATH, which is not helpful.
Also tried:
GetDir(szUNCPath, szShareName);
but got the same results.
I can bypass by using some StrFind and StrSub functions, but that's not what I want to do, and want to know why this isn't working all of a sudden.
Any thoughts?
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 09, 2015
08:23 AM
Looking at the help topic for ParsePath I'm not convinced the behavior you expect matches the documented behavior. It looks like for a path of the format \\server\share\dir\file.ext, the DISK is \\server\share, the DIRECTORY is \dir\ and the FILENAME is file.ext. This would indicate for a shorter path of just \\server\share, the DISK would remain the same, but the DIRECTORY and FILENAME would be empty.
However I would typically not expect us to have changed this behavior, so it sounds like we need to assess whether the behavior was buggy, the docs were buggy, or if the scenario was what changed. Is there any variability in the way you acquire the path you pass to ParsePath, or have you verified simple hardcoded strings in multiple versions of InstallShield?
However I would typically not expect us to have changed this behavior, so it sounds like we need to assess whether the behavior was buggy, the docs were buggy, or if the scenario was what changed. Is there any variability in the way you acquire the path you pass to ParsePath, or have you verified simple hardcoded strings in multiple versions of InstallShield?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 09, 2015
10:14 AM
First, I should amend my original statement. My code did actually take into account the file name and extension by adding a fake extension.
The UNC path is retrieved from a database table, in the format "\\MachineName\FolderName". I append a ".tmp" to the end to make it look like a file, and then use the "FILENAME_ONLY" to retrieve the FolderName value (which is the UNC share name that I'm looking for).
The UNC path is passed into a function and the local path
This worked fine up through IS2012, same code not working when I upgraded the project into IS2014.
I can recreate using hardcoded strings as well. However, if I change the scenario, I get different results for IS2014 and IS2012 (same code used in both versions):
So, scenario "A", the original scenario, behaves differently in IS2014 and IS2012, with IS2012 giving the results I've expected over time and throughout previous versions of IS.
Scenario "B" both return blank, which is kind of expected, as "\\\\MachineName\\FolderName" is probably considered the "DISK", there is no "DIRECTORY"
Scenario "C" returns different results, and, again, IS2012 would be the preferred, and maybe expected (?) results.
Scenario "D" returns the same results, but contains a leading quote mark for some reason.
Scenario "E" returns the same results, but contains a trailing quote mark for some reason.
Scenario "F" returns the same results "FolderName", which is what I'm looking for, but based on results for "D" and "E" this seems kind of "lucky" in that "D" and "E" pick up the leading and trailing quotes, but since this is FILENAME_ONLY, the trailing quote would be at the end of the file extension.
Just find this very odd, as I can't imagine the ParsePath function underwent many changes from IS2012 and IS2014.
The UNC path is retrieved from a database table, in the format "\\MachineName\FolderName". I append a ".tmp" to the end to make it look like a file, and then use the "FILENAME_ONLY" to retrieve the FolderName value (which is the UNC share name that I'm looking for).
The UNC path is passed into a function and the local path
szUNCTemp = szUNCPath + ".tmp"; //create a fake filename for ParsePath
ParsePath(szShareName, szUNCTemp, FILENAME_ONLY);
This worked fine up through IS2012, same code not working when I upgraded the project into IS2014.
I can recreate using hardcoded strings as well. However, if I change the scenario, I get different results for IS2014 and IS2012 (same code used in both versions):
//A
szUNCPath = "\\\\MachineName\\FolderName";
szUNCTemp = szUNCPath + ".tmp"; //create a fake filename for ParsePath
ParsePath(szShareName, szUNCTemp, FILENAME_ONLY);
MessageBox("ORIGINAL\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
//IS2014 returns szShareName = ""
//IS2012 returns szShareName = "FolderName"
//B
szUNCPath = "\\\\MachineName\\FolderName";
szUNCTemp = szUNCPath; //no fake filename
ParsePath(szShareName, szUNCTemp, DIRECTORY);
MessageBox("DIRECTORY (no fake filename)\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
//IS2014 returns szShareName = ""
//IS2012 returns szShareName = ""
//C
szUNCPath = "\\\\MachineName\\FolderName";
szUNCTemp = szUNCPath; //no fake filename
ParsePath(szShareName, szUNCTemp, FILENAME);
MessageBox("FILENAME (no fake filename)\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
//IS2014 returns szShareName = ""
//IS2012 returns szShareName = "FolderName"
//D
szUNCPath = "\\\\MachineName\\FolderName";
szUNCTemp = "\"" + szUNCPath + "\""; //surround with quotes
ParsePath(szShareName, szUNCTemp, DIRECTORY);
MessageBox("DIRECTORY (surrounded by quotes, no fake filename)\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
//IS2014 returns szShareName = "\"\\\\MachineName\\"
//IS2012 returns szShareName = "\"\\\\MachineName\\"
//E
szUNCPath = "\\\\MachineName\\FolderName";
szUNCTemp = "\"" + szUNCPath + "\""; //surround with quotes
ParsePath(szShareName, szUNCTemp, FILENAME);
MessageBox("FILENAME (surrounded by quotes, no fake filename)\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
//IS2014 returns szShareName = "FolderName\""
//IS2012 returns szShareName = "FolderName\""
//F
szUNCPath = "\\\\MachineName\\FolderName";
szUNCTemp = "\"" + szUNCPath + ".tmp\""; //add fake filename, surround with quotes
ParsePath(szShareName, szUNCTemp, FILENAME_ONLY);
MessageBox("FILENAME (surrounded by quotes, fake filename)\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
//IS2014 returns szShareName = "FolderName"
//IS2012 returns szShareName = "FolderName"
So, scenario "A", the original scenario, behaves differently in IS2014 and IS2012, with IS2012 giving the results I've expected over time and throughout previous versions of IS.
Scenario "B" both return blank, which is kind of expected, as "\\\\MachineName\\FolderName" is probably considered the "DISK", there is no "DIRECTORY"
Scenario "C" returns different results, and, again, IS2012 would be the preferred, and maybe expected (?) results.
Scenario "D" returns the same results, but contains a leading quote mark for some reason.
Scenario "E" returns the same results, but contains a trailing quote mark for some reason.
Scenario "F" returns the same results "FolderName", which is what I'm looking for, but based on results for "D" and "E" this seems kind of "lucky" in that "D" and "E" pick up the leading and trailing quotes, but since this is FILENAME_ONLY, the trailing quote would be at the end of the file extension.
Just find this very odd, as I can't imagine the ParsePath function underwent many changes from IS2012 and IS2014.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)