VBA Rubberducking

Duga

12:00 AM

RELOAD!

[banane-io/PDB] 4 commits. 137 additions. 190 deletions.

[rubberduck-vba/Rubberduck] 3 opened issues. 1 closed issue. 6 issue comments.

IvenBach

3:46 AM

@this Yet again, thanks for ~~older~~ wiser pontifications about two part naming.

Saved me confusion with Constants.xlLeft not behaving properly. Which is used [VBA.]Constants.xlLeft vs [Excel.]Constants.xlLeft depends on what has higher priority in the references. :+1: for RD. Thanks @pond!

mansellan

11:55 AM

I think the CE Add menu should eventually end up like this:

(VB6 version, icons still need work)

ThunderFrame

@mansellan as does VB6's Add Predeclared Class command. I'm also planning on adding an Add PublicNotCreatable UserForm for VBA. IDK how forms are instanced in VB6?

mansellan

@ThunderFrame hmm... just tried adding a form to an ActiveX EXE - no instancing property visible in the properties window :-(

exported properties are:

Attribute VB_Name = "Form1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False

ThunderFrame

12:32 PM

@mansellan It's the Exposed attribute

mansellan

If I change it in Notepad, then open \ save it in VB6 and it doesn't error, does that mean it's "manually tweakable"?

ThunderFrame

Granted, not as useful as a predeclared class, but a PublicNotCreatable form is still useful in certain situations.

@mansellan that's what you have to do in VBA.

6

A: Add userform to a different workbook at runtime

The problem that you're encountering is that UserForms are Privately instanced by default. That means that a project cannot refer to a UserForm in another project, and if you can't refer to the form, you can't call it's Show method. Your Set myForm = CallerWorkbook.VBProject.VBComponents.Add(vbe...

mansellan

ok lemme try

ThunderFrame

@mansellan tweaking in notepad is about not erroring, and the attribute sticking.

mansellan

ThunderFrame

12:38 PM

Huh, interesting. VBA has a feature that VB6 doesn't.

mansellan

wait... I might have messed up the project type

retrying

this

@mansellan fwiw, might consider add a new vb6 only command to create a new test project. In VS we do tests as a separate project but in VBA that is not always possible.

mansellan

@this I like :-)

I didn't mess up the project type... In an ActiveX EXE, neither Form nor MDI form allow Exposed = true

Class of course has everything, and is UI settable

this

I remeber seeing a table that listed all 6 instancing and told which were available or not for each project type.

May have to consult local VB6 help, Googling didnt find it. Makes me think MSFT finally swept away the remaining VB6 documentations.

mansellan

@this suspect that's aimed at classes though. Need to do some investigation to see what "hidden" options are available for forms.

If indeed there are any...

@this One of the things that MS hasn't got better at... If you're going to demise docs, at least turn them over to the community ffs...

</rant>

The MS journey to open source niceness is... incomplete.

chores, bbl

this

1:02 PM

When you're back, do you still get a AV if you try to load RD with no project open?

mansellan

@this ah sorry should have put that in the comments. Tried all projects and none (dialog cancelled) - all golden.

this

cool

Duga

[rubberduck-vba/Rubberduck] mansellan edited pull request #4284: Quick hack to fix VB6 crash on certain project types

Duga

1:17 PM

[rubberduck-vba/Rubberduck] mansellan created comment on issue #4280: Some VB6 projects cause an RD Access Violation

> Turns out that this is caused by trying to set the caption on the MsForm context menu. If the initial project includes a Form or a User Control, then all is well. If not, the MsForms designer is not loaded at startup, and trying to set the caption on its menu causes an AV.

Quick fix is to simply comment out this menu addition for VB6. Longer term solution is to intercept the form designer loading and attach the menu at the appropriate time.

Strangely, the context menu for form controls i

[rubberduck-vba/Rubberduck] mansellan edited comment on issue #4280: Some VB6 projects cause an RD Access Violation

> Only one commandbar control is involved - the main Rubberduck menu (caption Ru&bberduck). The COM target appears to have lost its pointer at the point where the caption setter is called.

Edit: wrong menu implicated - see below.

mansellan

@Duga ok, chores :-)

Duga

[rubberduck-vba/Rubberduck] mansellan edited comment on issue #4280: Some VB6 projects cause an RD Access Violation

