The Real Studio Debugger

We all know by now that Real Software is redesigning the Real Studio IDE. For better or worse it’s coming whether we want it or not. It would really be nice if they changed the debugger to be more useful. Real Software last changed the IDE for the 2005 release and, in my opinion and many others, the debugger was a huge step backwards in usability.

In my opinion, and the feedback I get from other users, is that the Stack popup menu is not intuitive at all. In the old IDE it was a listbox which let you see, at a glance, what the call stack was that got you to the current breakpoint or exception. The popup menu is not intuitive. It confuses users. I say bring back the listbox.

As Merv pointed out in my last blog post, setting a breakpoint is sometimes an exercise in futility. The area to set the break point is maybe 8 pixels wide? Why not double the size? The UI shouldn’t be designed for 800 x 600 windows any more. Most monitors have much more width space than they used to. Make this more user friendly.

Many, many people have begged for Watchpoints in the debugger. In fact, the Feedback <feedback://showreport?report_id=1095> is currently at #13 and was entered in 2008.

An even bigger request is to have the debugger show a value tooltip while debugging. This means that if you hover your mouse over the variable ‘i’ the tooltip will show the current value. This one is at #7 and was entered in 2009.  <feedback://showreport?report_id=10536>

Make these feedback items part of your Top Cases and show Real Software we really need them.  My bitching about it won’t change it.  Only your votes can give them any indication what you want.

Now, I have no idea what changes they have in store for the debugger. What I do know is that they’ve already said the first release will not have ANY changes to it.  This is too bad but I don’t want to wait five years for a better debugger!

So my question is why do we have to wait for so long to get needed and wanted changes? What else do you think should be part of the debugger?

