MessageBox as a 'Debugging' Aid

Getting Started
1

I’d like to use the MessageBox to track what’s going on during program execution. (Is there a better way?) Here’s a sample that fails.

Sub Pressed()
// The DB file will be on the desktop
Var dbFile As FolderItem = SpecialFolder.Desktop.Child(“example.sqlite”)

// Create the SQLite DB
App.DB = New SQLiteDatabase
App.DB.DatabaseFile = dbFile

MessageBox("dbfile " + dbFile) <<---- Fails here. Str(dbFile) also fails.

2

You want:

MessageBox ("dbfile: " + dbFile.name)
1 Like
3

Sometimes doing this can interfere with code execution because it inroduces a UI operation within your code that MAY impact execution. Typically better is to use debug mode with a breakpoint, or instead of a MessageBox() output to the log using something like:

System.DebugLog "dbfile: " + dbFile.name

then you can view in the debugger in the bottom console pane.

2 Likes
4

Ah, dbFile is an object that has properties. Got it! I tried the line and Xojo complains: " MessageBox("dbfile: " + dbFile.name) " , with the MessageBox highlighted, that the item does not exist.

5

I think I always say MsgBox. I can never remeber what the replacement is.

Don’t forget what @Douglas_Handy said, however. The debugger can help a lot.

6

Does the file exemple.sqlite exist before running this line ?

7

Thanks for the alert and the advice. I’ll do the ubuiquitous ever-handy print() (MessageBox) for now. Then. on to the good debugging stuff.

“The toughest point in a journey is the start; there the hurdles are high, and there’s a lot of dead bodies along the way that perished doing the tutorials.”

Trying not to be a casualty here.

8

Yes, example.sqlite does exist.

9

Interactive debugging is your friend. You should become acquainted.

If nothing else, try replacing “MessageBox …” with simply Break and run from the IDE and see what happens.

3 Likes
10

I used to use a MessageBox as well. I switched to System.DebugLog though. But, I occasionally I still use it. But a little bit customized though.

If you prefer the MessageBox way, it might be useful to create a public function instead. I sometimes forgot to get get rid if all the debug messages.
If you create a public function, you can include an “If DebugBuild Then” condition. So, the message only appears when you debug your app.

Additionally, you can make the Message function a little bit more flexible by using a Parameter Array. That way, you can pass multiple message lines easier.

Function MyMessage( ParamArray Message() As String )
    If Not DebugBuild Then Return // If you don't run the app in debug mode, no message will be shown.
    If Message.Count = 0 Then Return // if no message value is passed, no message will be shown.

    MessageBox String.FromArray( Message, EndOfLine ) // This will display the message values as multiple lines.
End Function

You can simply call your custom function like this:

MyMessage "Error found", "CurrentMethodName", "More detailed explanation"

When your final build hits this last line of code, nothing will happen.
But when you run the app in debug mode, within the IDE, a MessageBox will open with Three lines of code:

Error found
<name of the method, from where the function is called>
More detailed explanation

Disclaimer:
I didn’t test the above code, since I am not with my IDE now. But, I think it should work. I use it all the time.

1 Like
11

Thank you very much. I am now reading the Debugging article in the documentation. Yes, I do need a quick & dirty way of finding out what where. I will try your suggestion. Here’s hoping you get good weather where you are.

12

Much better than a messagebox, use system.debulog().

It shows the message in the message pane of the IDE, without interrupting the program.

https://documentation.xojo.com/api/os/system.html#system-debuglog

In a compiled program, debuglog outputs to the system, so you can use debugview to see the message.

1 Like
13

From the documentation:

Warning

You should avoid using MessageBox for displaying debugging messages. The displaying of the Message Box will alter event order and may give unexpected results. Instead use the [Debugger]

1 Like
14

Yes. Try to understand what do the code you wrote.

For example, Var dbFile As FolderItem

go to the documentation and read what is a FolderItem. You will discover that it have plenty Properties (24), have Methods, etc.

Then, as was already adviced, use System.DebugLog (read the documentation to know how to read the reported lines).

At this stage, you will have made tremendous progress and become ready to develop a software.

We all started somewhere.

1 Like