Debugging and error checking in .Initialize procedures

There have been several recent reports of .Initialize failing. I think this example may be a new problem. My .Initialize fails (it does not proceed beyond the message statement) unless I insert the message statement shown in the code below:

opensecret "Tab bar specs"
setactivedatabase "Tab bar specs"
Temp = arraybuild(cr(), "Tab bar specs", {TabTrigger+tab()+TabNames})
closedatabase "Tab bar specs"
TabTriggerDictionary = dictionaryfromarray(Temp, tab(), cr())
                                        message "1"

If I replace the five lines above the message statement with an initializedictionary statement, all works as it should.

The statement after the message is a call to an internal procedure. Its first statement is a message which is not delivered.

I’ve edited this post substantially - see the forum.

There are no reports that I know of of problems with .Initialize since 10.2 was released. Panorama X 10.2 substantially reworked how Panorama invokes .Initialize code.

If an error occurs during the .Initialize procedure, the procedure will stop, and a notification will be displayed. It will NOT display an alert because Panorama cannot allow the database initialization process to be interrupted. If you don’t have notifications enabled, you won’t know what the error is. Panorama X is designed to be run with notifications enabled. I suspect that if you enable notifications it will become obvious why your .Initialize procedure is stopping. Note that though your code is stopping, Panorama actually continues it’s internal database initialization code, no matter what. Panorama actually uses the try/catch mechanism to intercept any runtime errors in your code.

I don’t really understand your code and I don’t know what the problem is, but I do have some thoughts.

For starters, I recommend that you verify that this code works as a normal procedure (perhaps you have, but you didn’t mention it).

Your code contains two identifiers Temp and TabTriggerDictionary – what are these? They are not declared as variables in this code. I think Temp for sure cannot be a field, since you are using it in two different databases.

The second line of this code:

setactivedatabase "Tab bar specs"

is not necessary. You can use arraybuild( on any database without making the database active, and closedatabase allows you to close a database without making it active.

What happens if you don’t close the “Tab bar specs” database? I assume it is not very big, why not just leave it open? In fact then you could get rid of the dictionary and just use the lookup( or related( function instead.

A final thought on your use of the message statement for debugging. This is problematic because it alters the run loop and if you are using “secret” windows can change the active window. A much better technique is to use debug instrumentation. For someone like yourself that is doing a lot of coding you should get into the habit of using this constantly, it’s a huge brain multiplier for debugging.

True - I looked for earlier examples and found several but I see now that they are all old.

I have Notifications turned on and I get no message.

I have put my .Initialize in a try/catch loop - will that interfere with yours?

I’ve taken your advice and not made “Tab bar specs” the active database. That appears to have solved the problem which I find strange. I’ll pursue this a little further.

Depends on what you mean by “interfere”. There is certainly nothing wrong with you using try/catch (not sure why you added “loop” to that, there’s no loop). Of course if you are catching the error yourself then it will be up to you to handle and possibly report the error. Since you are handling any error that occurs yourself that explains why you don’t see a notification (so in that sense you “are” interfering with Panorama’s default handling of any error that occurs).

Note – by “I have put my .Initialize in a try/catch” I assume you really mean you have put try/catch statements in the .Initialize code.

That’s useful to know so maybe the Notification approach is safer; I’m not convinced that try/catch picks up all .Initialize errors. I just hate being inundated with Notifications about stuff I have no interest in.

Yes - all of the code is in the try/catch mechanism (no idea why I called it a loop).

I have found that Notifications are unreliable; that is, no notification box appears if notifications are set to Alerts (sometimes yes, sometimes no). However, they still appear in the Notification Center and you can look at them there.

I have notifications set to Banners, never had any problem with them.

I have seen that banners always work as intended. I just don’t like to end up with 10 or 20 or 200 banners open. I really like them to show up, hang around a little while, then go away.

That’s what they do on my systems. They don’t go away for you? Maybe there is some setting that needs to be changed.

In System Settings/Notifications, you can set your panorama notifications to Banner, Alerts, or none. Banners appear in a window on the upper right go away automatically. Alerts appear and stay until dismissed. Both appear in the Notification Center. (I reversed the behavior in my earlier posts.)

Before macOS had notifications I was a big fan of Growl. Growl only had banner notifications, and as far as I am concerned that is as it should be. I don’t know why Apple added alert notifications, personally I would never want to use them that way.