Closed ghost closed 5 years ago
?
as a shortcut to Print
worked in BASIC 2.0 on my old Commodore 64! 😀 ...and then there's the whole "but where is this Debug
object coming from anyway?" thing (looks like it's special-cased at the language/parser level), but I digress... I think it wouldn't be unreasonable to have an "autocorrect" feature that turns ?
into Debug.Print
as you type it, when that's the only thing in the current line of code being edited: similar "autocorrect" ideas are very much in-scope for the project.
Do you know about the VBE's Locals toolwindow? IMO combined with judiciously placed breakpoints, it's a much more appropriate tool for debugging and inspecting local variables' values, at least in most cases I can think of.
That said Rubberduck's "smart concat" and "self-closing pairs" completion would probably make it a little easier to type statements like these, by automating the closing of double quotes, the line continuations, and the & vbNewLine
concatenations.
Other than that, given the Locals toolwindow, I'm not convinced further enabling debug-outputting is something we should be looking into.
That said, we absolutely welcome pull requests that address open issues!
@MarkFern BTW sorry for basically derailing your docs PR the other day... and thanks for your contributions to the VBA landscape!
I'll probably try it out one day.
Awesome! Let us know when you do, and don't hesitate to ask anything!
@retailcoder, don't worry about your PR comments the other day. Actually, @Linda-Editor and I are planning on changing the text again to 'grammatical element'. If you hadn't added your input regarding the definition of 'token', I likely wouldn't have thought of this. Might even in the end write 'token' in some way to improve the content.
I've only very recently learnt about the existence of the locals window. It looks interesting & I'll probably try using it. I've used the watch window quite a bit which I think might be similar. Two disadvantages I find with the watch window is that it doesn't show a value history, & when the immediate window is displayed next to it, it seems to be often too compact for me. Also, you can't add a commentary to the values which I find I can do with Debug.Print
statements. For example, I can write the following that adds commentary to the outputting of expressions:
Debug.Print "Object has been created. Token has been received."
Debug.Print "MyFlag = " & MyFlag
However, I understand that perhaps using the locals window & the watch window, in conjunction with judicious use of breakpoints, could be sufficient. Perhaps I just need to improve the ways I check for code correction & debug code.
Glad to see that my earlier comment has resulted in a new feature request.
Thanks.
Hello.
Me & Rubberduck
I've just been browsing your pages on Rubberduck and it looks like a very useful tool. I'll probably try it out one day.
What I would like to do
I've just been thinking today that it would be good if I could more easily code statements like the following in the VBE:
Sometimes, instead of
Debug.Print
, I useMsgBox
.I find myself running such statements quite often for debugging & code-checking purposes. They're not so easy to read even though they all follow very standard forms.
Ideas for how to do it.
I've been trying to figure out how I can write such statements using a simpler form. I've figured out a way to do it using source-code rewriting but I'm not so keen on it as if others were to use it, they would have to trust that the rewriting code wouldn't do anything nasty to their source code. Also, the rewritten code still has a relatively 'ugly' form similar to that shown above.
Interfere with compiled p-code?
I then thought it probably would be best if I could interfere with the p-code generated through compilation whilst at the same time leaving the actual source code unchanged, but I have no idea where to start with this.
VBE's
? <varname>
syntaxI notice that if you write
? MyVar
in the code pane of VBE, it oddly rewrites the code asPrint MyVar
which the compiler or runtime won't accept. I'm wondering whether the VBE developers meant for the code to rewrite toDebug.Print
instead.Anyway, if I could implement such an automated rewrite that happened straight-away after the line was entered, I think this would be an acceptable solution.
Is Rubberduck relevant?
Are any of these things, things that Rubberduck could be geared up to handle? I had a look through past Rubberduck GitHub issues to see whether there were any existing issues related to this issue, but couldn't find anything. If Rubberduck isn't geared up to handle such things could you tell me if I coded something up to do what I'm suggesting, would I be able to submit such code to the Rubberduck project such that it might be beneficially used in Rubberduck some time in the future?
Thanks.