Improve VBA IDE: Line numbering by default
Line numbering is essential for efficient error trapping. It would be great if the VBA had line numbering by default. To be effective, it should...
(a) automatically renumber when code is edited
(b) be able to be toggled between show/hide
Greg
shared this idea
12 comments
-
Ben Sacheri
commented
Instead of having line numbers embedded in the code and in the way during development, I propose that the undocumented ERL be able to report the line number the same way vbWatchdog does, unless there are explicit line numbers (to be backwards compatible).
In the VBA IDE it would be nice if line numbers were outside of the code, visible in the left margin like in Notepad++, with the option to turn them on or off. It wouldn't matter to me if the line numbering were continuous throughout the module, instead of starting at 1 or 10 in each procedure. Continuous numbering would make it easier to find a reported error line without first having to find the procedure.
A bonus feature in the IDE could be a dialog to "Go To" a line number like the Go To dialog in Excel.
-
Anonymous
commented
Hi, I have excel 2010 it is possible to turn on or add line numbering on my IDE. THANK YOU.
-
Francesco Foti
commented
Line numbers are an important visual aid for editing code, no matter what the language is and the size of the routine. In my VBA projects, how many times have I inserted stop/resume statements in my error trap, just to see which line generated the error ? having an error line number would definitely be useful, although I wouldn't even mind if it's not reflected in an Err object property. There's nothing "old" or wrong with line numbers in a code editor, visually it's just a user preference, so toggling goes naturally with the feature. Every code editor I know of can display them including all the visual studio editions. Bring it to the VBA code editor.
-
Paul Rohorzka
commented
Thanks Mathieu. I could not agree more.
-
UlisesT
commented
I do not know if this would help to keep track of changes in multiprogramming environments
-
Mathieu Guindon
commented
No, no, no, no. Line numbers are NOT useful for error trapping at all, and the undocumented Erl function is broken and only has integer resolution while line numbers can be a long.
Making VBA code default to looking like 1980 can't be the way forward, and makes line labels superfluous which is dumb. Use On Error statements with line labels, and write smaller functions. If you can't tell what threw an error, you've written a procedure that's doing too many things. Refactor your code, don't force line numbers down my throat!
A MUCH better idea would be to give VBA programmatic access to the call stack, so we could have current-century error reporting. See what vbWatchdog does. -
Anonymous
commented
I like it in notepad++ and better for collaboration as easier too point people somewhere.
-
Anonymous
commented
This would be a very helpful debugging feature, especially in applications deployed long ago that suddenly come up with runtime errors.
-
Andy Rice
commented
We need this in the VB editor for error handling!
-
Anonymous
commented
Used line numbers in mainframe FORTRAN code 50 years ago but only because I had to. They're unnecessary or unavailable in COBOL, BAL, PL/I, Pascal, REXX, or VBA and I never missed them.
-
Anders Ebro (TheSmileyCoder)
commented
Totally agree. I use line numbers alot, but right now its part of the deployment procedure to add line numbers, because its so disturbing to see them while developing, but they are critical while getting/logging an error message.
-
Juan Soto, Access MVP
commented
Couldn't agree more Greg! The line number can be used in error messages to quickly identify where the error is being generated.