@Comintern I'm curious, what was the Professional feature you were missing earlier, that would have helped the problem at hand? I thought Community and Professional differences came down to licenses and MSDN access.
Sometimes I wish I could downvote @UserVoice feature requests... The number of votes on this one is deeply worrying. Are that many people stuck in 1980? https://twitter.com/ITImpactInc/status/1017529807490502658
@MathieuGuindon Exactly! Also, when you think about it, even VS' stacktrace include the line number. Unlike VBA, the line numbers don't form a part of the code. The feature request need not mean that it be part of the code. But really easier if they just bought Wayne out.
@Comintern there was an answer on SO last week where the user thought that an Integer used more memory than a Long because it used more characters to type. We assumed he must be paid by the character.
@ThunderFrame No, then he'd be arguing for the other way around. He would have to be paid for using less character, not more. (how does one measure that....)
C - 2,739,341,494,945,868,415,002 (Not including whitespace)
Brute force for the win. Only handles integers, and preserves overflow behavior. Here's a snippet of the code:
int addnumbers(int x, int y)
{
if (x == -2147483648 && y == -2147483648) return 0;
if (x == -2147483648 && y == -21...
@this makes more sense to show line numbers as a title row adjacent to the code. The toolbar is enough IMO, but I can see how having multiple line numbers visible might help in certain situations. Might also be useful to show physical/logical line numbers, depending upon what you're doing. Just keep them out of the code.
@MathieuGuindon One would hope that MSFT would be a bit more smarter than to accept it at face value.
@MathieuGuindon I'll live.
but I saw why - in the feed he's promoting all VBIDE UV items - which isn't surprising since he wants them to invest more. Despite what they say, we're still making solutions with "1980" programming language today.
Our use case is simply tech debt. We have production VBA code with a main working function that is ~1000 lines long (it's a huge loop with about 30 global state variables). It's used by non-technical customers, so we don't put any useful error details in the message boxes. The project is locked, and we open it in its own process so it won't assert a debugger. Line numbers and Erl :shudders: are the only thing that makes it remotely maintainable.
@ITImpactInc If you need a line number to find an error, your function is doing too much. Refactor to the point where you don't need to number lines and you'll also be rewarded with much more maintainable code. Crutches are only useful if you can't walk yet.
@MathieuGuindon Oh, I re-wrote the entire thing in my spare time. It runs about 10 times faster and it's completely OO. Management doesn't want to spend the money to run it through QA until it's broken to the point that they have to.
It was reminiscent of the legacy SmartIndenter code base.
ok that's a tough one. the Call MsgBox( off-by-one crash? VBE is "helpfully" removing the empty parens when the autocompleted line is inserted, so I do module.ReplaceLine(pSelection.StartLine, "Call MsgBox()");, and still end up with Call MsgBox on the line
I mean, that's not the off-by-one (that one's fixed)... but the result is that there's no way to open parens when you use an explicit Call statement
> Another work-around is to avoid `Call` altogether.
In fact, I've got the off-by-one under control, but a quirk of the VBE is literally preventing the insertion of the empty parentheses - they get "helpfully" removed as soon as they're inserted, making the `(` keypress feel like it's simply not working.
Yesterday I stumbled upon a Stack Overflow question that asked if it was possible to implement Tab-triggered auto-completion in a console application.
I thought that was an interesting idea, so I went ahead and wrote a small program that does just that, given a hard-coded string[] - I might even...
Does CodeModule.AddFromString have the same behavior? You could call module.ReplaceLine(pSelection.StartLine, string.Empty); first, then call AddFromString.
Damn. I was thinking of defaulting it to MsgBox(""), but to be a general solution you'd need to know the type of the first parameter (or whether it had one).
@MathieuGuindon once we get declarations from TypeLib, we could have signatures worked out without a full parse. Or, we could just pre-parse the declararations rather than every line, and that would be faster. My preference would be using the TypeLib.
I don't think the client area of the code pane is attached to the message pump at all. The wierd thing is that it asks itself "what character set do I want", and then replies to itself "ansi". And that's it.
> Fixes the off-by-one bug that sends everything up in flames when you type this: Call Anything( So the good news is that it's fixed. The "bad" news... is that when parenthesis autocompletion is enabled, Call statement is special-cased and stripped - because the lovely VBE is being "helpful" and instantly removes empty parentheses in Call Something(), leaving the ( key appear to do exactly nothing. Short of preventing the VBE from "prettifying" the replaced line, stripping the explicit...
Call statement is really the only thing AC could do. See it in action
I think you lose the history that it branched that way, but if you clone and then swap the config with the branch on the filesystem, in theory you should be able to just commit it.
The intermediary commits get lost though. I'm not sure what happens when you merge it back into your "real" next.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4177?src=pr&el=h1) Report > Merging [#4177](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4177?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/abe03b04767868cce2672bff8c9289d0e1bbf2ad?src=pr&el=desc) will **decrease** coverage by `0.02%`. > The diff coverage is `0%`.
Probably not. I'll try and break it after I'm synched.
BTW, I forgot this bit:
//This is an output window firehose, leave this here, but comment it out when done.
//if (idObject != (int)ObjId.Cursor) { Debug.WriteLine("Hwnd: {0:X4} - EventType {1:X4}, idObject {2}, idChild {3}", (int)hwnd, eventType, idObject, idChild); }
It's useful as hell for debugging the message pump.
Huh. I apparently mis-remembered how that was wired up. We only call VBENativeServices.AttachWindow in response to a WinEvent.ObjectCreate. Apparently existing windows were never subclassed.
That wouldn't be deterministic, but the first call on the class is always going to be attaching the event handlers to the VBE, and that's about the perfect time to run the ctor.
@MathieuGuindon damn - had an extra blank line between Option Explicit and @Folder foo so the annotation was above the Sub Foo. Removed the blank line, the annotation was treated as being in the declarations section, and then it worked. I thought you fixed that?
seems the annotation is still only recognized if it's in the declarations section. The parser doesn't scan until the first Sub/Function/Property declaration statement, so comments above the statement can be treated as belonging to the procedure, and not to the declarations section
"Bad news": because the VBE will "helpfully" turn 'Call Foo()' into 'Call Foo', parenthesis completion can't work for a 'Call' statement, so it's special-cased.
Type this: 'call msgbox('
Get this: 'MsgBox|'
Just type the " (no need for space!) to resume (i.e. to get 'MsgBox "|"')
Here's a link to a 9-second video showing the surprising new behavior in question:
https://www.dropbox.com/s/i6hwqapja5aicew/RD%20AC%20-%20CallStmt.mp4?dl=0
I realize this is surprising behavior that's completely not ideal, and I apologize to all the hardcore fans of the explicit 'Call' statement. But if you had to choose between tripling your productivity with AC, or using obsolete 'Call' statements... I mean, right?
@Comintern IIRC, there are 3 places to look. Child docked windows, Child windows that are undocked/MDI children, and windows that are floating (and floating windows can have a hierarchy too)
The dockable windows are parentless IIR, but I'm pretty sure anything in the Windows collection will always be in the VBE main windows child hierarchy.
I'll make sure to play around with both docked and undocked windows.
@TweetingDuck make the RD settings let you choose between: AC disabled for Call, AC enabled for Call, whereby typing Call will have the keyword removed, and a giant fish emerge from the monitor, to slap you in the face.
@Comintern There's a difference between docked and undocked, but if a window is made undockable, it becomes an MDI child. Currently, making an RD ToolWindow undockable makes it so that you can't make it dockable again without either killing the host before it saves, or obliterating your Dock registry key
Right now, on first use, RD just floats the window. There's an issue somewhere for being able to have finer control over which window they're docked to, so we could create various workspaces. One say, optimized for debugging, and another, optimized for inspections.
@Comintern I've worked out the key, but IIUC, the key is only read on startup and written on shutdown. There's no way to have the key read when you want to change the layout, unless you restart the host.
@Comintern FWIW: you can get to the Immediate's VBA project using type lib API. We have yet to try whether that lets you write code to the immediate window or whatever.
Coming to a rubberduck near you soon... live ITypeLib support from the VBE, including reading and writing the conditional compilation arguments plus determine the types of objects (workbook/worksheet/form/report etc), and controls.
I just did git init to initialize my folder as git repo and then added a remote repository using git remote add origin url. Now I want to remove this git remote add origin and add a new repository git remote add origin new-url. How can I do it?
@Comintern, some background material that Wayne has contributed via chat, that has either already been implemented, or should be. I may have missed a few, but SEchat search functionality is not as powerful as it could be. Thought you might find them interesting:
On getting the ITypeLib (despite the message saying ITypeInfo) from the References Object
On getting the ITypeLib (including protected projects) from the Project Explorer
I get the purpose of using Right$() to avoid the implicit type conversions. What was the point of creating Right() with the implicit type conversion, and is there a time when one might actually, intentionally, want to use it?
So in those use cases, you might need to use the variant returning types rather than string-typed alias. At least that's what I thought why we default to using variant-typed functions.
So, if you're writing good, strongly-typed code, you have to think long and hard to contrive an example of when you'd want to use the variant-typed functions. i.e. they're there as a crutch for those who don't write good code because VBA makes it so easy to do so
which created a generation of poor coders who really weren't coders, and really, that created the entire demand for SO, so, I guess, it's good in the long run.
> I think of the company advertising "Thought Processors" or the college pretending that learning BASIC suffices or at least helps, whereas the teaching of BASIC should be rated as a criminal offence: it mutilates the mind beyond recovery.
> It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
> I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself "Dijkstra would not have liked this", well, that would be enough immortality for me.