« first day (2686 days earlier)      last day (494 days later) » 

12:00 AM
REFRESH!
[Minesweeper] 35 Games Played. 20 Bombs Used. 4783 Moves Performed. 4 New Users
[rubberduck-vba/Rubberduck] 26 commits. 4 issues closed. 8 issue comments
[rubberduck-vba/Rubberduck] retailcoder pushed commit 8c47d897 to next: closes #5824
Merge pull request #5882 from retailcoder/issue5824

Fixes AssignmentNotUsed false positives
 
 
3 hours later…
3:22 AM
> An addendum to the rules used by the control naming....

If the name leads to ambiguous name in VBA, the name will be rejected. Thus, one cannot simply tranpose some characters in the name because that would result in the same VBA name which is already used. For example, a form cannot have controls with name `Inventory {},~@#$%&*()-_+=|\}"':?/><.!` and `Inventory {},~@#$%&*()-_+=|\}"':?/><..` or `Inventory {},~@#$%&*()-_+=|\}"':?/><!.` (note the last 2 characters). Those 3 examples would hav
 
3:47 AM
> The website is showing the inspection as a "warning", despite it being configured as a "hint". This PR attempts to fix this, also fixes an error in the xmldoc that broke an example, fixes a number of typos and adds a bit more nuance in the VBA code comments.

I've been pondering on the "code quality issues" qualifier for this inspection, and decided to move it to "language opportunities", because having it under "code quality issues" feels a bit too strong for the recommendation it means to
 
4:09 AM
[rubberduck-vba/Rubberduck] build for commit 4f7e2ed6 on unknown branch: AppVeyor build succeeded
 
4:35 AM
> Looking at the issue itself, it seems to break down in the TypeHierarchyPass because we use an expression parser, which does not recognize spaces as a part of the identifier name. As an experiment, I tried bracketing the identifiers with spaces when both adding supertypes via ReferenceResolverRunnerBase and TypeHierarchyPass. However, that did not resolve the expression. It’s possible I’m missing something, though.
 
 
6 hours later…
10:14 AM
[rubberduck-vba/Rubberduck] retailcoder pushed commit 3cd2b0a2 to next: opportunistic typo fix
[rubberduck-vba/Rubberduck] retailcoder pushed commit 4f296b45 to next: fix xmldoc example and inspection type, add more details
[rubberduck-vba/Rubberduck] retailcoder pushed commit 75dd61cc to next: Merge branch 'Issue3970' of github.com/retailcoder/Rubberduck into Issue3970
[rubberduck-vba/Rubberduck] retailcoder pushed commit 4f7e2ed6 to next: another typo
[rubberduck-vba/Rubberduck] web-flow pushed commit e037d010 to next: Merge pull request #5883 from retailcoder/Issue3970
 
 
1 hour later…
 
1 hour later…
1:04 PM
> Looking at the issue itself, it seems to break down in the `TypeHierarchyPass` because we use an expression parser, which does not recognize spaces as a part of the identifier name. As an experiment, I tried bracketing the identifiers with spaces when both adding supertypes via `ReferenceResolverRunnerBase` and `TypeHierarchyPass`. However, that did not resolve the expression. It’s possible I’m missing something, though.

Addendum:

It appears that the hidden interfaces (e.g. `_Form_...`)
 
 
2 hours later…
 
