“So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.” - Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
Yeah, it's annoying AF and has killed way too many innocent users
"Gee, I don't know what happened. I got the files like usual and I opened it up and it looked OK. I don't know why it keeps losing it only sometimes."
I really can't name even a single instance where they could say, "Oh boy I'm so glad Excel chopped off those silly leading zeroes. That really saved my time!"
> Look at these tests: https://github.com/rubberduck-vba/Rubberduck/pull/3695#discussion_r161249278.
We have one "body" and just one place that needs to change--the def type. The name does change, but that doesn't have to, IIUC. We can make that into one data-driven test, reduce a ton of typing, and make it clearer/more obvious what we are actually testing.
> Given the multitude of members that are unique (or relatively common) to each Access control type, and given that we don't want to miss usages like `Vulae`, it seems we have 2 options:
### 1 White-list the distinct list of members of *all* access controls That would ignore the inspection for `ctl.Value` on a `Control`. But that still doesn't solve the problem of the members of third-party controls
### 2 Allow the ignore annotation to specify the type *and* the members that are ignored
> This code accesses the `FormatConditions` property of the `TextBox` control, but because `FormatConditions` is an object, and one of its members *is* accessed, the *Member Not On Interface* inspection is *not* triggered:
```vb Dim accessTextBox As Access.Control Set accessTextBox = Me.Text0 Debug.Print accessTextBox.FormatConditions.Count ```
This code accesses the `FormatConditions` property *without* accessing a subsequent member, and *does* trigger the inspection.
After creating a Grid based on user-input, a Depth-First Search and a Recursive Backtracker is used to carve out a Maze. The User then uses the Arrow Keys to solve the Maze.
Note: The Worksheet_SelectionChange event ensure that the player can only make valid moves.
Note: I paused the video...
@M.Doerner, @this, @Mat'sMug with regards to the unique RCWs exposing some new leaks, I think these can now be ignored.
Having looked deeper, in each case, it was due to direct accesses of the regular RCWs, rather than going through the wrappers. In particular; 1) in the VBProjects/VBComponents constructor, 2) Window stored in the _dockableHosts dictionary
I was under the impression all uses of the RCWs go through the wrappers, but they don't, and so by changing only the wrappers over to use the unique RCWs, the regular RCWs being accessed directly start leaking.
^ due to the regular RCWs no longer having ReleaseComObject called on them, as they no longer have a wrapper associated with them
BTW, IF you were to go with unique RCWs, you also need to remove the 'rewrapping' flag used in the wrappers for supporting the casting of CommandBarControl to CommandBarPopup etc. The reason for this is that when you cast to the alternative interface, this converts to a regular RCW, which now needs to be wrapped as a unique RCW and disposed of properly. That would actually simplify the safe com wrapper a little.
@this... sorry but the IConnectionPoint* thing was a red herring. It was the command bar leak due to the subtle difference noted above that was also leaking the IConnectionPointContainer pointer. By removing the rewrapping, that fixed the IConnectionPointContainer leak as well, so the CLR appears to release it appropriately when the main RCW is released, and so there's actually nothing to fix ;) sorry if you already started
@WaynePhillipsEA Well, it still have to be fixed IMPOV because it's implemented as static which I think is very strange way to set up events. We have another issue where we are missing events because of that. That said, I was able to modify the VBProjects to receive events using the ICPC/ICP as an instance method. Whether it's leaky, I can't tell yet though I still get a clean exit.
Just to confirm - to obtain the ICPC, I cast the COM object. However I should not release the ICPC, right? I did that and got "RCW has separated" error. I do release ICP as part of disposing, however.
stupid question.... in vs2017 with git extension I've cloned, created a branch, made changes. how do I get it to compile? vs just keeps saying 'Item(s) saved'
@M.Doerner on the VBENativeServices.cs we have a procedure UnhookEvents -- those calls static DetachEvents for both VBProjects and VBComponents. They are now instance. Will commenting them out suffice or do we need to add a field to hold the instance for the class?
His notes indicate that he made those changes to be thread-safe. However, simply making them static doesn't mean it's thread-safe. He later push another PR to "stop massive leaks": github.com/rubberduck-vba/Rubberduck/pull/2687
> This restores the implementation of events as an instance member of their containing class rather than as a static methods. This may potentially fix the issues where we miss some VBComponents events because only the first registration are considered. Note that this is somehow a reversion to an earlier pull request - see @comintern PRs here: PR to make it thread-safe...
PR to plug memory leaks That said, there are still few differences -- 1) We build upon the SafeComWrapper, creating SafeEventedComWrapper which controls the disposal. 2) We implement the source interface directly, rather than using a separate sink, which simplify the instance management as there's now an one-one relationship between the source and the events. This is being put up for review by others before I proceed further on...
other and to help us decide if it's still warranted.
@M.Doerner, @Mat'sMug, @this... I'm giving up on the unique RCWs at the moment. Whilst it works easily without any leaks for the most part, there are loads of edge cases/side effects that are very difficult to track down the root cause. They can all be fixed, but I'm finding myself having to make minor changes throughout the whole codebase, including things like QMNs.
I am out of my comfort zone as I just don't know your codebase well enough... yet. I may well return to it in future.
But by then, you'll probably have a shim in place, and so won't need it anyway
There is something I am not sure I understand. How could VBE library implement CommandBarControlEvents which has a Click event that can return a IDispatch representing the CommandBarControl, which we cast to Office's implementation of CommandBarControl. But if the host isn't an Office program, then what is it?
Furthermore, the declaration do not match.
This is how Microsoft Office's CommandBarControl implements its Click event:
Anyone else in the PMADN Access group in linkedin? There's a post mentioning mz tools and RD. And RD is getting a bit of a battering due to the crashing
@WaynePhillipsEA VBE has no interfaces whatsoever for the CommandBarControl itself - that is defined inside MSO.dll. What I don't understand is that depending on which you ask, you get 2 parameters, one in/out, or you get 3 parameters, all in.
I thought the interfaces had to be uniform in how they define the method with same DispID
@this there was a change to CommandBarControl, where click event and mask properties were added, around Office 2000/2002. We had to deal with that for CorelDRAW, which used the old Office typelib
I wouldn't have bat an eyebrow if the Click had handled as the 3rd parameter since by then, the definition is sufficiently similar to allow casting at runtime.
The VBA and VB6 Add-In Object Models (VBIDE) expose a CommandBarEvents object that have a Click event, and the event signature is:
Dim WithEvents CmdBarEvents As CommandBarEvents
Private Sub CmdBarEvents_Click(ByVal CommandBarControl As Object, handled As Boolean, CancelDefault As Boolea...
Perfect, that explains the why, thanks @ThunderFrame. Not quite the how, though because I genuinely thought that if you assume a dispatched method to be same between two different interfaces, you better have the signature similar enough or you get problems.
It's late bound, so it could just try 3 args and then fall back to 2 on error, our vice versa Not likely though. More likely just two different interfaces. They don't have to be compatible.
IIRC, Chip Pearson's site has an article on attaching events for the VBE, but the article is so old, it relies on the VBE CommandBarEvents approach, so is out of date, and won't work on 64-bit.
@WaynePhillipsEA they're different, of course. See, my confusion was that because VBE did not define the CommandBarControl, I assumed they were borrowing from the Office library though I did not see any references.
It did not help also that in Office there is no CommandBarControl -- there are CommandBarButton and some other stuff.
so earlier I thought they were all somehow sharing the source interfaces but I don't think that's the case anymore now that I have historical background (thanks, @ThunderFrame!)
"hacked" is putting it mildly. :)
one wonder if it was a project done by an disgruntled intern 20 years ago....
After creating a Grid based on user-input, a Depth-First Search and a Recursive Backtracker is used to carve out a Maze. The User then uses the Arrow Keys to solve the Maze.
Note: The Worksheet_SelectionChange event ensure that the player can only make valid moves.
Note: I paused the video...
The VBA and VB6 Add-In Object Models (VBIDE) expose a CommandBarEvents object that have a Click event, and the event signature is:
Dim WithEvents CmdBarEvents As CommandBarEvents
Private Sub CmdBarEvents_Click(ByVal CommandBarControl As Object, handled As Boolean, CancelDefault As Boolea...
VBA Rubberducking
VBA Rubberducking