I have some systems set up like Jim Rea’s and some other systems set up like Jim Cook’s. It is all dependent on the method of screen sharing, the software used, and the security settings. As is most often the case, you can have it whatever way you configure it. Different security requirements cause me to use different configurations on different computers.
I fully agree, and knew that from the start. It was just a hope that you or someone knew how to deal with it.
It’s surprising how little info I’ve been able to find about the topic of installing for one user versus all users, or other peripheral info on the topic.
As Robert has noted, there are many options in configuration in addition to all the operating systems. I’m fortunate enough to have an extra server to test with, but it takes a lot of time to fully realize the results of each tweak.
If I find a solution I’ll surely share it in the unlikely but not impossibel chance that someone else may encounter it.
The problem occurs when the screen is initially locked. That is where the security configuration occurs. I am imagining that you are using all Apple for your screen saving. One method that I find to be the least intrusive and easiest to implement is to achieve security through the screeen saver.
This ensures security with no logging out. Then use Apple’s ‘Screen Sharing’ app.
This combination will give security with only the current user login knowledge needed without logging out. Of course the screen saver can be turned on by time, or by mouse position. This method has worked over many iterations of the OS.
Agreed, and that’s pretty much along the lines of what’s been set up here.
In trying to emulate the server’s settings, I’ve been able to match it all except for one thing that might be the difference. When I first access the server via screen sharing, the name of the computer appears in the upper left corner with the word “Locked” appearing underneath it.
On my own, it requires me to log in, but it never shows as locked.
Locked means that the computer is running headless. A nice, clear indicator. 
Meanwhile the issue remains unresolved and I continue to dig.
Mine runs headlessly. A monitor connected to theirs makes no difference. And my hair thins.
I have never seen anything like that.
It turns out that the provue.com server does have a second admin account, so that probably isn’t the problem. Though of course it could work differently on different versions of macOS. The provue.com server is running 10.14 so that it can continue to run Panorama 6 Server (for now, so that Panorama 6 registration/activation still works).
Sorry that I don’t know what the problem is, I’ve got absolutely no clue.
Nor am I expecting one at this point. Just sharing info and answers as I find them.
While still working on this issue, I’ve started running into an asyncCallbackLabel error. It has occured when I was not logged on via screen sharing so I’m having trouble figuring out where it comes up. And it’s only come up twice even as the timer runs the same process numerous times.
View Search doesn’t find it in any library files and it’s not in my code.
But is this any clue?
The Panorama statement CLIENTQUERY uses a local variable called asyncCallBackLabel. This statement is used every time the client needs to contact a Panorama server, so, a lot in a shared application. I take it your timer is performing some sort of shared database operation?
This statement contains about 300 lines of code, but only a handful reference this variable.
try
...INITIALIZATION CODE...
let asyncCallbackLabel = getdictionaryvalue(queryDict,"ASYNCCALLBACK")
...LOTS MORE CODE...
catch
let errorMessage = info("error")
if asyncCallbackLabel<>""
// return error to async code
...
return
endif
endcatch
If an error occurs in the initialization code, it would cause the alert you are describing to appear.
So, the million dollar question is - why would there be an error in the initialization code? It’s pretty simple, just setting up some local variables with parameters passed to the statement. However, some of this setup is reference the user account name and information. If Panorama is not logged on, perhaps that could cause an error. That’s the only possibility I see.
I’ve modified the code in CLIENTQUERY, adding a catcherror( like this:
if catcherror("",asyncCallbackLabel)<>""
However, that won’t really fix the problem, just change the error reporting. The solution is going to be fixing it so that the user account remains logged on, even when you are not actively screen sharing. Panorama is simply not going to work if the user account is logged off while Panorama is running.
Thanks, I’ll try the catcherror(. I’m assuming that replaces the entire catch thru endcatch.
And FWIW, the timer does open and run a search in a very modestly sized, shared, database to see if there are any tasks to be performed. The user account is not being logged out and far more often than not the procedure runs successfully. The timer is also running in Panorama on the same machine as Panorama Server.
There’s a shortcall that seems to be where the error comes up. When bypassed, I haven’t seen it, but then it has only come up three times in a script that has run over and over today. It has only occurred when I’m not connected via Screen Sharing too. Vague, I know.
The shortcall is a cleanup after one or another task has been run. Today I’ve had most tasks disabled in order to narrow down the possibilities.
ChoresDB is shared and is the only file being accessed (opened and closed) today. The procedure does synchronize when the file is opened. The other files are single user. I’ve altered their names in the array below for the client’s privacy and security but there’s nothing unusual about their names and they have not been accessed while getting this error today.
Otherwise I’ve left out nothing in case there’s some less than obvious error on my part.
CloseFiles:
OpenFile gvMonitor
Let lvDbases = "ChoresDB,OneFile,AnotherFile,AndAnother,PlusThis"
looparray lvDbases,",",lvFile
If dbcheckopen(lvFile) = true()
CloseDatabase lvFile
If error
nop
Else
gvStatus = "Closed "+lvFile+" @ "+timepattern(now(),"hh:mm am/pm")+¶+arrayrange(gvStatus,1,50,¶)
EndIf
EndIf
EndLoop
OpenFile gvMonitor
fileappend dbpath()+"Logs",datepattern(today(),"mm.dd.yy ")+"Monitor.txt","TEXTttxt",cr()+"Files Closed @ "+timepattern(now(),"hh:mm am/pm")
Rtn
Sorry to mislead you, there is no change for you to try. I was just thinking aloud to try to explain what I figured out about how that alert could be generated.
Even if you could make this change, it wouldn’t fix the problem. The change is in error handling code – the error isn’t being handled correctly so an alert appears. With the fix that will be in the next release, the error will be passed back up to whatever code called CLIENTQUERY. What happens then is up to that code, but there was definitely an error so it won’t be what you wanted to happen.
Also, I don’t really understand how this error could occur. It could only happen if there is an error in the 10 lines of code that run before the asyncCallBackLabel variable is defined. But those 10 lines of code do nothing other than set up some other variables. There’s no logic involved, no opportunity for an error to happen.
Ok, then I haven’t understood your previous posts. You said that every time you connect to the server via screen sharing you have to log in, since you have to log in I was assuming you were logged out. I guess I have no idea what you are talking about. I can say that on my servers I don’t have to log in each time I connect via screen sharing, even if they have multiple admin accounts. Yes, the password needs to be entered to enable screen sharing, but I don’t have to select the account.
In any case, I have never heard of Panorama working differently depending on whether screen sharing is currently connected or not. I have no idea how that could happen but I think you need to solve this first - it may solve all of the other problems.
The CLIENTQUERY code is called for any server operation. For a shared database that means when the file is opened, closed, synchronized, record locked, record unlocked (change committed), and other things like fills. It’s also used by the Server Admin wizard, and when you upload or download - it’s used constantly. In fact, I just checked, CLIENTQUERY is called in at least 67 different places.
Let me offer a thought on this, not really based on anything factual but just my gut feeling. If I was doing this, I probably would not cleanup. Memory is cheap. Why not just open all of these files once when you start up, and leave them open indefinitely? Does the cleanup actually buy you anything?
Actually, what I would probably do is open all of the files without windows and program them to run without windows, and leave the files open (without windows) all the time. But I understand that may be a lot of work for your existing application.
It’s been accepted that overall this is not a Panorama issue although I’ve occassionally added new information to the thread.
So, for clarity, we are not logging out of the Panorama account. Neither Panorama or the timer would be expected to wotk under those circumstances.
When I’ve referred to logging in or out it has been in reference to accessing the computer via screen sharing. The problem has been that unless we’re logged in via screen sharing Panorama runs as if it’s in the background. This is in spite of the inclusion of bringpanoramaforward.
Apple Memory is about the most expensive commodity in the world (or so it seems). Probably more expensive than Saffron or Tritium.
Once Apple puts AI into its M4 chip, I heard a rumor that Apple Memory will try to establish its own country.
Have you tried using magicformwindow while Panorama is running in the background?
Since there is selecting and data processing involved in order to generate PDF reports, it is necessary that various databases are fully accessed.
I’ve used this function extensively in my Pan Audio Player (Panorama Database Exchange) to keep the display updating while Panorama is in the background with other applications up front. Don’t know how effective this might be for your use however.
I’ve not done well with magicformwindow in other situations. It’s likely me, not Panorama, or the circumstances under which I was trying to use it.
After many whole days sunk into this issue, it’s among the things I’ll have to try.
It appears that Panorama cannot be automated to run on a server.
Connected to a server via screen sharing, I can start a timer to run a simple task of opening another database, selecting some records and closing the database. As long as I stay online it works. Apparently the timer stops as soon as I close the screen sharing window. I closed the screen sharing window and came back to find the timers had quit.
So, whether it’s Panorama or the OS, I continue to need Panorama to carry out some tasks on the server using multiple files.
In trying to create my own cron program to handle this I found that there are different places to save a plist for launchd depending on the targeted users. I can’t see that Panorama is using one or another of these but it did make me wonder if Panorama is saving something for use only with users logged in versus when NO users are logged in. I’m guessing that when I close the screen sharing, it amounts to no users logged in.
- /Library/LaunchDaemons - Put your plist scripts in this folder if your job needs to run even when no users are logged in.
- /Library/LaunchAgents - Put your plist scripts in this folder if the job is only useful when users are logged in. (Note: I learned that this has the side-effect of your job being run as ‘root’ after a system reboot.)
- $HOME/Library/LaunchAgents - Put your plist files in this folder if the job is only useful when users are logged in. (When your plist configuration file is placed here, your job will be run under your username.)
I just double checked to make sure. There is a copy of Panorama X running on the provue.com server, and it is running a timer. It definitely does not quit when the screen sharing window is closed.
My timer is much simpler than that, it doesn’t open any windows or perform any action that requires a window.
A timer will quit if it encounters an unhandled error. So maybe that is what is happening for you. You can change this behavior - see the error and continueaftererror discussion in starttimer. Or, a better approach would be to use try/catch to cover the entire code in your timer. If an error is encountered, you can find out what it is with info(“error”) and log it in a file. Then later you can come back and see what is going on. I would definitely recommend this approach for an application like yours where you want it to run unattended.
There are no errors as long as I sit there and watch, or as long as I keep the Screen Sharing active. It runs endlessly in that scenario. On both an i7 and an M1 processor, the timer stops when the Screen Sharing window is closed.
The screen shots below show both cpu’s one running the timer at 15 seconds, the other at 60. I closed the Screen Sharing windows and came back about 15 minutes later and neither had progressed from when I closed them and the Timer Workshop showed the timers as non-existent.
The script that starts the timer:
LetGlobal gvStatus = ""
stoptimer "DoThings"
If error nop EndIf
starttimer "DoThings","background","yes","interval",15,"next",supernow()+30,"scope","global","code",{BringPanoramaForward
FarCall "Monitor",".DoThings"
ShowVariables gvStatus}
gvStatus = "Timer Started @ "+timepattern(Now(),"hh:mm am/pm")+cr()+arrayrange(gvStatus,1,100,¶)
ShowVariables gvStatus
fileappend dbpath(),datepattern(today(),"mm.dd.yy ")+"Monitor.txt","TEXTttxt",
cr()+"Timer Started @ "+timepattern(Now(),"hh:mm am/pm")
And the procedure it runs:
gvStatus = "Cycle Started @ "+timepattern(Now(),"hh:mm am/pm")+cr()+arrayrange(gvStatus,1,100,¶)
ShowVariables gvStatus
fileappend dbpath(),datepattern(today(),"mm.dd.yy ")+"Monitor.txt","TEXTttxt",
cr()+"Cycle Started @ "+timepattern(Now(),"hh:mm am/pm")
OpenFile "Lists & Matrixes"
If Error
gvStatus = "OpenFile error @ "+timepattern(Now(),"hh:mm am/pm")+cr()+arrayrange(gvStatus,1,100,¶)
ShowVariables gvStatus
fileappend dbpath(),datepattern(today(),"mm.dd.yy ")+"Monitor.txt","TEXTttxt",
cr()+"OpenFile error @ "+timepattern(Now(),"hh:mm am/pm")
Rtn
EndIf
SelectAll
Field Author SortUp
Select Author contains randomletter("x")
Let lvCount = str(info("Selected"))
Save
CloseFile
gvStatus = lvCount+" Selected @ "+timepattern(Now(),"hh:mm am/pm")+cr()+arrayrange(gvStatus,1,100,¶)
ShowVariables gvStatus
fileappend dbpath(),datepattern(today(),"mm.dd.yy ")+"Monitor.txt","TEXTttxt",
cr()+lvCount+" Selected @ "+timepattern(Now(),"hh:mm am/pm")
gvStatus = "Idle @ "+timepattern(Now(),"hh:mm am/pm")+cr()+arrayrange(gvStatus,1,100,¶)
ShowVariables gvStatus
fileappend dbpath(),datepattern(today(),"mm.dd.yy ")+"Monitor.txt","TEXTttxt",
cr()+"Idle @ "+timepattern(Now(),"hh:mm am/pm")
gvStatus = info("WindowName")+" @ "+timepattern(Now(),"hh:mm am/pm")+cr()+arrayrange(gvStatus,1,100,¶)
ShowVariables gvStatus
fileappend dbpath(),datepattern(today(),"mm.dd.yy ")+"Monitor.txt","TEXTttxt",
cr()+info("WindowName")+" @ "+timepattern(Now(),"hh:mm am/pm")
Yes, it’s opening and closing a file. That’s necessary and other than updated code, overall it’s the same as what I ran (and still have running) on several Pan 6 servers for years using ExecuteEveryMinute. It seems unachievable with Pan X regardless of the fault being in Panorama or the OS.
Here’s the simple two-file set