@this For DWORD WINAPI GetCurrentDirectory what does WINAPI signify? msdn.microsoft.com/en-us/library/windows/desktop/… says "The calling convention for system functions." and it's declared in WinDef.h by #define WINAPI __stdcall.

I'm trying to answer it my self. I found docs.microsoft.com/en-us/cpp/cpp/stdcall but I'm again in territory that's beyond my current comprehension.

@IvenBach That's more than I've done.

Well, I've done it a little bit, but mostly I just use the .NET Framework.

@Hosch250 These things I've wanted to do for so long.

I still find it hard to believe that I'm actually doing them. More than that I'm understanding what it is and why.

@this :+1: I got my RD working with the VBE again.

Now you just need to learn how to write these things in C :P

C# first then C++ then C.

Powershell for me then C# I just feel I could learn framework better this way especially shared by others.

Hence was good to find search-Registry script that fits a good purpose in the long run

Night pond.

@IvenBach Soooooo..... as I am desperate to learn more VBA I was trawling through that Windows API guide link you referenced and ByRef literally means "By Reference." That "reference" is in reality a 32-bit pointer - I guess that holds for 64 bit machines - still 32-bit pointer?

I wish I had done CS. Reading these articles I have too many questions.....

@QHarr No, it varies with the machine/OS. So a pointer on a 64-bit machine will be 64-bit long, and a pointer on a 16-bit machine will be 16-bit long.In old days of VBA5 it was common to use Integer for pointers for 16-bit API but then when VBA6 and 32-bit Windows came, it was updated to use Long for the pointers. But in reality that was not a great idea because a true pointer data type should not be fixed in size. In C-family languages any type* data type already scale up/down...

... and one must use the sizeof() to get the size of things, including the pointer at the runtime. That's why it wasn't until VBA7 (e.g. Office 2010) we got a true pointer data type LongPtr, which converts into Long for 32-bit systems or into LongLong for 64-bit systems.

@IvenBach It's hard because in VBA, we never have to think about the calling conventions, which is pretty low-level. The issue is that without a calling convention, you don't know who owns what and who has to clean up. So if we have a function that takes 2 parameters and returns something... who's going to deallocate the parameters and the return? Should it be the caller? Or the callee? And how do the callee know where to retrieve the parameters?

At that level, the function is nothing more than a pointer to a region of memory with some machine instructions to do something. The instructions only know about the registers and memory addresses (oversimplyfing a bit here). Therefore, you must be able to describe how the parameters will arrive to the function -- by storing it in the stack, and in what order, so that when callee runs the machine instruction it can do the right thing in reading the inputs and creating outputs.

@this Thank you. That is logical. Additional question: why is it on 64 bit I still make Win32 calls? (Or am I mis-remembering #made up word)

because how they transitioned from 16-bit to 32-bit was different than how they transitioned from 32-bit to 64-bit.

ok

in 16/32, we basically moved everything over... for example, from system to system32

and made a separate copy of all DLLs, separate path, blah blah

so for that reason, we refer to system DLLs in the system32 as "Win32".

m'kay

but on 64-bit system, there is no system64

instead, we now have system32 to store 64-bit system DLLs.

ahhh

and we put all original 32-bit system DLLs into SysWOW64

@this not at all confusing ;-)

Why? So that 32-bit apps can run on 64-bit OS.

Ahhh..gotcha. You answered my confusion!

I kinda of missed the 16/32 transition but I think it wasn't as seamless as the 32/64 transition. IIRC, you could only work in one or other mode.

so that's why we still use "win32" even for 64-bit systems.

Thank you very much

In case you don't know already - WOW64 in the SysWOW64 expands to Windows on Windows 64. But yeah, not exactly the bestest name.

I didn't know. Consider me learnt!

[rubberduck-vba/Rubberduck] bclothier created pull request #3948: Remove the restrictions on the admin elevation to merge bclothier/Rubberduck/FixElevationForInstaller into rubberduck-vba/Rubberduck/next

[rubberduck-vba/Rubberduck] bclothier added label PR-Status: Review Requested to pull request #3948: Remove the restrictions on the admin elevation

[rubberduck-vba/Rubberduck] bclothier added label PR-Status: WIP to pull request #3948: Remove the restrictions on the admin elevation

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

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

@Duga worked for me @this, thanks.

@WaynePhillipsEA Thanks for the confirmation! Will see if I can get few more from others.

@M.Doerner what would be the correct way to cause a resolver error state? Throwing exception nor returning resolution failed expression works?

^ "works?" should read "doesn't work?"

[rubberduck-vba/Rubberduck] mansellan added label technical-debt to issue #3949: Wrap VB6 CommandBarEvents

[rubberduck-vba/Rubberduck] mansellan added label vb6-support to issue #3949: Wrap VB6 CommandBarEvents

