Page 1 of 1

PostPosted: Tue Jan 28, 2003 8:28 pm
by FrankG
Is there any fancy way to bebug an OrbForms application? So far I've used the brute force approach by putting a bunch of Alerts through the areas of my code I want to test. It's been working well - especially with automatic loading to the emulator. I'm just wondering if I'm missing some way to trace or something like that.


PostPosted: Fri Feb 02, 2007 2:22 pm
by sangahm
It's been a while since this was posted, and no one has replied. I'm wondering if everyone only uses the alerts for watching the code operation, as well as some other things available such as assertions, debug logging, debug code blocks, and runtime functions.

These seem to be very limited in terms of stepping through code, watching variables, etc. that other environments have.

PostPosted: Fri Feb 02, 2007 4:22 pm
by FrankG
I guess no one replied beacause application debugging isn't really all that difficult... I must have been having a tough time with whatever I was debugging a the time. I should take more advantage of assertions,
debug logging, and debug only code blocks than I do! :oops:


PostPosted: Fri Feb 02, 2007 5:38 pm
by sangahm
Agreed that it's not hard, but it can get very tedious especially having to click through many alerts when watching loops, in/out functions, or other frequently changing variables.

I also noticed that when modal forms are up, it keeps alerts from coming up (I guess as it should; but irritating nevertheless).

PostPosted: Sat Feb 03, 2007 1:29 am
by jobie
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">
I also noticed that when modal forms are up, it keeps alerts from coming up (I guess as it should; but irritating nevertheless).
<hr height="1" noshade id="quote"></font id="quote"></blockquote id="quote">

Definitely make use of the <b>debuglog</b> function. It's basically what we old school C programmers usually call "<i>printf debugging</i>", but it's better than clicking through alerts, especially if you're monitoring variables in a loop.

Of course, the downside there is you must be running on an emulator...but you should probably be doing that anyway until you're ready to test on hardware.


PostPosted: Sat Feb 03, 2007 1:52 am
by sangahm
I'll have to give it a try...I just thought it would be more trouble since it wasn't "real-time." It takes a different way of thinking about the process.

I always do run on the emulator/simulator first anyway, so that shouldn't be an issue.

PostPosted: Tue Mar 20, 2007 11:15 am
by kda406
I must have missed this thread earlier. My apps can rarely be debugged in the emulator; I usually have to debug on a real device. My apps make generous use of modal UIs, plus alerts can keep time critical communications from working, so my use of alerts is limited.

Instead I have a simple modal I created that has a scroll bar, an 11 line field text area, a clear button, and a close button. I copy this modal to each app I'm developing. From the home page of a given app, I'll have a resource that will open this modal. When opened, the modal displays the contents of the global string gnLog. gnLog is cleared on application start.

Anywhere I need to dump any kind of data "print style" debugging info, I append it to gnLog. For example I might put in "way" points to indicate which direction the application proceeded through the conditional processing. When the modal is opened and gnLog is viewed, it might look like:
Code: Select all
Opened communications
Requested ver from destination
Got 1.2, okay
Initiated database transfer manually

by simply constructing the string like:
Code: Select all
gnLog = gnLog + "Initiated database transfer manually\n";

All this assumes your code is stable enough to run crash free. If it is crash free, you can do <whatever> and then go back and review the "print style" log later. Very long logs can slow the processing down a little bit, but I have never crashed a PDA with the global string log file itself. I have had this kind of log work for hundreds, and perhaps even in the low thousands of lines of print style debug dumping. It has been quite effective for me.

I hope this helps you all.

PostPosted: Tue Mar 20, 2007 12:01 pm
by sangahm
Very nice. I'll have to try that next time around.

My last app had a few conditionals that was rather complicated for me to determine the input & result. I ended up using a debug log and that helped me zero in on where the logic was failing. I now use this for debugging, but I can see where your modal gnlog would work too.

PostPosted: Tue Mar 20, 2007 11:40 pm
by FrankG

Great idea!

Thank you,