Can I include æ and ø in a variable name?

I’m working in a database all of whose field names are in Danish and include names like Sværmtrang which contains the æ character. I want to create variables based on the field names so I need a variable called SværmtrangName which Panorama X reads as rmtrangName which, of course, hasn’t been declared. This code works:

local «SværmtrangName»
«SværmtrangName» = "abc"
message «SværmtrangName»

… but when I click the Run button in this procedure, the procedure closes (but still runs). I can also invoke it from the Action menu.

Am I courting danger by declaring a variable within chevrons? Should I avoid all characters likje æ? And why would the procedure close itself?

Interestingly, Panorama X has no problem with SværmtrangName as an object name in a form.

This looks like a good way to use names and titles of fields that are different.

There should be no problem as long as they are enclosed within the chevrons. This is from the Help file under Variables:

Panorama allows any sequence of characters to be used as a variable name. However, if the variable name contains any punctuation (including spaces) it must be surrounded by the chevron characters « and ».

I believe Panorama X treats anything with a chr( value over 126 the same as a punctuation mark. This behavior is also evident in Apple’s TextEdit app if you enter “SværmtrangName” and then double click it to select it, it will only highlight a limited portion of the word depending upon where it was clicked. At the beginning it will highlight “Sv”, at the end “rmtrangName” and only “æ” if that is directly clicked. This is therefore an Apple convention and not limited to Panorama.

It sounds like Apple would be able to change this behavior at some point, but it may not be desirable. It would make sorting difficult. Alphabetization is not universal, something my brother found when he hired someone from China to alphabetize some records, and she had no idea what that meant.

Now when I checked out some other high ASCII characters, TextEdit consistently selects the entire word. I made no changes to TextEdit that I know of so I’m at a loss as to why it is now accepting characters above 126 as normal characters and no longer treating them as spaces or punctuation characters. I just checked Pages and that also selects the entire word when double clicked. Panorama X still treats these as special characters that need chevrons enclosing them to work as field or variable names.

Thanks guys. I think I’ll go with changing the field names - using chevrons necessitates more complex code when creating and accessing new variable names based on chevron-quoted field names and I’m trying to keep it as simple as possible.

It doesn’t close (I just tried your exact code to make sure). However, whenever you click the Run button Panorama automatically brings the frontmost data window from that database to the front, either a form or the data sheet. Depending on the size and position of that data window, it may cover the procedure window. In that case it looks like it disappeared, but it’s really still open if you move the frontmost window out of the way. This is the way all procedures work, not just the particular code you have submitted here.

No, that is absolutely ok. But the chevrons are necessary if the variable name contains anything other than

  • plain letters A thru Z (upper or lower case).
  • underscores (_)
  • numbers (but not allowed as the first character)

Only plain letters can be used without chevrons. Letters with any kind of accent marks or diacriticals require the chevrons, as do any ligatures, like æ.

This actually has nothing to do with how Apple’s text editor code decides what a word boundary is – that is an entirely separate issue.

I agree with this – I generally try to avoid the use of chevrons as much as possible. Keep in mind that in Panorama X the field name can be different than the field title that is shown in the data sheet. So you could name the field SvaermtrangName for use in formulas, but still display the field title as SværmtrangName. Best of both worlds, I think.

Of course - the perfect solution.