> ~~Only one commandbar control is involved - the main Rubberduck menu (caption Ru&bberduck). The COM target appears to have lost its pointer at the point where the caption setter is called.~~

Edit: wrong menu implicated - see below.

M.Doerner

2:07 PM

We are currently determining the project id for referenced libraries based on the hash of their name and path without any check whether that id already exists. That might lead to a collision with a user project already loaded.

My suggestion would be to simply prepend the project id with something like External in order to make the ids of libraries distinct from those of user projects.

(Currently all project ids are strings containing integers.)

Any thoughts?

this

2:20 PM

Can a user project reference itself?

~~Not sure I see how a collision can happen.~~

Not enough caffeine. You're worried about the hash collision due to have same output. In that case, I think prepending with External. is just fine

Comintern

2:34 PM

@M.Doerner What about assigning GUIDs to user projects?

this

I assumed we were using int for compatibility with GetHashCode

Comintern

@this We can just build the int into the GUID. That makes them comparable with the external ones.

We assign the project id from the GUID of the actual library.

Then for user code, we build the GUID out of the hash.

Time to go pick up a truckload of dirt. TTGPATOD?

M.Doerner

3:37 PM

Hm, I do not really think that using GUIDs on user projects is a good idea.

The problem is that we want to persist them over reloads, which is why we save them on the HelpFile.

However, we can get into the situation that the project id is already taken by another project, which makes us change the id.

I think that would kind of defeat the purpose of a GUID.

We could use the GUID as project id for the referenced projects though.

If we go that way, the serialized projects will need to serialize the projectId as well.

Hm, I think we can get away without that if the reference always has the GUID for library projects.

Now I wonder what the GUID member on a reference to an Excel workbook returns.

mansellan

@Comintern That's exactly what I did for VB6

@M.Doerner I must be missing something - GUIDs should never collide (well, if they did it's time to go buy a lottery ticket!)

M.Doerner

3:53 PM

We sometimes have the situation in the VBE that two versions of the same project load.

mansellan

ah ok

M.Doerner

In that case, the HelPFiles obviously return the same.

It is really annoying.

Currently, we get around a hard collision by reassigning the projectId of whoever came last.

That is not ideal, but at least RD does not go up in flames.

DisplayName

7:36 PM

Hi everybody, any good news on RD-AutoCAD front?

Duga

8:35 PM

[rubberduck-vba/Rubberduck] MDoerner created pull request #4285: Dirty hack to not blow up for hosts with unexpected COM setups to merge MDoerner/Rubberduck/DirtyHackToNotBlowUpForStrangeHostSetups into...

rubberduck-vba/Rubberduck/next

> This PR tries te address #4283.

Tha hacky solution is to castch the `InvalidCastException`, log it and use `null` as target. Currently, we only ever use the application name anyway, which is saved independently of the underlying COM object.

[rubberduck-vba/Rubberduck] MDoerner created comment on issue #4283: Problem with AutoCAD VBA

> I have my doubts that this really is a regression. As mentioned in chat, the error occured when loading RD in a newer AutoCAD version that does no longer support VBA out of the box via a VBA enabler. I bet the VBA enabler does not register with the same GUID the old original AutoCAD host did. In that case, the original GUID is probably not registerd at all and the cast is failing because of this.

[rubberduck-vba/Rubberduck] build for commit acd485f8 on unknown branch: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] [codecov[bot]](github.com/apps/codecov) created comment on pull request #4285: Dirty hack to not blow up for hosts with unexpected COM setups

> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4285?src=pr&el=h1) Report
> Merging [#4285](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4285?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/055d9110421e53908807d8aac9348209f4af3b55?src=pr&el=desc) will **decrease** coverage by `<.01%`.
> The diff coverage is `n/a`.

```diff
@@ Coverage Diff @@
## next #4285 +/- ##
============================

[rubberduck-vba/Rubberduck] build for commit acd485f8 on unknown branch: 52.3% (target 0%)

Duga

9:08 PM

[rubberduck-vba/Rubberduck] mansellan commented on Rubberduck.VBEEditor/SafeComWrappers/Abstract/HostApplicationBase.cs of pull request #4285: Dirty hack to not blow up for hosts with unexpected COM setups

Transcript for