We're going to take a little break from the current series (don't worry -- we'll get to the last post in the series tomorrow, I promise). You may be interested in what sort of evil things I've been up to lately.
Tons of evil things. :: grins ::
My job for this release is to work on the debugger, and I've been really enjoying my job lately. I've been looking at areas where the debugger can do a better job of helping the programmer to find bugs. This involves things like displaying more information to the user, viewing information in different formats, and other goodies.
Before I go any further, I want to explain that this is all pre-alpha stuff and things change. Under no circumstances can you ever say "but Aaron said it would be there and work like this" because that's simply untrue. I'm playing with various UIs, and you are getting a sneak peek at how things look before we've even put out an alpha with them. So be warned -- if any of you mess this up, I'm taking my ball and going home (read: that'll be the last time I ever give sneak peeks).
Ok, now that you are sufficiently scared to even look at these ideas... ;-)
One of the first things I started working on was the ability to modify values within the debugger's variables viewer. The basic idea is that sometimes you want to keep debugging, but you want to modify a value because you want to see the effects it has on your application. Interestingly enough, this has some a rather complex problems. In theory, you should just be able to click into a listbox cell and start editing. But in actuality, it's not so easy. For instance, a listbox's editable cell is a single-line field. So what happens when you attempt to edit a multiline string? Well, if we just did the naive approach, then you would be able to edit the first line of the string -- and everything after that line is gone. Oops! Not such a good idea, eh? There are a few other situations like this which require some special care. (FWIW, the initial alpha may actually have the data loss bug in it because I checked in a first-pass implementation just as a proof of concept.)
Speaking of strings, they're getting some major attention this release. They're such a common and versatile item in most applications that the extra love should translate into much better debugging productivity for the user. For starters, the data that you view in a string isn't always textual in nature. For instance, if you work with serial or networking, you frequently are working with binary data that's been shoved off into a string. So one new addition to the extended string viewer is the ability to view the string's binary contents. This way you can see any non-printable text. But that's not all -- there are other times when you *swear* the binary data is right, but for whatever reason, the data simply isn't being displayed properly. That's usually an encoding issue, which is why the extended viewer now allows you to view a string with various encodings. The final string goodie is more of a performance optimization than anything (and isn't complete yet, I might add -- it's what I'm working on right now). When you step over code and there's a string being displayed in the viewer, the entire contents of the string is transferred every time. For small strings this isn't a problem. But if you have the entire contents of Moby Dick in a string variable, this can be a very laborious process which makes debugging seem slow. So the idea is that the StringCellManager will only ask for a preview of the string (the first 50 characters or something), and the extended string viewer will show you the entire string. Since the listbox can only show you a small amount of data, the overall experience should be sped up without affecting the data being displayed to you.
Ok, so string viewing is pretty cool (if I do say so myself). But what's really cool? Being able to view the contents of a RecordSet. Wouldn't that be pretty neat? Hmm... ;-)
So, as you can see, I've been a busy boy. And we haven't even put out the first alpha yet! And remember, these features can be yanked/changed at any time, so don't go assuming this is some sort of finalized set-in-stone feature set. I just wanted to share my excitement with you.
I usefull feature of a debugger would be the ability to create and insert a ad-hoc expressions or statements into the debugging window allowing further inspection or testing of values in the debugging window.
Yes -- I'm well aware of several dozen useful debugger features (some of which are in the feedback system, like yours, and others of which are not).
Especially the recordsetviewer is a wonderful idea. I can't wait to see it.
Very nice... and that one for the recordset is also very good!
BTW, what are those minus boxes before the Case and If statements on the recordset image? If those are expandable/collapse boxes for blocks of code, I also like them ;-)
That may very well be some UI for code folding... ;-)
Looks very interesting and I can't wait to try it out.
Would it be possible to have a 'watch window' in which you can select and display only the variables you are interested it?
@Ben -- anything's possible. :-) But you should file a feature request for that sort of thing.
PS. Being able to see non-printable characters in serial strings will be extremely useful for me as I do a lot with data being sent from microcontrollers.
As long as you are looking at strings and debugging, I'd just like to check and see if an old 5.5 bug got fixed. When debugging and viewing a long string in the little popup box, it seemingly convert CRLF's into either just a CR or just an LF, so that when you go back to stepping through, anything that required a CRLF failed, because RB didn't think they where CRLF's anymore. This (hopefully) was fixed a long time ago, but....
I do rather like the recordset view thing. Will be useful in many places.
Wow that's really neat. The RecordSet view is most excellent. I'll hold you at your word that it's going to be in the next release ;)
@jdiwnab -- That's an excellent question. It's entirely possible that issue may still be happening since the string viewer is an editfield. That's something I'll have to keep a careful eye on while working on this.
Cool stuff, especially with the recordsets. That'll sure come in handy.
Aaron, that is some exciting stuff you're working on.
You and the rest of the RS team are doing some great work.
It seems like only yesterday we could only have one project open at a time...
@jdiwnab -- ok, so I've been giving this some more thought, and I've come to a different opinion. An EditField is not a bit bucket in any way (this is the reason the hex canvas is so desperately needed). There are no promises that the data you put in to it can be displayed, or retrieved without data loss. Basically, the EditField.Text property isn't meant for round trips.
Because of this, I don't think special care is needed with regards to any data. If I put in a string with several null bytes into an EditField, and then I modify the contents of the EditField and commit, I should get the contents of the EditField. This includes line endings.
Generally speaking, this should not be problematic since most of the time you are editing multiline strings, I'd guess they're in a platform-native format.
Not to say this couldn't cause problems -- but it does seem like more of an educational issue, since the general problem can never be solved, than an engineering problem.
Aaron, you rock! You've been filling my inbox with a bunch of "fixed" feature requests. These are items which I've been waiting for, for a long time.
Whether you allow editing or not, it seems as though, as of 5.5 (I know, out of date), that if I had, say, "Hello"+chr(13)+chr(10)+"World", the single line in the debugger would show "Hello[][]World". I would then click on the button to see more, and it would show it on 2 lines, but when I go back, the single line shows just "Hello[]World", showing that one of the characters got dropped. If I then used something like NthField(s,chr(13)+chr(10),1), I wouldn't get the right result, as I no longer had a CRLF according to the debugger. Now, if I didn't view the contents in the bigger window, it would work fine, as the CRLF is still there in it's entirety. How viewing the variable in the debugger, in 5.5, no less, would change the data, I don't know. Maybe RB was (is?) making an internal conversion, and committing the corrupted data back.
This might not even be a problem anymore. But just make sure the line endings are the same as they should be.
You know what would be cool? If the "collapse section" icon only appeared on mouse-over. That would make the IDE much less visually cluttered. (I'm picturing a cool fade-in effect.)
But I'm glad to have it, no matter what!
@Adam -- unfortunately, those don't work so hot because there's no reason to ever assume they'd show up in the first place (requires foreknowledge of the feature). There are other tricks that can be done though.
@jdiwnab -- You're making the assumption that the EditField itself isn't what's corrupting the data. It's been a long time since I've even seen the 5.5 source base, but IIRC, string editing was committed when you closed the viewer. So that means "viewing" it in a multiline editor was the same thing as "editing" it in the multiline editor. If the multiline EditField was changing the EOLs, then they'd be stripped automatically. This is no different than viewing/editing a string with null bytes in it. In 5.5, that string would be modified as well.
We're playing around with several UIs for things currently, but in 200x, viewing shouldn't automatically edit (I think) because of this reason. You should have to be explicit about your commit. However, the chance for data loss is still there. It's implicit by the use of the EditField. Without a hex *editing* canvas, there's no way around it.
Whoa! I have been using this thing for years, and never realized I could actually edit strings there! *hits self on head* I should know better. ;P
Huttah, I think I came up with an intuitive solution to the string editing issue. Spent a long while drawing it out on paper and passing it around (also discussing it with others). Having played with what's implemented, I'm quite pleased. All of my previous implementations lacked because they either had fundamental problems with the UI (easy to cause data loss, etc), or they left me wondering "what do I have to do?"
I don't think a1 will have it in there, but a2 should. Now I just have to solve a few more problems, and pretty soon most everything will be modifiable.
Will we be able to specify custom collapse sections (not necessarely in a logical code if/loop/whatever block)? :-)
@Math -- It's not my feature, but I'd find it to be highly unlikely.
Thanks for your reply Aaron. I guess it will call for a feature request when the first alpha is released! ;-)