Duplicated items in Intellisense

[KitaYama]

I've recently noticed some items have been duplicated in Intellisense.

I narrowed down the problem and found out it's because of the following two references.
Microsoft Scripting Runtime
Windows Script Host Object Model

Deleting any of them solves the problem.

Because of the nature of our job, I need to extremely work on external text files, that's why Microsoft Scripting Runtime is added.
In some cases for changing windows default printer, the database is using WshNetwork and Windows Script Host object is added (there are some other cases that need this reference)

Does having duplicated items in intellisense cause any harm on the over all functioning/performance of the database?
Will I face any other problem in long run?
Will it be OK if I leave them both?

Any insight or advice on this is much appreciated.

This is the list of references I have.

 

[arnelgp]

you can append the correct Library when you declare and instantiate an object, like for Scripting Runtime:

Dim fso As Scripting.FileSystemObject
Set fso = New Scripting.FileSystemObject

the Library is identified by a "book" icon (on intellisence, with the rightmost, yellow book slanting).

 

[The_Doc_Man]

Does having duplicated items in intellisense cause any harm on the over all functioning/performance of the database?

There are times when it is possible to have problems, but they tend to be rare. I believe that FSO is the same in both of your sources. For a counter-example, we used to have issues with .Recordset if both DAO and ADO (or ADODB) references were present. In such cases, .Recordset was different between the two and would cause no end of havoc. Now that Access Web is no longer a particular "thing" to worry about, ADO references are fewer in number - but not vanished, since ADO has other uses.

 

[isladogs]

Are you sure you need both references?
For example, you mentioned using Windows Script Host Object Model to set the default printer
I've not used that reference for many years & I know you can do that in other ways
e.g. try adapting this code from Application.Printer property (Access) | Microsoft Learn

Dim prtDefault As Printer
 
Set Application.Printer = Application.Printers(0)
 
Set prtDefault = Application.Printer
 
With prtDefault
 MsgBox "Device name: " & .DeviceName & vbCr _
 & "Driver name: " & .DriverName & vbCr _
 & "Port: " & .Port
End With

Or use this:

Function ChangeDefaultPrinter()

    Dim ptr As printer
    'Get current default printer
    Set ptr = Application.printer
    
    'modify it to a specified printer
    Set Application.printer = Application.Printers("YourPrinterNameHere")
    
    'code here to print whatever you need to do ...
    
    'optional - restore default printer
    Set Application.printer = ptr

End Function

 

[MarkK]

Deleting any of them solves the problem.

This is a feature, not a bug. There can be a same-named class in multiple referenced object libraries, but it's just that the intellisense dropdown doesn't show the project name. I commonly reference both DAO and ADODB in a project, and both those libraries expose a Recordset class, so there are two of them in the dropdown.

An ADODB.Recordset and a DAO.Recordset appear in the dropdown.

So I disambiguate in code by specifying the library name...

Dim rst As DAO.Recordset

 

[KitaYama]

Are you sure you need both references?

Yes

For example,……….

I’m already using what you explained in some cases.
The method you explained changes the printer that reports use to print to. But doesn’t change Windows default printer. As I said earlier, I need to change Windows default Printer, not the printer Access uses.
Your method fails in the following situations.

1. You need to print pdf, excel, text or drawing files from a specific printer. Application.Printer controls the printers that Access uses. Sending the print of an external file to a specific printer fails.
2. You have the search result in a form and based on this result you need to print report1 from printer1, report2 from printer2 and report3 from printer3. VBA runs very fast, but printer needs a little while to accept the job and print it. You send your job to printer1, change application printer and send your second job, but because the print job is not physically finished, changing application printer has no effect and your second job will be sent to printer1. We’ve had this problem for years.
3. You can not change Application.Printer to a printer that is located in Active Directory connected via VPN.

Today’s Sunday and I don’t have access to my pc. I’ll try all given suggestions first thing on Monday when I’m back to my desk.
I really appreciate all who shared their experience.

 

[KitaYama]

This is a feature, not a bug.

I didn’t meant it’s a bug. I was trying to see if they may be problematic or not.
I’ll add the library name.

Million thanks.

 

[isladogs]

The method you explained changes the printer that reports use to print to. But doesn’t change Windows default printer.

Agreed

 

[Pat Hartman]

@isladogs , this is probably a bug. If you define an object as FSO, you should NOT be seeing properties/methods from different libraries.
Can you bring this to the attention of the Access team and ask them to qualify the references so we can tell which library they come from if they don't think the duplicates are a bug? It may not matter if they are careful to use the same numeric value for the reference but in that case, it might be better to remove the duplication to avoid confusion.

 

[isladogs]

From the OP's description, I'm not sure this can be seen as a bug.

There are many cases of similar code being in two (or possibly more) reference libraries
DAO & ADODB recordsets have already been mentioned and we are all used to disambiguating those

In some cases such as the old DAO libraries & the newer Microsoft Office xx.0 Access Database Engine library, having both would cause a conflict and so this isn't allowed.

Clearly in this case, the two Scipting references do not conflict or both libraries wouldn't be allowed at the same time.
The OP says he is going to disambiguate in his code, as I do. I normally use:

Set objFSO = CreateObject("Scripting.FileSystemObject")

However, it sounds like doing that isn't even necessary in the case of FSO.

Its safe to say that they won't remove FSO from either library as doing so would break large numbers of apps that have worked for many years