> In the PR #5182 there was a block for `LOAD_USER_COM_PROJECTS` that got deleted but didn't get refactored. As per #5217 this is now the suspect for crashing.
This PR put it back in its own back. Note that `ref` are used to preserve the current semantics now that it's in its own method. Added a comment as well.
@IvenBach Just getting back. So very sorry to hear about your mom. Very happy to hear that everything was good between the two of you - it would be even harder if things weren't. Prayers for all the family as you deal with the loss.
@Duga Now I'm doubting myself again. Without the localization passed into the ChangeType function, it might actually fail on a non-US install. The string-as-a-date presumes en-US format for simplicity. I think that's why I put in explicit en-US
If anyone has a non-US VBA install, can you do me a favor and test how it handles "04/12/2000", "12/04/2000", "13/04/2000" and "04/13/2000" ?
> May need to bookmark @MDoerner 's explanation - I have a feeling that it's going to be needed a _lot_ as more people start using the duck and hit this. It looks _very_ fully qualified and is going to leave a lot of people very confused.
While `Worksheet.Range(1,1).Value` is (fairly) commonly shown in examples, `Worksheet.Range.Cells(1,1).Value` is probably shown equally as often, so people are going to assume that it's equally valid - after all, it works, doesn't it?
I've done my best to follow along with all the discussions about default member access here and I'm still a bit lost when looking at the explanation on that issue. Would Worksheet.Range(1,1).Value still trigger the inspection?
Let's just say, for the sake of argument, that a guy was not yet using OASIS-SVN for export/import of code from his Access DB, and that git was showing that there were differences in form and report exports from what git has stored in binary format. How would he go about determining what those differences were?
> @mai-am happy to hear this. You'll probably want to poke around in the `AssertClass`. If I understood correctly, the relevant code is [Line 350](https://github.com/rubberduck-vba/Rubberduck/blob/f202cad0b6f19a2a25685bb90ba25b3349d27928/Rubberduck.Main/ComClientLibrary/UnitTesting/AssertClass.cs#L350).
You can find the class in the Rubberduck.Main project under `ComClientLibrary/UnitTesting`. It's there to register the class for COM access. There's other COM-visible unit-testing code in the
> My excuse is it was late on a Sunday evening 🙃. I totally forgot that a call to Cells(i,j) was a call to Items - Should've looked in the Object browser!
Version 2.4.1.5081 OS: Microsoft Windows NT 10.0.18362.0, x64 Host Product: Microsoft Office x86 Host Version: 16.0.11328.20420 Host Executable: EXCEL.EXE
**Description** When a class Get property is marked as the default member annotation ('@DefaultMember), applying any quick-fix results in the `CurrentValue.VB_UserMemId = 0` attribute being added to both the getter and setter. This seems to prevent any additional quick fixes from being applied.
@this [_Default] is actually completely consistent in mapping to Item if an argument is provided. The strange state dependent behaviour comes from Item.
The enumeration behaviour does not only concern For Each loops but also Item.
If the range is a collection of rows or columns, e.g. after using Columns, passing two values to Item will cause a run-time error 1004.
@FreeMan Worksheet.Range has two parameters, which are optional. So wks.Range(1,1) is a simple function call passing two parameters.
@M.Doerner IMPOV, it doesn't feel natural. If they wanted a certain behavior with Item, they could have just made it a function with 2 optional parameters, as opposed to being a property that alters the behavior of the [_Default]
> This is a bug in the member attributes recovery. The problem is that it matches attributes to members by name, which does not work for properties since `Get`, `Let` and `Set` have the same name.
The reason why the recovery is in place in the first place is that the VBE erases all member attributes when we copy in the new module code as part of the Quick fix.
The Worksheet.Columns property only accepts the index (column) number as far as I can see in the documentation.
Nowhere in the documentation does it say the Columns property takes a parameter, and indeed, it would be wrong to mention that, because it doesn't have any:
Like Worksheet.Rows,...
@M.Doerner thank you. I did read that, and I'd even read Mug's answer before, but it'll still take me a while to fully absorb & understand. Especially since I'm in the middle of a minor non-code-related crisis here at work at the moment...
@MathieuGuindon "i am trying to do this in excel-vba; how to do?" provide an answer, but they accept the answer which was downvoted because it was in the wrong language...
that's just following onto the conversation from a week or two ago, where you went through and annotated/commented on each aspect, then they accepted a different answer
> I'm afraid I'm still seeing crashes with 5081. 5061 is running fine. Log for 5081 attached. If you need to see my code I'm happy to provide. [RubberduckLog.txt](https://github.com/rubberduck-vba/Rubberduck/files/3726355/RubberduckLog.txt)
RD supports VBA and VB6. I don't have VB6 but would like to. How to get VB6? There appear to be free download sites, but I am leery of those. Is there a place to get it and be assured of no malware/bloatware included?
@this There are a huge list of them on Ebay, and many with widely differing descriptions (and prices). Any suggestions on what to specifically look for (or avoid)?
The Worksheet.Columns property only accepts the index (column) number as far as I can see in the documentation.
Nowhere in the documentation does it say the Columns property takes a parameter, and indeed, it would be wrong to mention that, because it doesn't have any:
Like Worksheet.Rows,...
VBA Rubberducking
VBA Rubberducking