3 hours later…
6:26 PM
Hey quick question: in this comment on an issue in the TB repo: github.com/WaynePhillipsEA/twinbasic/issues/… , bclothier mentions a VBRUN.[_DClass] that all VBA/VB6 classes inherit from. This includes their Dual(IUnknown+IDispatch) implementations as well as stubs for Class_Initialize IIUC and other things. Can anyone explain them in more detail to me/ knows of any documentation (I can't find anything with google)?
A GUID/ list of methods would be v useful!
 
6:57 PM
@Greedo, here's the full IDL definition of the _DClass:
[
  uuid(FCFB3D2B-A0FA-1068-A738-08002B3371B5),
  hidden,
  nonextensible
]
dispinterface _DClass {
    properties:
    methods:
};
IOW, nada. I think it's simply a marker interface, possibly with some custom implementations of the IUnknown and IDispatch.
Also, no, the Initialize and Terminate aren't implemented there. Those princesses are in the IClassModuleEvt interface:
[
  odl,
  uuid(FCFB3D21-A0FA-1068-A738-08002B3371B5),
  hidden
]
interface IClassModuleEvt : IUnknown {
    [helpstring("Occurs when an application creates an instance of a Class."), helpcontext(0x000df918)]
    HRESULT _stdcall Initialize();
    [helpstring("Occurs when an instance of a Class is removed from memory by setting all the variables that refer to the object to Nothing or when the last reference to the object falls out of scope."), helpcontext(0x000df919)]
    HRESULT _stdcall Terminate();
 
7:44 PM
Cool @this thanks! So do you know are there any other hidden interfaces of VBA classes? Just trying to improve my COM knowledge...
Where do those IDL definitions come from, reverse engineering?
 
yeah, you can see them all via the type libraries. You can use the oleview tool (or olewoo, too) to view the metadata
 
Would that be in any compiled VB6 project? Not sure how I could access typelibs in VBA except through IDispatch at runtime - but then I can't pass those to olewoo
 
No, not just VBA/VB6, literally anything that has a type library.
For example, you can have oleview open the type library embedded in EXCEL.EXE or MSACC.OLB
However, I don't think you can directly expose the hidden typelib from a VBA project or standard VB6 project to oleview - it can access VB6's ActiveX project. Probably tB's ActiveX dll, too.
 
@this Yeah that's what I was getting at
Because EXCEL.EXE doesn't define IClassModuleEvt for example
 
Oh, those come from other DLLs.
 
8:00 PM
Basically what I'm asking is whether there is a way to see the IDL info/ set of GUIDs that RandomVBAClass::QueryInterface will support - for example _DClass or IClassModuleEvt. Just so I can understand the COM building blocks of classes I define in the VBA editor, what goes on behind the scenes...
 
the name can vary on different machines but if you look up the Visual Basic runtime objects and projects (6.0) via the Type Libraries folder in the oleview, you can see those interfaces by double-clicking the type library.
because this is a 3rd type library in dll, it's not easy to open directly.
 
8:12 PM
oledump.exe C:\Windows\SysWOW64\msvbvm60.dll\3 did the trick
olewoo wouldn't let me load an indexed typelib
 
yep, but you can via oleview's Type Libraries folder
opening the file with an index doesn't work in oleview, though they say it should have. I wonder if newer Windows OS broke that.
in VBIDE, you can do .References.AddFromFile "C:\Windows\SysWow64\msvbvm60.dll\3" and it will work, too. Just not via the browse button. Go figure.
(again, the path may not be always the same on different computers)
 
8:35 PM
So weirdly in VBA: Dim c As VBRUN.[_DClass]: set c = New Class1 is fine, but Dim c As VBRUN.IClassModuleEvt : set c = New Class1 is a type mismatch
@this thanks for the info btw, invaluable:)
 
@Greedo I don't think that's how it works.
Think of it more like Implements VBRUN.IClassModuleExt
 
If Class1 implements VBRUN.IFoo then I can Dim c as VBRUN.IFoo: Set c = New Class1?
 
no i'm sorry, I said one thing but was thinking another thing
I meant: Private WithEvents Class As IClassModuleEvt
(this is not strictly accurate but gets the idea across)
 
8:52 PM
So C:\Program Files\Common Files\Microsoft Shared\VBA\VBA7.1\VBE7.DLL\3 defines VBInternal which contains
[
  uuid(fcfb3d2a-a0fa-1068-a738-08002b3371b5)
]
coclass Class {
	[default] interface _DClass;
	[default, source] interface IClassModuleEvt;
};
 
Yep
source => WithEvents
 
Oooooh
 
you can't cast to a source interface because you are supposed to implement it yourself (e.g. handle the events in your own code)
 
Yeah, Class exposes events
@this I see. That's weird, I had always imagined events as functions not an interface that must be implemented. So makes sense you can't cast to that interface. I can cast to Class though so I suppose everything in VBA derives from that which is where it inherits the set of events to listen to.
 
if you look around, you'll notice there are lot of event-only (aka source) interfaces which define those as functions
[
  uuid(00024500-0000-0000-C000-000000000046),
  helpcontext(0x00020000)
]
coclass Application {
    [default] interface _Application;
    [default, source] dispinterface AppEvents;
};
and so forth
 
9:07 PM
Thanks for the help:) Need to look at ConnectToConnectionPoint API I think to understand events properly, but I think I'm getting the gist. Interesting to see how the coclasses are composed of event only and standard method interfaces like that though
Makes you wonder why VBA lets us partially implement event listeners but you have to implement every member of an interface. Feels like similar levels of difficulty
 
in the case of Excel.Application, you'd have to Private WithEvents App As Excel.Application, then you get App_NewWorkBook in the VBIDE which is an implementation of the AppEvents interface --- so when Excel application wants to RaiseEvents AppEvents.NewWorkBook, it's conceptually the same as if it had cast your custom class to AppEvents, then invoked the NewWorkBook method on it.
2
 
:o
That's so clear
 
Yeah, TBH, i don't get those weird restrictions VBA has around implementations vs. event handling. I suspect this is largely driven by availability of resources --- they only made event handling work with less hassle (not requiring you to implement everything) but then Friday came and they said "screw it" when it came to supporting the Implements.
 
So Application is basically defining things that listen to it must implement a certain interface so that it can enumerate all its listeners and call the corresponding methods
 
yes
 
9:12 PM
@this haha such is the real world
PS opened an issue for OleWoo to accept tlib IDs in the filepath - I don't have Visual Studio so oleview isn't available by default
 
 
3 hours later…
11:47 PM
[rubberduck-vba/Rubberduck] 1427 stars vs. [decalage2/oletools] 1762 stars
 

« first day (2686 days earlier)      last day (494 days later) »