18 thoughts on “The Real Studio Debugger

  1. In the code editor you can get a break point without clicking in the “gutter”.
    Put the insertion point anywhere on the line & press cmd-\ and it will toggle the break point.
    And it works in the debugger as well.

  2. Great, now if I could only see the breakpoint after it is set. Joking (somewhat) of course, but I for one would give up a few measly pixels off to the right for a much easier to see breakpoint on the left. If it were bigger, then I wouldn’t mind clicking in the “gutter” as much. A dark red background on the code line in addition to the marker would even be better.

    The one feature I would most want to see in the debugger is the the ability to hover over a variable and get the value in a tooltip as Bob mentioned, like Visual Studio and other IDEs. That would cover a multitude of sins. I have no idea how hard it would be to implement, but I would also imagine it would be the least intrusive on the current setup. You don’t have to fit any new variable watch windows into the IDE. Once you have identified the variable, you know its scope, so it ought to be fairly easy to look up the current value, as you can already get to it in the variable viewer (after a finger-numbing number of mouse clicks, true, but still you can get to it), so RS knows what the value is.

  3. I looked into adding the hover feature in the debugger way back in the day. At the time, it was a very difficult thing to accomplish because you had to take a lot of contextual information into account in order to find the correct thing to query. It wasn’t impossible, just not nearly as easy as updating the variable viewer. Who knows though, perhaps things have improved since then.

  4. @Aaron Ballman
    Well, if it was easy it probably would have been done by now. And that’s on a local machine. I can’t even begin what complexities Remote Debugging adds to the mix.

    This was one of my favorite features from VB6. I didn’t like the language much, but I liked the debugger.

  5. Thanks for bringing this up Bob. It’s pretty much my biggest pain point when working with RealStudio. It’s not the most painful, mind you, but more like a chronic cough that distracts me from whatever I’m doing. Dumb analogies aside, I added them to my top cases. Watchpoints is now #9 and Tooltip is now #5.

    I hope the debugger gets some attention after the IDE renovation resources free up.

  6. @Christian Schmitz
    Right, from what little of the new IDE I’ve seen there’s some layout differences (less cluttered?) but it’s still pretty much the same debugger.

    From what I gather, people either like the debugger or hate it. Not much in between. But the one thing that both groups can agree upon is that it can be better.

    And if I could get the hover feature on LOCAL debugging but not on REMOTE debugging I think that would be a reasonable compromise (but of course I’d love to have it both ways). Remote debugging is something that VB6 never had to deal with.

  7. @Merv
    The IDE actually has no clue about the value – it asks the running application for the value.
    It really doesn’t track much about the running application at all.

  8. @npalardy
    I didn’t say the IDE held the value while the program was running, I said the IDE need to get the value. I’m not really interested in where the value comes from, I just want be able to see it a lot more easily than the current implementation.

  9. Christian Schmitz :
    I just moved both cases up one rank
    Also with 2013r1 I think there are a few minor tweaks to the debugger as the IDE around changed.

    If ranking up issues were something RealStudio would take as todo list… I still see case #9515 (Preemptive Multithreaded from 2009) in top 10 list (case 9), and no answer from users requests since march. Or you can get the typical hated response from 64 bit support for schedule (case #3353) made by customer and the infamous “When it’s done”.

    Is it worth customers time and efforts voting and in same cases, begging for what they want to be added in our paid upgrades or should be wait to “When it’s done” when the Marketing team asks you to renew. I know that if most of us answered that way, thinks would change.

    Note that I have taken Christian’s post to make my opinion about the real convenience of submitting feedback requests.

    Bob, I have voted for these 2 cases you mentioned, for a.. “2013 compiler”… Hope RealStudio change his policy about feedback or drop it, and continue doing whatever they want.

  10. @Merv
    The reason I mentioned that the IDE doesn’t store the value is because IF it has to ask a remote process for the value is that it could be slow – esp where the latency between the IDE and the target app is high. Basically it could make mousing over things in the debugger very slow which it waits for the value to be returned.

  11. @Amando Blasco
    I’ll just say that there are things that have to happen in certain orders to get them all done.
    We have to get Cocoa done before we can move to 64 bit – Carbon apps CAN’T be 64 bit.
    There is already a bunch of work being done to make 64 bit possible – but you won’t see much of it until we can compile a 64 bit app.
    Just because it’s on the feedback list & not got any recent responses from us doesn’t mean it’s not being worked on.

  12. @npalardy
    I don’t think we are married to the idea of having to query every time it hovers over each variable, just an easier way to get at the values. Right-click on a variable and have a new addition to the context menu, perhaps. I just want to get at the value of the variables much easier than I can now. Just too much clicking and a good percentage of times I end up down the wrong rabbit hole.

    I know it sounds like we complain a lot, but the debugger is just really hard to work with a lot of times compared to debuggers in many other IDEs we have used.

  13. @Merv
    Click / hover it won’t really matter – on some “action” the value would be queried from the running application via a network connection (it’s actually a similar set up for a local app).
    On a local app being debugged this should be fast but it is possible to remote debug across very slow connections & then it would be horribly annoying as you wait for the request to be responded to.
    A hover / click could take several seconds.

    Then you’d be asking for a preference to turn this capability off 😛

    THat said we are looking into what we can do for the debugger as there are a umber of things we’d like to do as well as the ones you folks have requested.

  14. Well, I just spent 5 minutes looking for a variable of defined structure in the variable viewer, never could find it. We can talk about this all we want, but the bottom line is it is really bad design. I find it much easier to just dim a local variable assign it, and stop on the line of code after it. And that takes programming back about 20 years.

  15. Merv :

    Well, I just spent 5 minutes looking for a variable of defined structure in the variable viewer, never could find it. We can talk about this all we want, but the bottom line is it is really bad design. I find it much easier to just dim a local variable assign it, and stop on the line of code after it. And that takes programming back about 20 years.

    +1,000!

    Creating a local variable is what I end up doing a lot, too, rather than trying to dig through the possible places a global object can live. If I could fix one thing about the debugger it would be this. If I could just easily get the references for all the variables that are used in the current method that would go a long way into making it easier to use.

  16. <blockquote So my question is why do we have to wait for so long to get needed and wanted changes?

    For the same reason we have to wait for everything else. The guys at Real are very talented, but they are too few for such a big project (IDE, Frameworks, Compiler, documentation, all cross-platform). It can only end up in features not present, or, worse, in bad quality. I have the impression they recently go into the direction of more quality, which is very good. For missing features we can at least buy MBS plugins or something like that. This cannot change as long as Real has only 0-1 guy available per topic.
    Now I’m waiting for someone saying “It doesn’t help to throw more people on a problem”. :-))

Comments are closed.