Intellisense with File Scripting and Shell Objects

[Micron]

but not for those defined as Object.

Not sure if you ever got the answer to that or not. I'd say that when you declare a variable of type Object you are late binding. Access has no idea what kind of object that will be, thus you don't get intellisense. IIRC, you never get intellisense when late binding like that.

As for which library a Property, Object or Method (POM) might belong to, I would not rely on the first in the order of references. As you have discovered, invoking the library (usually by its common name) before the POM is the way to go. Perhaps you have seen this before as in DAO.Recordset vs ADO.Recordset, which is the better form so as to remove disambiguation. Sometimes this is done in the declaration itself, as in Dim fso As New Scripting.FileSystemObject

[isladogs]

@Miles R
Re: FATT - I also originally referred to file attributes when I first developed my app about 7 years ago.
However, the approved terminology appears to be standard file properties (for those common to all Windows files (e.g. name/date created/date modified etc) and extended file properties for those that depend on file type.
In total there are 321 of these properties though no individual file type has more than 50 or so of these properties

If you haven't yet done so, I would recommend you look at my example app. It might save you some time/work

[Miles R]

Thanks for the reply. I have just come to terms with Early and Late binding and am now using Early Binding for all variables that were declared as Object. Now using the correct Class Name after adding the appropriate library.
I only found Shell32.Folder by looking at other code as it was not obvious from the Library Browser in the Visual Basic Editor. Now I see that if I enter Folder in the search box, I get a load of lines that contain the word Folder and Shell32 library is one of them.
Scripting.Folder would be the full name for the other Folder class that I use.

What puzzles me slightly is how the code works if the Library is not included. Prior to changing to Shell32.Folder, the variable was declared as Object and the Library "Microsoft Shell Controls and Automation" was not included. The code still worked, but without Intellisense obviously.

[Minty]

Late binding doesn't require the library to work as you create a non-specific object, then assign something to it. That is why there in no Intellisense - no library associated with it.
Early binding requires the library and therefore it knows the scope and related object references.

Late Binding will work everywhere on other machines.
Early Binding won't if the machine doesn't have the same version of the same library loaded.

For apps that you intend to send to other users, develop using early binding but change to late binding once it is ready to distribute, to avoid issues with references.

[Miles R]

Minty,

Thanks for the reply. I will use Early Binding as all the code is for my use only.
I'm still not getting it though. For the code to work on other machines, they have to have the code. If the library is not included, where does the code come from?
If the code is not in the library what does the library do? Is the library just a reference for what is in the code - which hopefully would have to match otherwise it could go wrong.

[Minty]

There is a much more enlightened explanation here:
https://www.devhut.net/vba-early-bin...-late-binding/

With part two here:
https://www.devhut.net/vba-early-bin...inding-part-2/

Hopefully that will answer all your questions, if not come back and ask.

[Miles R]

Minty,

Ok thanks that makes it a bit clearer. So the code itself must be part of the Access installation itself and not in any library.
I guess for me the only issue will be when I migrate to 64-bit Office 365 on Windows 11, will the library references need updating. I'll worry about that when it happens though.

[Micron]

So the code itself must be part of the Access installation itself and not in any library.

Don't think you quite have it yet. Libraries may or may not be part of an Access install. Could be part of Office install as well. Usually with any given version of Office/Windows/Access every typical install puts the required files in the same place. These file extensions are like .tlb, .ocx, and mostly .dll

As long as those file locations are the same for all users, things should work for the most part because these libraries you speak of are those files. When you create a reference, you are adding references to these files and not the files themselves. If the reference you add points to a file that is in a different location (e.g. you're on W10 and user is on XP) that is likely a big enough difference in Windows versions (thus likely Office as well) so it's unlikely these files exist in the XP user's pc in the same place, if at all.

I said for the most part because the only reason you'd ever have to worry about 64 bit vs 32 bit when it comes to vba is if you use API functions that use pointers that need to be declared as safe. I'm no expert on that subject but that's how I understand it.

[Miles R]

Thanks Micron,

Ok I think I'm getting there. So, in this case the code (specifically getDetailsOf) is part of Shell32.dll. If I add the Library reference, I can use the correct Class name from the library (Shell32.Folder) and Intellisense.
Presumably, if the Library Reference is not included, the runtime has to find getDetailsOf from somewhere. Not sure how it knows to look in Shell32 though - no doubt in the internals of the system somewhere.