Would this be a case for introspection?

General
1

I often make a debug window that gets updated from inside some frequently occurring event within my app (like in a paint event, or a timer). I can use that to easily see what the value of a specific variable is, without having to drop into the debugger. But it’s hardwired and different for each application.

I’m wondering if there’s a way to automate this, possibly using introspection? That is, have a method in my utility module that just gathers all the key/value pairs for various variables in some object into a dictionary, then generates a nice vertical list of the variable name and its value. I do this now using text labels but as it’s hardwired, it’s a little tedious to set up so I only do it when I need it:

image
image980×988 38.7 KB

If someone has made something like this already, even better. I don’t have too much time right now to devote to this, but it seems like it’d be really useful. Like you could specify levels of depth, or you could call it specifying a list of object names whose variables should be displayed. I’m sure this is more complicated than I’m imagining, but if someone has already done this and it’s available code, I’d love to give it a try.

I’ve found that I tend to spot bugs sometimes while inspecting the variables in the debugger at runtime, that I may not have noticed yet in actual usage of the app. Having a window like this while you’re running the app would be helpful because it lets you see stuff at a glance without the debugger

2

That’s what the debugger is for. Granted, the debugger is clunky and crashy but it’s there.

1 Like
3

You can use the following to record items into the debug log.

System.DebugLog( "Variable is now : " + CStr( SomeVariable ) )

You can see the results by clicking on the fan icon in the bottom of the window. This does not alter the flow of your application so is useful for items like the Paint event.

As a workaround for not having watchpoints or break only ever 100 loops you can use the Break command:

For n = 1 to 1000
   If n / 100 = floor( n / 100 ) Then Break
Next

Will only stop in the debugger once every 100 times through the loop. You can make the if condition anything you want so it’s really flexible.

1 Like
4

I’m going to make a suggestion here. Instead of a single inline if statement, use a multiline if that does not contain a break and set a breakpoint. The reason is so that offer you’ve determined what it’s doing, you simply turn off the breakpoint without having to edit your code again. Additionally, if you enclose it in

#if DebugBuild
    Your code here
#EndIf

It won’t be included in your final app.

2 Likes
5

Sure, I was more concerned with the ways of using break to overcome the deficiencies of the debugger.

6

i rarely need debug at release app but when
i use a similar method for debug log into a list to store the last entrys and remove olders and show them into a debug window.

or i add a Debug method into a class and output things i need to control. could be a class Interface.

or if you speak about debug into paint event, just draw properties there direct enabled by a flag.

computed properties are also good for debugging.

i would not use introspection for general debugging.

control and debug is often in a special context.

7

thanks for the responses - sorry I didn’t reply sooner, we were away for the weekend.

This isn’t really a technical “how do I do this” question as much as one about whether anyone has done something like this before and if there are existing modules that are available.

I know how to use, and use regularly, breaks into the debugger. And in fact, all the information I need is in the debugger, yes. But it is a bit clunky in some scenarios, especially if you have to dig around looking for something.

What I am suggesting is not about display of debug information in a production version, though I could see that being handy in some cases. What I’m talking about is different - a way to discover an issue before you discover the effect of a bug on your application’s behavior. Let me explain:

There are situations where seeing realtime feedback in your UI as you’re using it can help you find thing you might not find otherwise. In my world (film and video), a VTR will display that kind of feedback in the form of error messages or alerts, or will light up LEDs that indicate something is functioning as expected or that there’s an issue.

In a more abstract way, our film restoration software has a “red only” mode, where it will display the footage you’re restoring very faintly in the background, with bright red pixels anywhere there was a fix applied on top of the background image. This is insanely useful in finding false positives that the software caught and “fixed” that aren’t actually defects in the picture. Doing at least one pass through a film in this mode is part of our standard operating procedure for film restoration, because it works so well. What I’m talking about here is conceptually similar to that.

For example, you may not notice that the value of a variable is being incorrectly set (or not set at all), if it’s then being correctly set somewhere else in your code, just after that. By the time you drop into the debugger you may have missed the bit where it wasn’t set. If that variable is being used by some other part of your application, it may not be immediately obvious in the debugger that the value is incorrect.

When you drop into the debugger and you step through your code, you do not necessarily see what’s happening in the UI as you step through the code. Yes, all the steps happen but it breaks the natural flow of using the application, so you are interacting with the app in a different, more methodical way (which has its place of course). But that may not be conducive to discovery of some bugs.

This happened to me on Friday, when I set my custom debug window to show me the value of a key variable as I was working on one issue. Turns out I’m not setting it in a particular loop like I had intended to, but it was masked because it was being set to a value in a later step. I only noticed it because the debug window I use, which happened to be tracking that variable at the moment, flashed a different value and it caught my eye. That was unrelated to the bug I was tracking down, but I was able to fix two things because I was able to see that the problem was there. I probably wouldn’t have noticed it otherwise, at least not until I wrote code that accessed that variable in that weird interim state.

I came into programming through software QA, and with no programming or CS background. I worked for a company where my job was to use their software as a user would, because I had a background in film and video, and the software was a major editing system at the time. So my approach is probably a little different, but still worthwhile, I think. A visual “control panel” of the state of my application that I can see at runtime would be immensely useful to me.

What I’m imagining is actually pretty simple: A window that contains a nested tree view of all variables and objects in an application. You can expand any section of that tree view and it remains open while you’re using the app, so that you can see what’s happening in that specific part of the code while you interact with the UI. Basically like taking the debugger’s variables pane out of the debugger and sticking it in your app, and having it update in real time as you use it.

8

in your case it would helpful to use a custom class for a value with a given range (computed properties) and a status enumeration.

because a app have very much objects and values i think a dump as tree view is not helpful.
its somehow object serialization. someone provide a source code for this here in xojo forum.

9

Back in the good old days there were some classes which gave limited debug information in a window. These days with threads you can forget to get anything like that working.