When I ask FireFly's help file about "debug" or "debugging" or "#debug" it says "no topics found".
The table of contents has no entry for this subject.
Searching the message board produced one reference to code like:
debug.print "message text"
but this syntax won't compile.
I can add #Debug Print statements and the code compiles and runs w/o error. Where is the debug output window? If I run PB8 simultaneously, the debug window in it does not show my debug output, or any other output.
If I bring my generated code to JPro and run the .bas file I do get output in the PB8 debug window, but not from my #debug print statements.
===
How does one go about debugging in FireFly?
NOTE - I'm looking for logic/usage errors in code that compiles w/o error and runs (more or less), but doesn't behave as intended.
Thanks,
LB
Hi Larry,
Debugging... ah, one of the bane's of dealing with PowerBASIC code. As you have found out, there is no really good way to debug code from inside
FireFly. The #Debug statement only works when the PowerBASIC
Debugger is running. When a FireFly project is compiled to an EXE or DLL then all #Debug Print statements are ignored (per PB's Help).
When FireFly creates your EXE it will simply run it. It does not interact with your EXE once it is running. If you come from a Visual Basic background then you'll have to leave behind the thoughts that you can run your program and step through code like in the VB environment.
Quote from: Larry Burford
Searching the message board produced one reference to code like:
debug.print "message text"
but this syntax won't compile.
As well it shouldn't. Looks like Visual Basic code to me. Most any command with a dot "." in it is similar to the VB style function.method stuff.
QuoteI can add #Debug Print statements and the code compiles and runs w/o error. Where is the debug output window? If I run PB8 simultaneously, the debug window in it does not show my debug output, or any other output.
Like I said above, FireFly has not interaction at all with the PowerBASIC Debugger. You would run into the exact same problem if you attempted to run PB's PBForms, Chris' EZGUI, Dominic's Phoenix or Edwin's PwrDev.
QuoteHow does one go about debugging in FireFly?
You can insert MsgBox's at certain key places to evaluate variables.
You can create a temporary Label control on your Form and update it with the values that you want to query (use FF_Control_SetText).
Now that you mention it.... maybe an FF_Debug style function would be pretty good. I could have it conditionally compile into the FireFly code and pop up a debug window at the EXE's run-time. That would be certainly a worthwhile addition.
[Paul] "Now that you mention it.... maybe an FF_Debug style function would be pretty good. I could have it conditionally compile into the FireFly code and pop up a debug window at the EXE's run-time. That would be certainly a worthwhile addition.
I'll vote for that. And in the mean time ...
[Paul] "You can insert MsgBox's ..."
(Gag, choke, shiver ...)
[Paul] "You can create a temporary Label control on your Form and update it ... "
Now *this* sounds like a decent work-around, but I think I'll use a listbox, and a debug function [Sub Debug(msgString) ... ]
Thank you,
LB
Here is what I have been using for debugging. The code comes from the PB site(Don't remember from). It is a lot nicer when you have 2 screens so it doesn't get in front of the working program
$ConClose = "$CON:CLOSE"
SUB DEBUG (st$)
STATIC Hwnd&
LOCAL szConsole AS ASCIIZ * 255
IF Hwnd& = 0 THEN
ALLOCCONSOLE
SETCONSOLETITLE "PBDLL Console"
Hwnd& = GETSTDHANDLE(%STD_OUTPUT_HANDLE)
SETCONSOLETEXTATTRIBUTE Hwnd&, %FOREGROUND_RED OR _
%FOREGROUND_GREEN OR _
%FOREGROUND_BLUE
END IF
IF Hwnd& > 0 THEN
' a magic word that close console
IF st$=$ConClose THEN
FREECONSOLE
Hwnd& = 0
EXIT SUB
END IF
szConsole = st$ & $CRLF
WRITECONSOLE Hwnd&,szConsole,LEN(szConsole),%NULL,%NULL
END IF
END SUB
Bert
I just tried the debug code Bert posted. THANKS! WOW! COOL! WONDERFUL!
This will simplify debugging for me! MessageBoxes have nasty undesireable side effects of doing things to the natural flow of field focus.
With a little thought and some conditional compile metastatements this will work nice.
NOTE TO PAUL
Maybe you can incorporate this into a future FF release using some custom FF metastatements. It could be nice to add just one simple line of code to do things like see the content of a TextBox, variable, etc. If it was a custom FF metastatement then one additional custom FF metastatement could turn debug on/off at compile time. I know I could combine a FF_GETTEXT function with Berts debug call into one line but it would be a little ugly to type if you needed more than a couple.
A few global FF metastatements could provide a field trace function that would post a debug message for every SETFOCUS or KILLFOCUS without having to add any lines of code. Another global metastatement could combine with this to include a specific control value or variable value display as the focus changes providing a sort of WATCH function.
You could even provide the standard display code as a source module and the user could modify it to add custom debug features with a FF metastatement just simplifying the call.
Food for thought.
Thanks
Thanks guys, I have noted the request in the FireFly bug/feature tracker. Actually, it was already there so I just added Bert's code to it.
This is not my code but I sure do make good use of it.
Bert
I use OutputDebugString() in the code and use sysinternal debug viewer to capture the output. It automatically logs the time and you can save the log file.
Edited: Just realized that what I first posted was written in DDT. So, I have replaced that code here with the following improvement to Bert's code (a little more useful syntax, I think).
$ConClose = "$CON:CLOSE"
'syntax: debug v1 [v2, v3, ... v6]
'where v1...v6 can be strings, integers, or floats
'--------------------------------------------------------------
SUB debug(OPTIONAL BYVAL v1 AS VARIANT, _
OPTIONAL BYVAL v2 AS VARIANT, _
OPTIONAL BYVAL v3 AS VARIANT, _
OPTIONAL BYVAL v4 AS VARIANT, _
OPTIONAL BYVAL v5 AS VARIANT, _
OPTIONAL BYVAL v6 AS VARIANT)
LOCAL i AS LONG, n AS LONG
LOCAL s AS STRING, szConsole AS ASCIIZ * 255
STATIC Hwnd&
IF Hwnd& = 0 THEN
ALLOCCONSOLE
SETCONSOLETITLE "PBDLL Console"
Hwnd& = GETSTDHANDLE(%STD_OUTPUT_HANDLE)
SETCONSOLETEXTATTRIBUTE Hwnd&, %FOREGROUND_RED OR _
%FOREGROUND_GREEN OR _
%FOREGROUND_BLUE
END IF
DIM v(6) AS VARIANT
v(1) = v1 : v(2) = v2 : v(3) = v3 : v(4) = v4 : v(5) = v5 : v(6) = v6
FOR i = 1 TO 6
n = VARIANTVT(v(i))
IF n = 8 THEN
s = s + VARIANT$(v(i)) + ", "
ELSEIF n <> 0 THEN
s = s + STR$(VARIANT#(v(i))) + ", "
END IF
NEXT
s = RTRIM$(s, ANY ", ")
IF Hwnd& > 0 THEN
' a magic word that close console
IF s = $ConClose THEN
FREECONSOLE
Hwnd& = 0
EXIT SUB
END IF
szConsole = s & $CRLF
WRITECONSOLE Hwnd&,szConsole,LEN(szConsole),%NULL,%NULL
END IF
END SUB
Very nice, Charles! Got potential, that.
Minor thing, is it OK to close the console while the parent is still running, will it create memory leaks?
With some trepidation I present my debugging technique. Everyone might
think it horrible, but to me it is brutally simple, here goes...
I open a text file called Output.txt and blow whatever I want out to that. Works wonderfully for me. Since I work with databases a lot and do a lot of hard core data processing I can output lots of intermediate results, SQL query strings composed at run time etc. Believe it or not, that is also what I do when using VB or VC++ or C or whatever. Recently wrote a C
program for a handheld (Win CE) and did same there. I've always hated printing stuff out to message boxes. Just saw that code for outputting to a console, and that looks like it has possibilities, and I might try it.