How to solve reference issues when each pc has different version of it
i have a reference to Excel object set to one location / folder However different pc have different office package eg 32 bit or 64 bit all from different folder thus cause error on running application
then you may have a nightmare on your hands due to bitness (32/64).
Opening a file through any application object exposes various objects and methods that are built according to the bitness of the app that built them. However, any App object that a user opens HAS to run on that system using the versions of Office utilities available there. That might not match the bitness of the system that built the targeted object. I.e., if you distribute your front end to various users, it might not run correctly on machines that don't match the bitness of the Office version where you developed the FE file. Having a split environment like that spells all kinds of trouble for compatibility. The problem is that if you have 64-bit Excel, it is there because you installed 64-bit Office - including 64-bit Access.
This forum is full of posts regarding the trials and tribulations of bitness incompatibility. Worth a search.
Having different versions of Office and both bitnesses will certainly cause issues that need resolving. However I don't agree with the following comment:
There are 3 main issues to deal with:
1. Different Office versions - there are two possible solutions:
a) develop and distribute using the lowest version of Office in use by your clients e.g. if your clients use A2010/2013/2016/2019/365 then you need to develop in A2010. This is because references to e.g. Excel 14.0 should successfully 'upgrade' to later versions such as 16.0 but the reverse isn't true
b) use late binding (as already mentioned) and remove reference to version specific items such as Excel
2. Different bitnesses
a) All APIs will need updating
If all users are on A2010 or later (VBA7), you may just need to add PtrSafe and convert Long to LongPtr for pointers and handles such as hWnd
For example:
Code:
Private Declare Function LockWindowUpdate Lib "user32" _
(ByVal hWndLock As Long) As Long
becomes
Code:
Private Declare PtrSafe Function LockWindowUpdate Lib "user32" _
(ByVal hWndLock As LongPtr) As Long
That will work in all versions of Access from 2010 onwards (32-bit & 64-bit)
However if any users have A2007 or earlier you need conditional compilation
Code:
#If VBA7 Then
Private Declare PtrSafe Function LockWindowUpdate Lib "user32" _
(ByVal hWndLock As LongPtr) As Long
#Else 'A2007 or earlier
Private Declare Function LockWindowUpdate Lib "user32" _
(ByVal hWndLock As Long) As Long
#End If
b) ACCDB files work in both bitnesses. However, if you distribute files as ACCDE, you will need two different versions compiled in each bitness
c) A small number of older references do not work in 64-bit e.g. Windows Common Controls. Code dependant on these will need altering
3. ActiveX components
In general, these are best avoided as they may be version dependant & not all work in 64-bit e.g. flexgrid / treeview are 32-bit only
I may have forgotten something but that should cover almost all issues
If you plan & test carefully there is no reason why your application shouldn't work in a variety of setups
