I’m betting that there is a smarter way to do what I’m doing.
When I am debugging a long procedure, I used to include a lot of Messges. When I was wanting to not display them, I commented them out. Then I could later turn them on again as necessary.
I then later created a Debug mode and checked to see if I was in Debug mode and only displayed the messages when needed.
Then I later recognized that I really needed to sometimes Stop the procedure when I saw that it had gone off the rails and needed to alter the code. What I have at the moment is a lot of code that really should not be necessary to have the opportunity to be in debug mode and see certain values or stop a procedure. This is what I have lots and lots of time in a procedure.
Local LDebugMode AlertYesNo "Are you in debug mode?" If Info("DialogTrigger")="Yes" LDebugMode="Yes" Else LDebugMode="No" EndIf
If LDebugMode="Yes"
Alert "Continue,Exit Debug Mode,Stop Procedure" FGBoatVSailsCriteria + ": Boat V Sails= " + Info("Selected")
If Info("DialogTrigger")="Stop Procedure"
Stop
ElseIf Info("DialogTrigger") = "Exit Debug Mode"
LDebugMode = "No"
EndIf
EndIf
Is there an easier way to accomplish what I think every programmer needs or would like to do?
Robert, have you taken a good look at the new Debug Instrumentation feature in Panorama X 10.2? (For those of you not signed up for the 10.2 preview, you’ll have to wait a bit longer for this.)
If you want to have code that only runs when instrumentation is enabled, use the zlogging( function.
ZLogging will only eliminate the LDebugMode portion of my code.
What I’m looking for is an easy way to report the value of a variable, then be able to easily Continue, Stop the Procedure, or Exit debug mode. I can not see how ZLogging does any of this.
The procedure at hand calculates lots of different values and many later values are based on previous calculated values so there is much need to have dynamic reporting of the situation as the procedure moves through the process. Stopping it when necessary, which is no longer supported with the Command-Period has only made the situation worse. Then too, if I am early in the procedure and want to then ‘let it run’, I can not turn off debug without my code.
The new debug instrumentation is all about reporting values. You view these values in the console or terminal, there’s no need to stop. I do a LOT of debugging of Panorama code problems, and in my opinion this is the best thing sinced sliced bread. I just used instrumentation to quickly track down multiple issues today.
You also have access to a 90 minute video on this topic.
P.S. I would replace all of the code in your original post with this:
I can’t say that I’m a fan of Instrumentation and zlogging over being able to single step through a procedure.
I’ve been inserting line after line of zlog comments into a crashing procedure through a couple of dozen crashes and am still only narrowing it down to the source of the crash. Stepping through it would have found the very line of the crash after only one or maybe two crashes.
Instrumentation requires getting the Instrumentation, et al, set up again after each crash too.
Just to be clear, I’m not dissing Instrumentation. It has been extremely useful to me when writing code and tracking the content of variables or the state of certain data. Stepping through procedures is simply a highly desirable alternative that is particularly helpful in pinning down the point of a crash or error in a large procedure, especially if it’s already written.
Instrumentation was not implemented as an alternative to single stepping. I created instrumentation because I was finding myself unable to debug problems in the new database sharing system. I needed a system that could be used for debugging code on the server. It turned out to be very useful for single user code as well. In the past year, it has probably saved me at least several weeks of debugging time, and that’s beyond the several weeks it took to create the logging system. My regret at this point is that I didn’t decide to implenent instrumentation earlier.
Single stepping is a feature that was added after the fact, I think in Panorama 3. There was always intractable problems with single stepping, which I thought were due to the fact that it was added in and not planed from the start.
So with Panorama X, single stepping was designed in from the start. I had high hopes for a much better working system. But it turns out that the problems before weren’t just because single stepping was added in later, but because of the complex way that Panorama’s procedure code interacts with the operating system. Unlike other programming languates, Panorama allows you to do things like update on the screen, open and close windows and then your code just continues as if nothing has happened. You can’t do that in C, Swift, Python, etc. Panorama performs a complex dance with the operating system to make that happen with you being none the wiser. I documented some of this dance in this new help page, which I also covered in a session a couple of months ago. But there’s quite a bit more than even what is covered there.
What I haven’t been able to do is keep that juggling act going while also starting and stopping your code for single stepping. It’s not that I decided it was an undesirable feature – it’s that I came to the realization that it was a feature that was beyond my capabilities to create. Yes, other programming languages have single stepping – but they don’t interact with the operating system the way Panorama does. They require the code (your code) to manually take care of the operating system interactions that Panorama takes care of for you.
Over the last several years I have spent more time than I would care to admit trying to figure out how to get single stepping to work. Eventually I realized I was just banging my head into a wall. Perhaps I’ll take another run at the wall someday. But I know that it’s not like there is some single key that will unlock and make it workable.
Long story short, instrumentation was created for it’s own purposes, and has nothing to do with whether Panorama can single step or not.
Your background on all sorts of Panorama aspects is always insightful for those of us who get to put targets on the wall for you to bang your head against. Don’t mistake my gripes as any lack of respect or appreciation for the incredible product you’ve created. In spite of a lot of my own head banging today, I turned out some pretty awesome procedures ( in my humble opinion ) that the tools in Panorama made possible.
I will take the opportunity to repeat an observation/comment I have made earlier. Seems like it is related to this subject, a cousin at least…
If a procedure begins running and the user clicks on a PanX window in a different database, the procedure switches its frame of reference. So, for example, if you have the name of a field in a line of code that is reached after you click the other window, PanX will look for the field in the newly clicked database. This will very likely lead to a failure of the procedure.
To avoid this problem, I created a statement I call PleaseWait, which opens a modal dialog and displays a message, such. as, “Please wait while I prepare your report…” Eventually the procedure reaches a closedialog statement which closes the dialog and allows other things to proceed. Something about a modal dialog disables mouse clicks and possibly other input.
I know that Jim is aware of this issue and has created a Bitbucket entry, but I thought I would just mention this again. Although there has not been much response from others, to me this seems like a very serious issue.
