Debugger doesn't work

Hello, i try to debug on Linux/Windows with Xojo.

Example:
a(3) and b as integer / defined in a module (global)

For b = 0 To 4
a (b) = 5
Next b

In the most of cases the debugger shows little or useless information, like in this case (exception), but no value. On VB6.0 i hoover over the variables and get b = 4. On Xojo i get nothing.
My way is to write the values in the title. But it’s a torture if a lot of values are in use.
Is there a hidden switch for “unhide debug informations”?

The VB hover thing has been on the feature requests for 20 years. What is “little or useless information”?

1 Like

Things like: self, Globals, content, App, etc.

There have been a lot of very necessary but very simple things on the “ignore list” for 20 years

What is bad? Don’t leave us guessing.

I bought RealBasic 2013, and the errors are still the same

Every variable is available in the debugger. If you want to see globals you have to open the globals. If you want to see modules you need to look in modules. Could it be better, yes very much so, however, it does show everything, if you look in the right place.

My request for Watch points is number 2 in feedback (yes, it now says Vanessa Gregory, but that is because I retired and she took over my account). I would love to see some improvements. <https://xojo.com/issue/1095>

If you can’t tell us what the problem is how do you expect us to understand your problem? Yes, the design of the debugger is a bit odd. But all values are there.

Open modules, select the module they are defined in and they will be there. You can even click on the array and see the individual elements values.

a(3) defines an element with indies 0, 1, 2 and 3. You have a loop from 0 to 4. You can say:

For b = 0 to a.LastIndex
    a(b) = 5
Next

and you can’t then go wrong.

Or even a screenshot…

Honestly, I love Xojo, but sometimes I hate it because very simple problems can only be solved with hours of internet research.
The debugger MUST solve problems, not create them. If several linked parameters that were declared in different modules cannot be found in the debugger after a minute’s search, I write the values in the title line. Then the debugger is useless.

Built an app with a module that defines a and b, plus a button that uses them. There is how to see them.

Clicked Globals:

Opened Modules:

Selected the module:

about 4 clicks.

1 Like

Ok, now i understand. I thought the debugger shows the error. In reality i have to search for.
(If i use complex values with arrays, the debugger search in different modules is time consuming.)
I use the title bar… that is fast and precise.

Thank’s to all! Solved!

As we said it could be better, but it does do what is required.

1 Like

Or don’t use global values. If they were local to the class, they’d be available under Self.

4 Likes

Interestingly in this case, when you code better the debugger works better.

sub pressed()
   do_something(a)
end
 
function do_something(arry() as integer)
   var index as integer
   for index = 0 to 4
     arry(index) = 5
   next
end

Now when the code breaks there is no need to go searching as the locals are displayed by default.

I don’t disagree, however, watchpoints would be a wonderful addition. Even better if you could include an expression.

You’re cheating Ian…

I understand; you reset the window size and enlarge the debugger part to not place too large images, but they are a bit misleading.

In fact, the debugger have to be a tear off… If it can be displayed in its own window (remember large screen is everywhere nowadays just like multi screens), it will be far easier to debug projects and continue to code / modify the code…

1 Like

The point was to show the data, however, this is a full window from my MacBook Pro 16" with the debugger variables area as large as it can be. It doesn’t seem too unreasonable.

in fact you can hide the inspector and make it like this:

The window is full size, but not full screen.

RealStudio, with better (imo) usage of screen real estate.

6 Likes

Ok, that’s what i mean. The debugger lags far behind the possibilities…