NOT Unable to Quit

Panorama X
1

Hello Everybody,

I see there was once a topic on the forum “Unable to Quit Panorama X”. My problem seems to be the reverse. The program keeps quitting on me during macro single-step.

Jim mentioned there is a known issue with single-step for Pan X. The code zips through without stopping. So I added a series of debug commands to force the macro to pause. That works - SOMETIMES.

But more often when I try to activate the next step with COMMAND-D, the macro jumps back to the first line. And if I try again, Pan X crashes, i.e. quits.

Have others experienced this behavior? Or is it just me? The only way I can see to write or debug a macro is to do so in Pan 6, copy it over to Pan X, and hope for the best. Obviously I’m not going to do that.

Is this a known issue? Is there a work-around - even a temporary one - so I can continue to master the Pan X conversion and check the results of existing macros?

Best regards,
Vic

2

Panorama X shows red warning signs in the View menu close to those procedures that contain incompatible statements. So it is very easy to find instances where you have to change a statement in your procedure.

After you have corrected those incompatibilities, maybe you will find other (e.g. syntax) errors when you simply run (not step through) the procedure, because Panorama X gives error messages (in the status bar at the bottom of the procedure window) and stops the procedure in the line where the error happens.

3

Hello KJM,

Perhaps I wasn’t clear in my note. I know that certain macros must be modified for Pan X, and have already made those modifications to eliminate the warning sign in the Action menu.

But I was referring to proper macros - those which do not have an incorrect or impermissible command entry. Those macros will run at full speed. But if the results are not what is expected, the macros cannot be “debugged” from within Pan X. It’s all (run at full speed) or nothing (cannot pause to see intermediate results). Are you able to step through macros with debug commands interspersed? Do your macros jump back to the beginning after a debug statement?

I wonder if there might be something amiss with my Pan X version. The version I am running is 10.0.0 (2648), with OS 10.11.6. Even though Panorama says I’m up-to-date, can there be a problem with just my download?

If this were a problem for others, I’m sure others would have mentioned it on the forum.

Regards,
Vic

4

Hi Vic, thought I’d drop in my 2¢ worth. First, I never use debug and single step when troubleshooting my procedures. My method of choice is to use floating message statements. Usually the message is the value of some variable I want to track at that location. If I want to force a stop at that point I simple add a stop after it. I can add several of these throughout the procedure or simply move a single one down the procedure as I go erasing the previous one or commenting it out until I have corrected the problems. Sometimes I will use a simple floating stop all by itself just to quickly see where the problem first appears.

I’m sure others have their own preferred method of debugging procedures but I have used this basic scheme for many years and am very comfortable using it with even the most complex procedure.

5

Vic,
I can confirm the same behavior with Pan X. Just now i was trying to step through a loop, and at the point it is at the first line of a block of code, when I do Step it runs through the rest of the block without stopping. The reason I was stepping was to see what it did at each of these steps and it just wouldn’t do it. To help confuse things, my program had been dying during this section because a local variable had lost value some reason. So I couldn’t see which line caused the problem, but in this debug mode it didn’t have the problem. That isn’t unusual.

All of this has been discussed before, and as far as I know it remains a mystery. Gary’s method is far too complex for me to use for what should be a simple operation. Here’s hoping Jim can get this working “as advertised”; it can be very useful.

6

Gary, that’s very helpful. I depended on stepping in all the previous versions and was dismayed when it broke in PanX. This strategy will help me a lot.
Just as an aside, I’m curious as to why it broke and why it hasn’t been fixed. Is there some kind of non-sequential processing that goes on in PanX? Jim hasn’t really said anything about it.

7

I’m with Gary - I never use debug or single step either. I use the message statement a lot and I also put arrays and other large hunks of data on to the clipboard (followed by a stop) and then paste the data into TextEdit for examination.

8

Hello To All,

Thanks for the input. I feel better knowing that it’s not something stupid that I’m doing.

Gary, I will use the “message” method you suggested. I actually have often used the message method myself, but the single-step method always shows the value of the current variable at the bottom of the procedure window anyway, so there usually is no need for a message statement so long as the debug statement properly stops the macro before continuing. But if this a method you use, it will be a good one.

For most code commands, pausing the macro at individual steps is usually not very important. Grouping, or sorting, etc. is straightforward, and never poses a problem.

The need for interrupting a macro is really needed when complex changes are being made to the database, such as when a new record is being added, or changes to a new or an existing record are being made. In these cases, you better make darn sure the macro is doing what you want it to do, and nothing else! Closing a sold stock record, for example, or splitting a stock record into 2 records because of a partial sale, or editing a compound’s property or thermodynamic property, etc., etc.

And especially when a calculated variable is used to change the value of a “DummyNumber” field in the database with a formulafill. That field’s total value may be used to converge on an iterative solution to a polynomial equation. Unless you can reliably stop the macro to look at the temporary values in the field and its total, it’s darn hard to know whether your iteration technique is converging or not, or to decipher WHY it’s not converging.

These all require each individual macro step to be examined, to see what possible problems might arise in some future run. Debugging a procedure (AS WE ALL KNOW) can be fraught with unknown problems, and it’s essential to carefully examine each step to see what might cause errors in the future. “Current results are no guarantee of future performance”, and all that.

But, the suggestions you all made here will be useful. I hope that eventually Jim will uncover the reason for the single-step problem, and will come up with a fix. He’s got a lot on his plate, and we shouldn’t be pressing him. He is making good progress.

Best regards,
Vic

9

One final suggestion which I have used for any situation where I’m altering the database data and structure while still testing is to take advantage of Pan X’s great undo feature. At the beinning of the procedure I include this line:

startdatabasechange "ALLRECORDS","Procedure Test"

This allows me to back-step to the state before the procedure was run by selecting “Undo Procedure Test” from the Edit menu or simply hitting Command-Z.

10

Another method to check a calculated variable: Use the Formula Workshop in the Help menu to check the calculation. (Use the message or notification methods to watch the value of a calculated variable changing in a loop.)

11

Wow, Gary. I didn’t know about that command. I must look into it. If it works for you, it must be a good idea because you have written some fantastic procedures!

But even so, Jim, please keep working on the debugger.

Regards,
Vic