OpenSecret LiveFolder+ "FileName"

Panorama X
1

Since upgrading to Pan 0.9.006 (2605)… the procedure below no longer works. Note, I just copied/pasted the part of the procedure that doesn’t work, not the variable info.

OpenSecret lvfolder+"TSL URRS"
Window "TSL URRS:Secret"
Select «Record Series Number» = thetslrsinnum
if info(“Empty”) Message “The Record Series Item Number is not in the TSL URRS Guidelines.” stop
endif

Clicking the procedure, a message tells the file doesn’t exist. But, it works if I delete “lvfolder+” How come? I use the OpenSecret code above often, hope I don’t have to find and change all of them. Thanks, Dusty

2

The content of lvfolder would appear to be a key element here. It works when you don’t include it, and fails when you do. That would imply that TSL URRS is in the same folder as the active database, so that the path is not needed. When you do include the path, Panorama, or the operating system, doesn’t see it as the correct path.

What operating system are you using? Has that recently changed?

3

Thanks Dave, Sorry, I should have mentioned… I also updated my OS to High Sierra 10.13. All 34 of my databases are in the same folder, but we frequently go from one database to another like this:

local lvfolder
lvfolder=folderpath(dbinfo(“Folder”,""))
save
closefile
OpenFile lvfolder+“Retention Schedule”

So with the new OS (or Pan?) I only need to say:
save
closefile
OpenFile “Retention Schedule”

If this is the way things are headed?

4

This seems to be the same or a similar issue as in my thread Do paths with colons still work in PanX?

In the meantime I think there is no problem with colons in paths, but with the start disk name in paths on APFS volumes in High Sierra.

5

The folderpath( function returns an HFS file path with colons, which as Kurt reported on another thread, doesn’t work with APFS (High Sierra). So your problem is definitely the same as the one Kurt problem, and it is due to a change in High Sierra, not a change in Panorama. I am currently investigating whether there is anything I can do about this beyond submitting a bug report to Apple.

6

I don’t know if this fits better here or in my other thread: I do not see this issue anymore as a matter of the colons. My suspect is that on APFS volumes you can’t get the name of the start volume the same way like before.

This affects functions like info(“volumes”) and homepath(). I have made a test with the openfiledialog statement. This is the result for the folder variable in my test.

See what happens when I use

hfspath(folder)

Hazel is not the name of my start disk; it is the name of another hidden (not mounted) volume, presumably belonging to a 3rd party pref pane “Hazel”.

So it is no wonder that the HFS path is pointing in a wrong direction now.

Paths are working perfectly when you use the UNIX path syntax (with slashes like in the 1st screenshot and without disk name).

7

Right, I see now that my post is linked to what Kurt reported earlier. I think I’ll wait for a little while to see if this can be resolved before making any changes - thanks Jim, Dave and Kurt.