I use the ShellOpenDocument command to open a document in a recipe database. Has worked for a really long time, on Pan 6. I give a document a name and store it in an appropriate sub directory. I then make an alias of that document and store that alias in a folder called “Signature Recipes - Famous Recipes-Alias Only”.
With my new computer I had to transition to Pan X running Ventura.
If there is a “—” in the file name (option shift key to the right of the 0 (zero) ) my document will not open with the ShellOpenDocument command and I get an error. Otherwise no problem.
The error statement:
“OpenURL statement url is malformed: file:///Users/George/Documents/GAB%20Folder/Main%20File%20System/Cooking/Signature%20Recipes%20-%20Famous%20Recipes-Alias%20Only/Maryland%20Crab%20Cakes—Pan-Fried%20Crab%20Cakes%20with%20Old%20Bay%20Seasoning.docx%20alias.”
Below is the one line procedure. «Document Link» is the file name of the alias file. All alias are stored in the same folder. The actual document, be it a word, pdf, Excel, etc. are in various folders depending on the specifics of that file.
You will find shellopendocument if you enable the Full Text Search option. The primary name for this statement has been changed to openurl, to reflect the intended use, so it doesn’t come up if you are only searching the page titles. The text does mention that openanything should be used instead.
This is not the first time that a user has been thwarted by not being aware of a result that would appear if they only had checked the ‘Full Text Search’ option.
Perhaps Panorama X Help might display an alert if it does a background search while only displaying the default search and having found additional results display “Additional information has been found by doing a Full Text Search. Would you like to see those results?” Yes No
There are two reasons why Panorama doesn’t default to the Full Text Search option.
The most important reason is that this option often produces too many extraneous results. Here’s an extreme example – if I search for “call”, I get 20 results, most of which are probably relevant to what I’m looking for. If I turn on Full Text Search there are 2,357 selected topics. Usually the difference is not that extreme, but it’s almost always best to search just the topic names first.
A less important reason is that Full Text Search is significantly slower. However, on modern M1 machines this really isn’t much of a factor any more, the search is still quite fast either way.
This sounds like a nice fantasy feature, but I think there are significant real world problems with it.
First of all, there is currently no “background search” capability in Panorama, and creating one would be quite complicated, if at all possible. So automatically performing a second full search every time would cause very noticeable performance issues.
A second problem is that there is no explicit action to trigger a search command. The search is performed instantly as each key is pressed. So at what point does Panorama decide that the user might like to see additional results? Maybe they stopped typing because of a phone call, or they are just thinking. In general, I think that it is very bad form for a program to suddenly pop-up an alert in an unpredictable situation. I think that this feature would probably result in a lot of spurious alerts that would cause users to curse at Panorama.
I think the current system is a pretty good compromise – if you do a search that doesn’t produce the results you were expecting – click the Full Text checkbox. It’s right there – just as easy as clicking Yes on an alert, but staying out of your way otherwise.
If I simply replace “ShellOpenDocument” with “openanything” and keep the rest of the code the same it does not work. I get an error. Not simply substituting a different statement.
The path has to be different.
I had to chop out " “file://" from the beginning. Studying the documentation was essential. Who would have thought? LOL
Hopefully this comment will save a few folks some hair pulling in transitioning.
openanything solved the problem with the “—” option shift “-” key, also “–” option “-” I later discovered had the same issue with the shellopendocument statement.
