OK, I think Pan X is trying to tell me I have an error somewhere…
I can’t close ANY window, and I can’t Quit Panorama, so I Force Quit.
It DID say it was a Closewindow error, so I removed that statement from the code, as you can see, and the errors stopped occuring.
(And BTW, I did drag those multiple error windows around the first time it happened, as they were all stacked up, and then I couldn’t close any of them. The next time it happened, I just clicked the red close button on the top error window, then the next, then the next… until they were all closed, and I was able to get back in control.)
I’m guessing the problem was that after I printed to a pdf, Preview opened up and was in front, and Panorama got upset when the code tried to close a window in the background? And why are there so many errors generated?
GoForm “Invoice”
if «Invoice Date» = 0 // If Invoice date is not set…
«Invoice Date» = today() // Set to today’s date
endif
PrintOneRecord dialog
// CloseWindow
Sometimes the process of opening the Error Window generates additional errors. There was a fix made in September to address this issue, apparently the problem was not completely fixed for all possible scenarios.
This happened me a couple days ago too. I thought my iMac had been swapped for a Windows box for a minute!
cw
1 Like
FWIW, it still occurs with the latest b30 release.
Is there a way to trap this so that it only occurs once?
TIA,
– Mark
I just closed a stack of about 25 or more that had the same error being reported.
In this case the error was: ObjectAction statement can only be used in a form window. This was in spite of the active window is a form and has the targeted object. The actual error was that I went to the Desktop while the procedure was running. If Panorama isn’t the active app, the error occurs for me in a number of places.
I’ve tried to discipline myself and the client to not touch anything when we have any one of several involved procedures running. These procedures are reliable if we control ourselves, but are just as reliable at failing if we click on anything.
I have been applying Gary’s suggestion about magicwindow in ObjectAction error but it’s been a bit elusive to get it working in all scenarios.
I guess this is kind of a gray (undocumented) area on the outskirts of the magicwindow statements. I know for a fact that using bringtofront or sendtoback will cause major problems if executed while Panorama X is not the active app while using magicwindow preceding it. Most other things I have tried have not had a problem under these conditions. Well, I haven’t really tried all that many things, just the ones I needed for my purposes.
yeah. me, too.
it sure would be nice if switching apps didn’t cause these kinds of failures.
As many have learned (or experienced), altering the active app while a Panorama procedure is running can be ‘problematical.’ This not new but yes, I was hoping that Panorama X would put this to bed. The memory of touching the interface while doing a 45 minute upload to Panorama Enterprise server was not a good one.
In a procedure that pulls monthly statistics from 32,000 records representing about 36 months, I have a LoopArray that takes about 12 minutes to get through each of the desired items. If the flu set of statistics is desired, it takes about an hour to process.
With nothing but Datasheets open for the involved databases, I just had an “error explosion”. The error claimed it was because a field did not exist and names a file that is not supposed to be the active file at that moment.
I ended up with 50 error windows. I know because I counted them as I dragged each off the stack and onto another stack.
The reason for unstacking them is in order to avoid force quitting. They need to be closed in the order in which they were generated. Only the first in the stack responds to the mouse over the Close button. Then the next, and the next, and so on.
When I close the last, one new one appears but closes without further errors.
The explosion of error windows can be avoided by ensuring that all procedure windows are closed or by unchecking Enable Advanced Error Dialog in Panorama X Preferences. This only resolves the pileup of error messages but does not eliminate this particular error.
This particular error was caused by me activating the desktop after the procedure had been running for about 20 minutes - without errors. I found that by loading the procedure with numerous OpenFile “DatabaseName”, I can move to other tasks on the computer as long as I do it when the procedure first starts. Otherwise there’s no way to see this procedure complete if you don’t keep your hands off the keyboard and mouse.
Even this solution fails if at any point I make Panorama the active app again ( even via the Dock in order to avoid activating a wrong window ) then go back to something else, like the Desktop.
With the OpenFile commands added, the error changes to claim the field is not Visible in the current window - the Datasheet in which no fields are hidden and the targeted field is visible to me.
I’m sure there is not a problem in the loop because I can cause the error in the early going by simply clicking to the Desktop. Or I just had it run for over 20 minutes without an error until the screensaver activated and caused it.
There has to be some way that Panorama can run processes between files without being the active application. As noted earlier in this thread, I’ve posted about a similar error, in which a single file has errors if graphic objects are referred to while Panorama is not active.
I doubt I can help with solving your problem. But I will just contribute this tidbit, which might have some relevance.
I was an early beta tester of PanX 10.2; and it had some problems with lengthy procedures failing if one clicked on a PanX window in a database other than the one that was running the procedure. At that time, I came up with a workaround (although I think this has been fixed by recent versions of PanX.). My workaround was to open a dialog window before the loop started. I used a dialog with a message for the user, such as “Please wait…”, and in one case, a progress bar. After the looping was finished, I put a closewindow statement. While the procedure was running, I could use other applications and PanX would continue running the procedure. The code between the open dialog and close dialog must not open any windows or alerts.
Whether this would work in your situation, I don’t know. I thought that PanX had already dealt with this problem (you have, I assume, noticed that lots of PanX menu commands are greyed out when a long procedure is running; and you can’t select any windows.)
That’s my two cents toward thinking about something you might try.