[rubberduck-vba/Rubberduck] mansellan opened issue #3949: Wrap VB6 CommandBarEvents

[rubberduck-vba/Rubberduck] mansellan edited issue #3949: Wrap VB6 CommandBarEvents

[rubberduck-vba/Rubberduck] mansellan added label vb6-support to issue #3950: Code Explorer needs additional icons for VB6 DeclarationTypes

[rubberduck-vba/Rubberduck] mansellan opened issue #3950: Code Explorer needs additional icons for VB6 DeclarationTypes

[rubberduck-vba/Rubberduck] mansellan added label feature-code-explorer to issue #3950: Code Explorer needs additional icons for VB6 DeclarationTypes

[rubberduck-vba/Rubberduck] mansellan opened issue #3951: Parsing a VBForm results in Unexpected Error

[rubberduck-vba/Rubberduck] mansellan added label parse-tree-preprocessing to issue #3951: Parsing a VBForm results in Unexpected Error

[rubberduck-vba/Rubberduck] mansellan added label vb6-support to issue #3951: Parsing a VBForm results in Unexpected Error

So, I set up a unit test to test the parameter not used inspection. It reported that value parameter wasn't used if I had a Debug.Print value. But if I change to MsgBox(value), then test passes. Is that because we special case Debug.Print or is there something fundamentally wrong here?

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #3893: Improve resolution for ambiguous names WRT scoping

[rubberduck-vba/Rubberduck] [codecov[bot]](github.com/apps/codecov) commented on pull request #3893: Improve resolution for ambiguous names WRT scoping

[rubberduck-vba/Rubberduck] bclothier edited pull request #3893: Improve resolution for ambiguous names WRT scoping

[rubberduck-vba/Rubberduck] bclothier removed label PR-Status: WIP from pull request #3893: Improve resolution for ambiguous names WRT scoping

@Duga I don't get it. I add more unit tests and it decrease coverage? Whatever....

@M.Doerner in regards to my prior question - I think I figured it out - resolving references is done outside the try/catch that will set the module states so I made the part that resolves reference have a similar try/catch. However in doing so, it now violates the assumption made with a Debug.Assert which I commented out ATM. See if that is OK or not.

[rubberduck-vba/Rubberduck] mansellan opened issue #3952: VB6 editor is missing menu and commandbar icons

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

[rubberduck-vba/Rubberduck] [codecov[bot]](github.com/apps/codecov) commented on pull request #3893: Improve resolution for ambiguous names WRT scoping

[rubberduck-vba/Rubberduck] build for commit 725c9361 on unknown branch: 57.69% (target 0%)

[rubberduck-vba/Rubberduck] mansellan added label vb6-support to issue #3952: VB6 editor is missing menu and commandbar icons

[rubberduck-vba/Rubberduck] mansellan opened issue #3953: Get unit tests working in VB6

> See chat.stackexchange.com/transcript/14929?m=44058227#44058227

[rubberduck-vba/Rubberduck] mansellan added label feature-unit-testing to issue #3953: Get unit tests working in VB6

[rubberduck-vba/Rubberduck] mansellan added label vb6-support to issue #3953: Get unit tests working in VB6

@Duga that's all I got for VB6 known issues for now :-)

[rubberduck-vba/Rubberduck] mansellan edited issue #3951: Parsing a VB6 VBForm results in Unexpected Error

@mansellan I'm curious. Can you qualify the built-in functions to VB using VB.<builtin functions> ?

@this Not sure I follow, sorry?

Ok - you know how we have stuff like MsgBox, Left, Right

In VBA, you can do VBA.Msgbox, VBA.Left, or VBA.Right

ah ok

checking

or more explicitly, VBA.Interaction.MsgBox, VBA.Strings.Left ...

I simply don't know if VB6 has the same thing going on.

yep you can - and indeed the OB shows it being exactly that VBA.Interaction.MsgBox

not VB

..... that's kind of weird.

is VB6 really using VBA?

yep. Empty project has refs for:

Visual Basic for Applications

and you can't unreference that?

Can't remove project or reference, in use

(empty .Exe project)

just one more thing to check

check the Reference's full path

