In Pan 6, when assigning a value to a field, a double equal sign, “==”, would trigger the automatic equations and procedures set in the design sheet. Pan X doesn’t do this it seems.
It’s been changed to <== .
You will find it documented here.
That should be included in the Help page for Operators, but it is not.
I’m imagining that you used the Corrections menu when you were in the Help file to update that page? 
I would have, but it was not immediately obvious how to do that and it was late.
That page begins with
All of the operators supported in Panorama formulas are listed below:
<== and = when used for assignment, are not part of any formula. They are alternative ways of writing the assignfieldwithsideeffects, and assign statements respectively, and are documented as such.
I disagree. <== is not an operator.
An operator is a token that takes a value on the left and a value on the right, and combines them into a new value. That is not what <== does. Also, operators can be placed anywhere within a formula, but <== can only be used at the beginning of a statement.
I’m not surprised. The list of operators on this page is generated automatically based on tags in the help database.
<«Body»>All of the operators supported in Panorama formulas are listed below:
@{arraycontains(Tags,"operators",",")}@
</«Body»>
To make this change, you would have to go to the assignfieldwithsideeffects page and change the PageType to operator. But don’t do that, because it isn’t an operator, and because it will mess up the formatting of the page.
All that said, I’m kind of hoisted by my own petard, because the text of this help page does call <== an operator! So I should change that!! Ok, here is the revised text:
I do think though that it would be wise to perhaps allow for a link to the proper place for the <== or the ==
If users might incorrectly believe that the should or would find info on that item on this page, shouldn’t they be accommodated and be able to find a link to where they should really be looking? Or is it more important to be accurate and thus unhelpful? I can imagine others might look to this page while not understanding the difference.
I don’t understand why anyone would look for this on the “operators” page. I don’t think someone will think that == is an operator.
If you do a full text search for ==, the assignfieldwithsideeffects page is the second result. I think this is good enough.
The first result, the = page, doesn’t even mention that = can be used for assignment. I think a reasonable argument could be made that there should be some mention of this here. However, this omission doesn’t seem to have caused any confusion. I don’t think it’s worth my time to write up an addition to this page for this, but if someone else wants to, I’ll almost certainly approve it (in any case, well over 90% of submitted corrections are approved and incorporated into the documentation).
In creating Panorama X, a huge amount of effort was expended to facilitate transitioning from Panorama 6 to X. Then over the past nine years or so many Panorama 6 users put in quite a bit of effort to make that transition in their own work. With that feedback Panorama X was improved even more, so that it was quite a bit easier for users to make that transition in 2023 than it was in 2016.
It’s now 2024, and the transition from 6 to X is pretty much in the rear view mirror. Are there still a few stragglers coming along and deciding that now is the time to make the transition? Sure, of course. But at this point any continuing work done to make the transition easier is of no value to 99.9% of Panorama users. In more specific terms, from now until eternity the number of users that are likely to need to look up how == has changed can likely be counted on the fingers of one hand. If someone does have a question about it, they can ask here, as has happened today. Answers are available. But resources are not infinite, and in my judgement it is simply not viable to invest any further in improvements related to transitioning from 6 to X. The limited resources available need to be focused on work that will grow the overall market for Panorama. In fact, I think it is quite possible that Greg will be the last person to ever ask this question, and he now has the answer. I’ve already changed the documentation to make this more clear, but I don’t think this needs to be belabored any further. Of course there’s always another place where a link could be added or an explanation elaborated further. But there’s no end to that, so at some point it just has to be arbitrarily cut off.
1 Like
Both = and <== are assignment operations. If you can have = in one place, you can have <==, which is just a special version of =. The point is not to worry so much about whether it is an operator or not, it is to put the information where someone is likely to look for it.
What would really be useful is a page of all the symbols that have special uses in Panorama, and how they can be accessed through the keyboard, things like « (option-\) and » (shift-option-\) for denoting fields, Ω (option-z) for line items, ¬ (option-l) for tab, ¶ (option-7) for, is that carriage return or line feed or both?, etc. I know these things can be found elsewhere, but I just would like Help to be as helpful as possible. I do not use everything in Panorama every day, and I do a lot of other stuff, so I do not always remember these things, and I would like to have an easy reference to them.
1 Like
I do like this idea… I was (and likely will be) doing a lot of fishing for these things as I was learning to do basic things. There were some things I knew the general gist of because of hacking my way with AppleScriptObjC… like the illusory ||| pipe escape, but I was really confused by $«field»$ vs «field» vs «variable» and so on. I still very well may be, but I hacked out what I needed to get a project mostly complete… I still have to figure out how to store these dictionaries – and I think I’ll wind up with a list item mess, but I’ve been putting that off because I don’t really understand it yet – for instance, if one record has ten key-value pairs in a related databased, can another have 5, and another have 8? will the Ω operator work to enumerate them? Stuff I can hack and figure, maybe…
That one is just for carriage return. For line feed you can use lf(), or chr(10). Carriage return is also cr(), or chr(13).
I’d also find Bruce’s special Panorama symbols Help page useful. Listing how to produce them via ‘the’ keyboard would be helpful. But there are many PanX users who use other keyboards, and some who use utilities to customize their keyboards. Moreover, with the size of Unicode, some characters can’t be entered by single keystrokes.
Their Unicode values and how to type them on a ‘standard’ US keyboard could be hard coded, but that wouldn’t help everyone correctly. It would be cool if such a Help page could read each user’s current keyboard setup and display the correct current keystroke(s) or other entry directions for each of the symbols. But I’m not aware of any OSX or Unix tools to calculate them. If such tools already exist I’d suggest a Panorama function converting Unicode values to keystroke directions. But I suspect that wish awaits Apple providing appropriate tools.
I think you may have come up with the entire list right there. I can’t think of any others off the top of my head.
I would suggest that you avoid using these characters whenever possible. I never use ¬ and ¶ any more, but always use tab() and cr(). I think it’s more clear and easier to type. If you choose field names that don’t have punctuation, you don’t need « and » (an exception would be in some external scripts). Remember that you can give a field a title (displayed in the data sheet) that is different from the field name used in formulas.
Also keep in mind that you can copy these characters from the help system. For example, I can directly copy « and » from this help page. Just select the text you want (as shown below) and press Command-C.
I have two objections to the idea of a special help page for these characters:
- I think very few users would ever find or be aware of this page.
- It would provide another complication going forward, if any new character is ever used I would have to remember to update this page.
I think it’s better the way it is done now, with each special character documented where the corresponding feature is described, as shown on the help page above. There’s already over 9,000 pages of material in the Panorama documentation, special characters is really a Macintosh feature, not a Panorama one.
If you want a great reference for all possible characters, I find PopChar to be a great tool. It’s not free, but it’s a nice little app and I find that it is worth it. When I get a new Mac this is always one of the first programs I install.
You would have to consider international keyboard layouts, too. In my German keyboard layout e.g. this list would read:
« (option-q)
» (shift-option-q)
¬ (shift-option-1)
¶ (option-3)
| (option-7)
Ω (option-z)
A comprehensive page listing all the uses of non-alphanumeric symbols would be useful because (if nothing else) they do not always come up in a full-text search in the help database. Try searching for π, for instance: four pages are listed, but not the page for pi() in which the symbol also appears. These are all that I have come across — not including the traditional uses of some of the 7-bit ASCII symbols — ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ { | } ~ — which should probably be included too: for instance \ indicating integer division (sometimes, but by no means universally, used elsewhere for this purpose). Several of these I have only discovered in passing when looking for something unrelated, or even by trial-and-error:
U+00B6 (¶, paragraph mark) is an alternative for cr() or chr(13).
U+00AC (¬, not symbol) is an alternative for tab() or chr(9).
U+03A9 (upper-case omega, Ω) or U+2126 (ohm symbol, Ω) signify the number of the current line-item field.
Correct glyphs for several mathematical symbols are accepted as alternatives to either the 7-bit ASCII symbols commonly used or Panorama X functions:
- U+2260 (≠) as an alternative to <> or !=
- U+2264 (≤) as an alternative to <=
- U+2265 (≥) as an alternative to >=
- U+00D7 (×) as an alternative to * for multiplication
- U+00F7 (÷) as an alternative to / for floating-point division
- U+03C0 and U+03A0 (lower- and upper-case pi: π and Π) and U+220F (∏, n-ary product) as alternatives for
pi() - U+2107 (ℇ) as an alternative for
eulersconstant()
However, U+2212 (−, the minus sign) is not accepted as an alternative to - (hyphen) for subtraction.
Double guillemets («…», U+00AB and U+00BB) optionally enclose field names, but are necessary when they include spaces.
Three matching pairs of characters are used to enclose string (text) constants, in addition to "…", '…' and ||…||, |||…|||, etc.:
- Braces: { and }
- Single quotation marks: U+2018 (‘) and U+2019 (’)
- Double quotation marks: U+201C (“) and U+201D (”)
However, I can’t think of any use Panorama X makes for matching single guillemets (‹…›, U+2039 and U+203A).
Various extra characters are used in LMSL menu definitions:
- U+025C (ɜ, lower-case reversed open E) signifying the end of a menu identifier
- U+221A (√, square-root sign) signifying a tick (check mark) — n.b. not the tick symbols U+2713 or U+2714
- U+21E7 (⇧, upwards white arrow) signifying shift modifier
- U+2325 (⌥, option key symbol) signifying option modifier
- plus specific uses in LMSL for 7-bit ASCII characters (some used differently elsewhere in Panorama X) such as * ^ ( ) @ ; # S
There are also the various ways symbols are used in regular expressions, but they probably don’t needed to be included.
PopChar provides a place you can store favorite unusual characters for easy access amongst its tricks. Apple’s less featured but free Character Viewers also lets you store favorites. I thought I recalled some special characters being potentially used either in graphic mode with forms or in the Constructer, but I haven’t worked anew with either for awhile and couldn’t find them browsing Help so may be imagining them.
I think I had a different idea than you guys… I know how to find the characters to insert or type them … I still use the keyboard from system 7 (or character map as memory serves)… all those nice little NS things laying around in OSX:
That’s easy enough… And it shows up localized to whatever keyboard you are using at the moment – so if I am using Greek, it shows Greek and the option characters are different, etc.
I was thinking of a cheat sheet / Quick reference guide that describes FUNCTION of the symbols and where to find help on them – something like a Table of Contents / Reference Chart or special character usage in panorama:
«» These are used as field or variable delimiters. See *Fields* or whatever appropriate page.
||| Triple pipe delimiters. used to enclose code (similar to NS usage). See {link to appropriate help page}
<== Special assignment operator, see {link to major help page}
Ω List Field Wild card. Used to tell Panorama to enumerate a list field. See {whatever best help page}
$ used to escape from triple piped delimited strings.. enclose the escaped object in $. See {link to major help page}
...
and so on down the list. A cheat sheet like that is helpful to get a bird’s eye view, useful for quick reference when rusty and need to quickly re-orient after a break, etc…
So I wasn’t too concerned about how to type the symbols… I’m concerned about learning the lingo and symbols. Jim has put together a nifty code system for panorama, but it has necessarily imported flavors of NS/Apple conventions, flavors or other languages, and some unique conventions Jim has built to make this neat code base and even full reflection (!). I like it because it’s pretty accessible and very much in the spirit of all my favorite scripting on apple even before next came along, but it also has its own conventions that can be pretty confusing (or maybe jarring) if you have passing familiarity of with those other things also! So I was, especially as a newcomer, thinking of what I was looking for as I’d hunt through help pages. I needed a topical map / quick reference chart of sorts to help point me towards best starting places.
I know what will happen to me – I’ll get onto some other project and months from now, I’ll want to write a new project, and I’ll be scratching my head – “wait, that omega thing was a field thing, I think… where was that again?” or “hmmm, I wonder how panorama sees this sort of object and how to describe it in a procedure” etc… A table like that is helpful because it also gets the special vocabulary flowing as well.
I believe that this is a solved problem with the help system’s excellent search tool.
I can see that. But it would also be quite a lot of work to assemble. There are a ton of very helpful projects that could be done. Literally years worth. It’s hard to judge which would provide the most bang for the (limited) buck.
While we’re at it though, I need to provide some corrections to the cheat sheet you have provided.
«» are used as field or variable delimiters, but are ONLY needed if the field or variable contains spaces or punctuation.
||| Triple pipes (or 1, 2, 4, 5, 6…) are used to delimit text constants. They are super handy when you need to put code into a text constant, but will work anywhere a text constant is needed. FYI, I lifted this idea from Python, I don’t know of any NS usage of pipes in this way.
Ω I never thought of this as a line item wild card, but I kind of like that terminology. But it’s not for enumeration. It’s actually a placeholder for the current line item field number.
$ used to escape from triple piped delimited strings.
This is just completely incorrect. $ generally has no meaning, it’s just a character. But when combined with « and » it can be used to embed formulas into various types of scripts (AppleScript, Python, etc.) That’s the only context where $ has any special meaning.
This last brings up what I see as another problem with this character cheat sheet idea - many of these are very context dependent. So either the cheat sheet has to be super simplified (and probably confusing/misleading) or has to contain complicated explanations of the various contexts. Currently, the documentation mentions these characters in each context where they are used. I think that is better.
Unfortunately, the more I think about it, the less I like this cheat sheet idea. Sorry.