Killall carbulator

I used this script in Hazel for years to monitor, quit, and restart Panorama on a Power PC Mac running my Heating System Controller program.

killall Carbulator
sleep 7
open -a /Applications/Panorama/Panorama.app

What is the proper identifier for Panorama in the new version? I’m running the program on OS Monterey.

Thanks,

Jeff

The Unix executable is named PanoramaX.

The application is PanoramaX.app unless you have renamed it, and there is no Panorama folder, so that last line is probably

open -a /Applications/PanoramaX.app

You wrote a script that intentionally crashes and then relaunches Panorama? That doesn’t seem like a great idea to me, I’m not going to help with that. That said, I think Dave’s almost got it, but I think there’s a typo. But I’m not helping!

1 Like

Thanks for pointing out the folder issue, Dave.

Jim, now and then, Panorama has an error, and the controller program stops. I’ve used Hazel to monitor a text file that Panorama saves every minute or so when the controller is running. Hazel runs the script when the file hasn’t been updated in the last 3 minutes and restarts Panorama. The controller starts automatically when Panorama launches.

I need a way for Hazel to restart Panorama in those situations to avoid overheat issues, etc. What do you recommend?

Yep. I copied and pasted his code, removed the Panorama folder, and forgot to add the X to the application name

Is there an external script that will close all or specific open databases and reopen a specific database? All without crashing Panorama : )

Is there an external script that will close all or specific open databases and reopen a specific database? All without crashing Panorama : )

Sure, you can use an AppleScript to do whatever you want.

Although I own a copy of Hazel, I’ve not used it much. But a quick Google search confirms what I suspected, that Hazel has built in capability to run AppleScript code. I think what you want is probably to use an embedded AppleScript, but and external AppleScript would probably work as well. Either way, here is the relevant documentation.

Thanks, Jim

I use an AppleScript in Hazel for sending the alert email. I just tested this, and it will work without having to quit Panorama :slightly_smiling_face:, assuming the issue isn’t a rare Panorama freeze.

tell application “PanoramaX”

activate

run code “closedatabase {Heating System Controller}”

delay 7

run code “openfile {~/Heating_System_Controls/Heating System Controller}”

end tell

Is it just my imagination, or are you closing and then re-opening the same database? If so, why are you doing that? If you just want to run the .Initialize code for some reason, that can be done directly.

Also, I would think you could get rid of the delay and just have one run code with both statements on a single line, with just a space in between.

That’s correct. I’m not the best at error handling, and there were situations in which the program hung up. I use Hazel to catch those.

At your suggestion, I’ve switched from force-quitting Panorama to calling the .Initialize procedure using an Applescript in Hazel. This seems to be working. Using the Console, I’ve noticed that in instances where Panorama didn’t respond to the Hazel script, the .CurrentRecord procedure was looping.

I added a check in the .CurrentRecord procedure to see if the file Hazel had watched and renamed was missing, and if it was, called .Initialize, which has worked.

It’s possible I’ll have to have a third check in Hazel that quits and restarts Panorama, but will wait to see.

Thanks

the .CurrentRecord procedure was looping.

Here is a quote from the documentation for the .CurrentRecord procedure:

However, we recommend that you keep this procedure as short as possible, and actually strongly recommend avoiding use of the .CurrentRecord procedure altogether if at all possible , since it can cause performance problems

When it says “as short as possible”, one thing that means is you should probably never use a loop in the .CurrentRecord procedure.

I really kind of regret including the .CurrentRecord procedure in Panorama. It’s just too powerful, too tempting for using it to try to rewire the way Panorama works in fundamental ways it was never intended for. The cat is out of the bag, but if you use it beyond the limited recommended usage of initializing a variable or a graphic object, you should expect problems.

It sounds like you have a Panorama database that you want to run 24/7, so that it is always available. That is especially the kind of situation where you should avoid pushing the envelope. I would strongly recommend that you evaluate your application and try to come up with a solution that doesn’t involve a loop in the .CurrentRecord code, or better yet, doesn’t use any .CurrentRecord code at all.

Thanks for the recommendation. I’d been using it to update record-specific numeric totals while browsing older records while developing in simulation mode, but I’d left those procedure calls in. I’ve removed them and only have the check to reinitialize now.