@ThunderFrame I think small caps Bank Gothic works the best. Syncopate does not primarily because the line weight is too different. Montserrat has the right line weight but I prefer smallcaps still.
@this you do know that Bank Gothic is the font used in "24" titles. So Jack Bauer is going to be happy when he next consults his Rubberduck. (btw Bauer definitely beats Norris)
@this There are forks on github. Not sure if any of them have the latest GPL compatible version though. The author took it to a paid model after version 2.2
@Comintern we spend too much time fighting the IDE if you ask me, i figure that if we implement all custom code panes and whatever, we can set whatever events we want, ans it would be pure .net, right?
The stuff that we need to react to is lower level than anything in the VBE object model. The only thing that really requires using SCWs is figuring out what windows belong to what.
Hell, if the VBE.Window wasn't busted we wouldn't even need to do that.
The subclasses are primarily used for 2 thing - we need to raise events to track the focus changes so the hotkeys work, and we're getting a keyboard hook in for AC.
Even if we offered our own implementation of everything, we would still need to know if the VBE decided to focus a code pane in the MDI, because we would need to take an equivalent action in WPF.
@this Meh, it shouldn't care where they are when they're undocked. Throwing it in a window as a child is no different than the desktop being its parent.
The subclassing is pretty rock solid at this point, as are the WinEvents. The only problem areas have been hanging on to SCWs or passing them around in events.
The other nice thing about the subclassing is that it provides a good bridge between the managed and unmanaged world that doesn't go through COM. We bypass all that headache entirely. Need to know when a code module is renamed? Listen for the WM_SETTEXT. Much cleaner that subscribing to the VBE events though the RCW.
Although the developers have strong MS links AFAICT.
The BSD version is stable though.
If I tracked a branch against the sharpdevelop version I could pull their upstream bug fixes too.
@this I'm not sure we care. If we need to respond to the VBE destroying a window, why do we care if the COM server does that before or after the WM_DESTROY?
Native WinEvents and message pumps aren't on the COM interface surface. Anything that we do on that level decreases the contact area between the managed and unmanaged side. We want and need that. Given the choice between holding a COM events object and not holding one, or passing around IWindow wrappers and just listening in on its message pump...
Dont have the code in front of me, but it can mean a COM event may be fired, is cancelled, so no window message, likewise, if there are multiple window message but only one COM event, it would be an example where COM event might be preferred.
Whether that is actually the case, IDK. Just want to consider that.
I do agree taht if they are basically equivalent, we should prefer window message over COM events.
For example, if we use WM_DESTROY to release a component, ww might wnd up causing more AVs or leaks because they are not being released by us when the close event is fired (and ignored by us), resulting in no WM_DESTROY being sent.
Need to check archive but the root issue was that .NET impl was not handling the IOleObject::Close() correctly, causing AVs on shutdown. Thats why timing matters.
Oh, and IIRC, those AVs were occurring long after .NET had shutdown.
@this Agreed, but timing also matters in how the managed side processes the message pump. IIR, it was leaving its subclass in until the DockableWindowHost was disposed and not pulling it soon enough.
I also seem to remember that disposing a managed object in the middle of processing the WM_DESTROY message was bad.
IMPOV, the window messages and COM are almost two different worlds. Yes, COM may have to build upon window messages but it has additional contractual obligations that arent always wnforced with the window messages,
Let's step back and look at the forest again. We've been talking about window management.
e.g. IWindow vs. window message pumps.
In this context, there's a happy overlap so we have the freedom to choose between two because, well it's window (in however sense of the word you want to use), right?
All we care about is the winproc level for what we'd be doing. If we need to get the ICodePane, we ask the COM server for it. About the only thing we need the VBE for is keeping the code in sync before saves or compiles.
@this Except we don't. Because first, the VBE doesn't have events related to the windows, and second, because we can't ask the IWindow what its handle is and get a valid response.
Correct. I'm more concerned about IVBComponent or ICodeModule or ICodePane , which are usually connected to a given IWindow. I'm thinking that if we take any COM object, we have to start pay attention to the COM events whenever a IVBComponent is added/removed/changed because that's a signal to us to drop our references and get new one.
We don't need to any more with Avalon though. What we do need is to know if the Window that we have associated with an IVBComponent is closing and what we're supposed to do with the code in the managed editor.
We shouldn't be using the VBE events in a multi-threaded environment to begin with.
@Comintern No, but it's indirectly listening to the COM events to know when it need to release the COM objects no longer being used.
@Comintern My concern is primarily that if we listen to window message in lieu of COM events, the timing won't be exactly correct, and we end up violating our contractual obligations, in similar fashion to what happen with the DockableWindowHost class before Wayne made it aggregate COM interfaces.
@Comintern No, it doesn't. We agree on that point.
I think the disconnect is in the fact that when we do get the handle to a code pane, we are going to want an actual COM object for that code pane to manipulate the code, right? As soon as we do that, we need to ensure that we are not going to be tinkering with a ghost.
@Comintern but you said earlier that disposing a managed object in middle of WM_DESTROY was bad. What's to stop you from saying that releasing a COM object in middle of a WM_DESTROY isn't equally bad?
I'm not sure the .NET Window implementation was thought through that well. At one point I read all the source code to figure out WTH it wasn't pulling out its subclass and it seemed like it wasn't written with interop in mind at all.
For the record, I absolutely agree on the minimizing the contact. We just have to do this in a way without losing our contractual obligations (e.g. listening to the COM events to ensure that we are not holding what we shouldn't be holding).
That way the VBE could crash completely and all the code would be sitting in a file (possibly with detached file handle), but it would be a backstop against loss of work due to COM glitches.
> This PR introduces an "IsEnabled" autocompletion setting that prevents wiring up NativeVBEEvents when the feature is disabled. It also brings in the changes to self-closing pairs, which is unfortunately still WIP although a big improvement on the current [next] implementation, at least in terms of testability. Although the code for block completions is still in place, the AutoCompleteService effectively ignores them, so the block completion settings are effectively no-op. Clearly this...
leaves AC in a pretty ugly state, so I'm slapping a [WIP] on this PR for now.
Hello people. I took the liberty to fix the OS requirements in the Wiki, as it now requires .NET 4.6, which requires Windows 7 SP1 (Was specified as 4.5 and Vista)
@Comintern As far as I remember, the problem was not that we pulled down the dockable windows too late, but that we pulled them down too early. The windows were not expecting that the managed side of their windows did no longer exist when they got the WM_CLOSE, which is sent after the add-in shutdown.
Btw, thank you VBE for closing windows created by an add-in only after unloading the add-in.
> Early on in the project, Carlos helped us through some show stopping issues around plug-in development. He’s absolutely a subject matter expert here and I’d highly encourage the community to take his advice on this.
> I know a bit of C++ and can be available via email if you need a hand. (Just remember that I don’t know squat about COM shims and might have to set up a Windows VM!)
@Duga technically, it can be run on Vista but it has to be SP2. Also, since our requirement is primarily determined by the .NET framework, I made it first.
@Comintern FWIW, a bit of history in regards to why Wayne set it up that way WRT toolwindows.
@MathieuGuindon I want to ask you - I saw you adding some new stuff to Rubberduck.Common within the Rubberduck.Core project. Do we want to do that, given that Rubberduck.Core should end up being the Rubberduck.UI? Would Rubberduck.Resources be a better home to house shared code?
(sorry to bring that up. I know Resources is .... uh, interesting topic).
Good deal - Probably want to make sure that Detachwon't be called before VBNativeServices goes away on shutdown - it explicitly clears its delegate list now.
@FreeMan Exactly. It's a big code smell if you have more than one junk drawer. We want to try and keep everything sanely organized.... but with "shared" code, it's a big PITA.
At least those could be housed in the Rubberduck.Resources - it's our official junk drawer, I suppose. Stick it in Rubberduck.PInvoke namespace or something.
The only major restriction on the Resources project is that it can't be referencing other Rubberduck.* projects because it is itself referenced by most, if not all of them.
(which IMO, is a good restriction - that should be the only place the truly globally shared freestanding code should go)
seems like whatever I do and wherever I end up, VS 6.0 lurks in the shadows, quietly laughing until one day it steps out and goes "BOOH! REMEMBER ME?!"
When I was writing COBOL shudder, we did have code review by our managers. They did manage to find some things, but they also made mistakes. I drew out the truth table for my boss on his white-board to prove to him I had the AND/OR combos right, and he still made me change it to broken code...
@FreeMan what I don't get is if mistakes made their way in, that'd been a opportunity for those multi-billion firms to upgrade their software and fix the bugs and.... stop using COBOL....
AIUI, the only reason they kept on using COBOL was because it has been working for decades and aint nobody going to touch that!
You have any idea how many millions billions of lines of COBOL exist? It takes time and a lot of money to replace all that "perfectly good" code for no valid reason other than to replace it. Don't forget, us IT types are an expense, not revenue generators.
@FreeMan No, I didn't, actually. Goes to show how little I know. I figured back in 70s, they were probably only hundred of thousands since there had to be so few people and so few computer back then.
Yeah, but new code was being written in COBOL shops at least into the mid- to late-90s. You've got these guys who know the language, it's cheaper to have them code in what they know than to retrain them and/or hire people who know new languages. You can't get rid of them because there's all the legacy code that has to be maintained...
Oh wow. That's a different story. I thought COBOL was dead by time we got in 80s.
But if it's been actively developed up to mid 90s.... well, massive pile of tech debts nobody'll want to pay, I guess. Thus, we get millionaire old bastards.
Pfft! I took a college class in it in '91! First job outta college was coding COBOL in '92. Worked there 3 years, finally escaped, then got sucked in by a customer of the old company that wanted some people who knew the software to help support it at their end. Worked there until '01!
That monstrosity probably still lives on to this day. Running on PCs!
I hate you all! Now you've got me thinking about contacting some former coworkers to see if they're still using COBOL and if they're hiring... It would be soul sucking, but it would sure pay the bills!
> @mansellan @rubberduck203. IIRC, the approach that I used was:
1. Run the [COM Shim Wizard 2.0 for VS 2005](https://msdn.microsoft.com/en-us/library/aa537166.aspx). Note: you don't need VS 2005, it's a wizard that generates VS 2005 projects that you can convert to VS 2017. You need a non high-DPI display, though. At this point, if you register the COM Shim as VBA add-in, you can test the Very High or High macros security settings to ensure that not using code signing is not a problem.
> For interest, this suggests a single C++ project can be used to compile both 32-bit and 64-bit output from a single project. Not sure if that's practical but something worth checking.
VBA Rubberducking
VBA Rubberducking