something like ?References(1).FullPath (don't know if VB6 has equivalent)

I can see it in the refs dialog - C:\Windows\SysWOW64\msvbvm60.dll

right it makes sense now

Hmm, sounds like VB6, but has types in VBA "namespace"?

compat thing?

I remember noticing both the msvbvm60.dll and vba.dll had same functions

yes, I think so.

though, that's not VB6.OLB.

no...

But that's reffed too

so what does OB call it?

as "Visual Basic objects and procedures"

i meant the programmatic name

as shown in the OB's library dropdown

ah yes, that is "VB"

ok, so I guess for common functions like MsgBox and Left, we still get them from the VBA namespace

i sec will up a scrrenshot

but what are exclusively VB, I guess they must be in a separate namespace, presumably VB.

Soooo.... using that logic - if you can find a function defined in there, and you can fully qualify as VB.<some function>

and if that compiles/run, then that's how we need to provide the name for MemberName/IdentifierName - may have to be a special case since we obviously don't get it for some reason.

says "Image not found"

gah

which image bucket is good for SE?

well, don't bother.

what you can do is paste the image in GH issue

(don't need to actually create issue)

oh ok

once uploaded, you'll get a URL, copy and paste it here.

right, so can you VB.Load then?

i guess the fully qualified name would be VB.Global.LoadPicture

but VB.LoadPicture should also work, too

VB.LoadPicture ""

VB.Global.LoadPicture ""

compiles fine

yeah, so I think the VB6.OLB should have name of VB

yep

either a bug in our type lib collector or it truly isn't there and we may have to special case.

ah ok

i think former is more likely. can't imagine how it would be broken for us and yet work for VB6, since OB can see the name of the library and everything

yeah... IIUC (unlikely) I don't think its the whole reference collection that's broken for VB6.OLB, as it gets quite far into the process. But it chokes on _PictureBox - could there be something funky on that type?

who owns that type?

the underscorce indicates hidden right?

looks like VB6.OLB (VB) does

well yeah but more likely - it's the correct thing

because under the hood, we all work with interfaces

@this yes

PictureBox is most likely the coclass, using _PictureBox as its default interface

checking

hmm ignore what I said about getting far into the process - first type in the lib...

would it help if I checked VB6.OLB into /libs?

GQ, IDK. HAO.

:p

HAO = Have to ask others

lol

got the other two!

was googling that one :-)

pretty sure doesn't exist. I made itup

gtg

@MathieuGuindon is it worth adding the VB6 issues to a new project?

[rubberduck-vba/Rubberduck] mansellan added label vb6-support to issue #298: VB6 IDE support

[rubberduck-vba/Rubberduck] mansellan removed label help wanted from issue #298: VB6 IDE support

[rubberduck-vba/Rubberduck] mansellan removed label up-for-grabs from issue #298: VB6 IDE support

[rubberduck-vba/Rubberduck] mansellan assigned mansellan to issue #298: VB6 IDE support

@M.Doerner I ran a couple of non-trivial VBForms through the parser (temporarily avoiding the other issues raised) - looks like the grammar changes for attributes have worked.

[rubberduck-vba/Rubberduck] mansellan added label user-interface to issue #3952: VB6 editor is missing menu and commandbar icons

@QHarr glad someone else is getting benefit too. I feel like I’m hogging the pond for my personal use way ore than I should.

@IvenBach @this's explanation of pointers and allocations above helped me too. Never done anything lower-level than C#, so whilst I know roughly what's going on nearer the metal, it's great to get expertise from someone experienced.

I'm pretty spoiled by all the type-safety in c#, and the GC

[rubberduck-vba/Rubberduck] bclothier opened issue #3954: ProjectId may fail and throw an exception

[rubberduck-vba/Rubberduck] bclothier added label difficulty-02-ducky to issue #3954: ProjectId may fail and throw an exception

[rubberduck-vba/Rubberduck] bclothier added label bug to issue #3954: ProjectId may fail and throw an exception

[rubberduck-vba/Rubberduck] bclothier closed issue #3922: Rubber Duck 2.2.0 failure to install via local admin account?

[rubberduck-vba/Rubberduck] bclothier commented on issue #3922: Rubber Duck 2.2.0 failure to install via local admin account?

> Since this issue has 2 separate problems, one which is going to be addressed by upcoming PR #3948 and another not related to installer, I'm opening a separate issue and closing this issue.

@this What's a coclass?

@mansellan To me it should be a default assumption that if you're working with something you'll know as much as is reasonable about it.

I just don't like the blind leading the blind...

I found this useful: limbioliong.wordpress.com/2011/10/23/…

Note though that section 6 relates to COM references being made directly in VS (which implicitly calls TlbImp to create an interop assembly). For RD we didn't do this - we used interop assemblies created explicitly, either supplied directly by MS (known as primary interop assemblies due to their being published by the owner of the COM library) or created by using TlbImp directly on the command line (I had to do this for Office8 and VB6, neither of which have PIAs).

I'm reviewing #3937 since it seemed similar enough to the PR I'm doing so thought it worthwhile to check in case it was related. I already verified that my fix in the PR was not sufficient since as noted, it is likely that only user-defined declarations get resolved, not the built-in declarations. That said, I'm having hard time figuring out when ColumnIndex gets visited. Is there a simple way of attaching a breakpoint for a particular token without figuring which point in parsing it is hit?