UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
3 Pages V  1 2 3 >  (Go to first unread post)
   Reply to this topicStart new topic
> Any Ms-access 64bit Users Willing To Test A Dll, Access 2007    
 
   
bowlesj
post Sep 12 2017, 09:07 PM
Post#1



Posts: 247
Joined: 20-May 08



Hi,

I was wondering if there are any MS-Access 64bit users on the forum who might be interested in testing a 64bit version of a DLL for me. It's a DLL you can keep of course. It allows you to pass data back and forth between MS-Access programs basically instantly (3,000/10,000 data items each of data formats Boolean, Single/float, Double/float, long integers and strings). The test involves downloading the DLL, putting it in the C:\ directory, loading the MS-Access database into your 64bit MS-Access and clicking 5 buttons which give a popup saying the test was a success or failed and that is it (a very simple database). I ask because I presently only have MS-Access is 2007 which is 32 bit and I have a need to upgrade to MS-Access 64 bit but only if this 64 bit DLL works with the 64 bit MS-Access. If someone gets back to me with positive results on the 64bit DLL I will go ahead and buy the 64 Bit MS-Access (maybe 64 bit 2016 office).

I attached the 32bit version of the DLL for any who may be interested (it definitely works with the 32bit MS-Access).

Thanks,
John
Attached File(s)
Attached File  Access_GV_Tests.zip ( 77.69K )Number of downloads: 8
Attached File  GlobalVariable_64bit.zip ( 142.74K )Number of downloads: 5
Attached File  GlobalVariable_32bit.zip ( 85.57K )Number of downloads: 4
 
Go to the top of the page
 
River59
post Sep 13 2017, 07:43 AM
Post#2



Posts: 1,344
Joined: 7-April 10
From: Detroit, MI


I am running 2016 on 64-bit machine. I am not able to create and save the dll in the 'C:\Access\GlobalVariables\' directory on this computer so I had to save it where I could ... C:\Users\xzbqxh\

I just tested this for you. The 32 bit works fine but when I test the 64 bit I get the 'File Not Found' error. This may be because of where I had to store the dll.

Sorry. Let me know if I can do anything else to help.

--------------------
Remember ... Armstrong, Aldrin and Collins flew to the moon and back with a computer system less complex than a modern, programmable toaster ...
Go to the top of the page
 
bowlesj
post Sep 13 2017, 08:48 AM
Post#3



Posts: 247
Joined: 20-May 08



Hi River59. Thanks for your help. I have attached the instructions for the dll in this message just in case you want to use it. I am guessing it actually does work so here is more info. Based upon what you said I am wondering if you are running a 32 bit MS-Access on a 64 bit machine. Maybe you can clarify my confusion. Here is more info that may resolve the issue.

Background info:
I have 64 bit windows-7 and I am running 32 bit MS-Access 2007 on the 64 bit windows-7. I was also running the 32 bit multicharts on my 64 bit windows machine but I had to upgrade the MultiCharts to 64 bit due to serious memory problems. So both 32 bit and 64 bit programs will run on the 64 bit windows and it would be the same with the 32bit and 64 bit ms-access. The MultiCharts people supply the DLL free as part of their program so charts can communicate with each other and it just so happens that MS-Access 32bit could also communicate with the Multicharts using the 32 bit dll. The Multicharts people converted the 32 bit dll to 64 bit as part of their 64 bit version and the 32 bit ms-access can not use the 64 bit dll. I am pretty sure excel and MS-Access can communicate using these GVs as well as Excel and MultiCharts. I use timers in MS-Access to almost instantly react to changes in the market as indicated by MultiCharts. I control how MultiCharts works using commands from MS-Access.

How to redirect the code to your "C:\Users\xzbqxh\" directory:
There are two modules in the database. One for 32 bit and one for 64 bit. In MS-Access 2007 you can get to these modules by pressing F11 (not sure how you do this in the 2016 version).
If you look at the code in the 64 bit module called "Mod_GlobalVariableWrappers64bit" you will see the DLL module pointers or whatever they are called (I copied them to the code extract below).
All you have to do is run a ctrl+h (search and replace) to change the directory to your directory "C:\Users\xzbqxh\" and try it again (but being sure you are running 64 bit MS-Access).
So search "C:\Global" and replace with "C:\Users\xzbqxh\Global". it should make 10 replacements.
You might want to put in a stop statement just to be sure it is executing the correct code (the code wrapper calls are farther down in the module).
NOTE:
in the extract below I had the 64 bit dll in a directory called "C:\Access\GlobalVariables\" but I decided to comment it out since I figured people would not want to create directories.
so I changed the code to point to the "C:\" directory instead and to do my tests I dumped both dlls in there (deleting them once I was done).
A successful Boolean test shows "Boolean Test Successful". A failure shows "Test Failed". The string test has two different successful messages. Which you get depends on what happens.

Tips for anyone wanting to use this code.
Normally with the useage of this global variable technique if you get the data prior to it being assigned you will get a very low negative number and you can use this to initialize it with a set command.
However with the boolean get command I just found out that you must set the boolean global variable first. If you don't it will actually lock up your whole machine (at least it did in my machine).
The other tip is with the string get command you may need to use the Left string command to get the left portion of it since sometimes extra characters are returned (I am not sure if they fixed this in the 64 bit version).

Thanks again,
John

CODE
Private Declare Function GV_GetNamedBool Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal intOther As Boolean, ByVal strElementLoc As String) As Boolean
Private Declare Function GV_SetNamedBool Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intSetValue As Boolean) As Long

Private Declare Function GV_GetNamedDouble Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intOther As Double) As Double
Private Declare Function GV_SetNamedDouble Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intSetValue As Double) As Long

Private Declare Function GV_GetNamedInt Lib "C:\GlobalVariable_64bit.dll" _
                                        (ByVal strElementLoc As String, ByVal intOther As Single) As Long
Private Declare Function GV_SetNamedInt Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intSetValue As Long) As Long

Private Declare Function GV_GetNamedFloat Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intOther As Single) As Single
Private Declare Function GV_SetNamedFloat Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intSetValue As Single) As Long
                                      
Private Declare Function GV_GetNamedString Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal strOther As String) As String
Private Declare Function GV_SetNamedString Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intSetValue As String) As Long



'Private Declare Function GV_GetNamedBool Lib "C:\Access\GlobalVariables\GlobalVariable_64bit.dll" _
'                                       (ByVal intOther As Boolean, ByVal strElementLoc As String) As Boolean
'Private Declare Function GV_SetNamedBool Lib "C:\Access\GlobalVariables\GlobalVariable_64bit.dll" _
'                                       (ByVal strElementLoc As String, ByVal intSetValue As Boolean) As Long
'
'Private Declare Function GV_GetNamedDouble Lib "C:\Access\GlobalVariables\GlobalVariable_64bit.dll" _
'                                       (ByVal strElementLoc As String, ByVal intOther As Double) As Double
'Private Declare Function GV_SetNamedDouble Lib "C:\Access\GlobalVariables\GlobalVariable_64bit.dll" _
'                                       (ByVal strElementLoc As String, ByVal intSetValue As Double) As Long
'
'Private Declare Function GV_GetNamedInt Lib "C:\Access\GlobalVariables\GlobalVariable_64bit.dll" _
'                                        (ByVal strElementLoc As String, ByVal intOther As Single) As Long
'Private Declare Function GV_SetNamedInt Lib "C:\Access\GlobalVariables\GlobalVariable_64bit.dll" _
'                                       (ByVal strElementLoc As String, ByVal intSetValue As Long) As Long
'
'Private Declare Function GV_GetNamedFloat Lib "C:\Access\GlobalVariables\GlobalVariable_64bit.dll" _
'                                       (ByVal strElementLoc As String, ByVal intOther As Single) As Single
'Private Declare Function GV_SetNamedFloat Lib "C:\Access\GlobalVariables\GlobalVariable_64bit.dll" _
'                                       (ByVal strElementLoc As String, ByVal intSetValue As Single) As Long
'
'Private Declare Function GV_GetNamedString Lib "C:\Access\GlobalVariables\GlobalVariable_64bit.dll" _
'                                       (ByVal strElementLoc As String, ByVal strOther As String) As String
'Private Declare Function GV_SetNamedString Lib "C:\Access\GlobalVariables\GlobalVariable_64bit.dll" _
'                                       (ByVal strElementLoc As String, ByVal intSetValue As String) As Long

Attached File(s)
Attached File  Global_Variable_2.2_MyNotes.doc ( 241K )Number of downloads: 2
 
Go to the top of the page
 
GlenKruger
post Sep 13 2017, 08:50 AM
Post#4


Utterly Crispy UA Forum Administrator
Posts: 8,766
Joined: 29-September 01
From: Edmonton,Alberta,Canada


Just a quick look at the test database the dll needs to be under the C:/ directory not any sub directories.
Haven't got time this morning to try it waiting on Nurse to come to my home.

--------------------
Human nature, it is a funny thing and the hardest thing to program to prevent.
Glen Kruger KNKConsulting
MS Access MVP 2013-2018| Wrox Techincal Contributor
Go to the top of the page
 
River59
post Sep 13 2017, 09:31 AM
Post#5



Posts: 1,344
Joined: 7-April 10
From: Detroit, MI


Thanks, Glen. I was trying to figure out if the path caused the problem but got sidetracked. I work in automotive so they are pretty tight about our pc's. I can only store files in my directory or on my department's shared drive. I did change the path in the module to point to where I stored the dll's. I thought it was weird that the 32-bit worked but the 64-bit didn't.

Bowlesj, I did change the path to the dll on my pc after I stored it but it still failed. At first I thought I had a typo so I did a copy/paste but again it failed. I'm not sure if Glen found something within the dll that expects a certain path or how he knows that it must be under C:\. Hopefully there is someone here today with the ability to save these on the C:\ drive and can test for you.

--------------------
Remember ... Armstrong, Aldrin and Collins flew to the moon and back with a computer system less complex than a modern, programmable toaster ...
Go to the top of the page
 
bowlesj
post Sep 13 2017, 09:46 AM
Post#6



Posts: 247
Joined: 20-May 08



I think the first message you mentioned would be because it could not actually find the dll at all.

When I use 32 bit ms-access to try and use the 64 bit dll it will give an error at the get or set commands shown below and it would stop at the command get or set command itself. The exact error it gives is this "Run time error 48: File not found: C:\GlobalVariable_64bit.dll". To make it easier to test I decided to put in the "On Error GoTo Error" command so it would keep going and I could give a simple popup to make it easier on whoever was testing it for me. To get the exact error 48 shown below I commented out the "On Error GoTo Error" command. This way you can be 100% it is hitting the correct command. Here is the main thing of concern. I read that if you buy Office 2016 you actually get the 32 bit ms-access. I am just now trying to figure out how to know exactly which of the two (32bit or 64 bit) that is actually running. I need to be sure that when I actually go out to get MS-Access that I can verify that I actually get the 64 bit version rather than the 32 bit version. They need an help/about ms-access popup that sais it is 64 bit but they don't seem to have it.

CODE
Public Function A_GV_GetNamedBool64(strName As String, blnErrorCode As Boolean) As Boolean
    On Error GoTo Error
    A_GV_GetNamedBool64 = GV_GetNamedBool(blnErrorCode, strName)
    Exit Function
Error:
End Function

Public Function A_GV_SetNamedBool64(strName As String, dblGVvalue As Boolean) As Long
    On Error GoTo Error
    A_GV_SetNamedBool64 = GV_SetNamedBool(strName, dblGVvalue)
    Exit Function
Error:
End Function
Go to the top of the page
 
River59
post Sep 13 2017, 09:58 AM
Post#7



Posts: 1,344
Joined: 7-April 10
From: Detroit, MI


I may not be the sharpest tool in the shed but I do know that if I put a file that a database needs in a different place, I should go into the module and change the file path. This was done the first time around.

It occurred to me that I may need the dll's in the same directory as the database so I did that. I tested and all of the tests failed ... dontknow.gif
At least I don't get the file not found error.


Attached File  TestFailed.PNG ( 37.04K )Number of downloads: 9


fyi ... I'm running Office 2016 32- bit on a 64-bit machine.

--------------------
Remember ... Armstrong, Aldrin and Collins flew to the moon and back with a computer system less complex than a modern, programmable toaster ...
Go to the top of the page
 
bowlesj
post Sep 13 2017, 10:07 AM
Post#8



Posts: 247
Joined: 20-May 08



Thanks. Yes that is the error. For sure it found the dll. I need to go back and find what I read about MS-access 32 bit coming with the 64 bit office (it does not make sense really).
Even at this link I can't find confirmation that I can choose 64 bit ms access.
https://www.microsoft.com/en-us/store/d/acc...16/cfq7ttc0k5dn
It just talks about the operating system being 64 bit which is totally different.
You would think they would be hyping up the huge increase in memory handling the 64 bit version has.
Go to the top of the page
 
bowlesj
post Sep 13 2017, 10:11 AM
Post#9



Posts: 247
Joined: 20-May 08



Determining for sure if you have 64 bit or 32 bit me-access.
http://portal.presentationpro.com/kb/a24/w...it.aspx#version
My understanding is 32 bit can go as high as 3 gig and the 64 bit can handle the maximum size that the 64 bit machine has to offer (64 gig in some machines which have 4 slots for 16 gig each).
Go to the top of the page
 
River59
post Sep 13 2017, 10:21 AM
Post#10



Posts: 1,344
Joined: 7-April 10
From: Detroit, MI


I knew how to check my version, bowlesj. I am running Office 2016 32-bit on a 64-bit machine. Sorry that the tests failed. If you can determine the problem and make adjustments, I can test again if you need me to.

--------------------
Remember ... Armstrong, Aldrin and Collins flew to the moon and back with a computer system less complex than a modern, programmable toaster ...
Go to the top of the page
 
River59
post Sep 13 2017, 10:23 AM
Post#11



Posts: 1,344
Joined: 7-April 10
From: Detroit, MI


64-bit Office is not recommended nor supported.

http://kb.mit.edu/confluence/pages/viewpag...ageId=155269580

--------------------
Remember ... Armstrong, Aldrin and Collins flew to the moon and back with a computer system less complex than a modern, programmable toaster ...
Go to the top of the page
 
bowlesj
post Sep 13 2017, 10:24 AM
Post#12



Posts: 247
Joined: 20-May 08



Hi River59. Thanks for clearing it up. You and I are both only running the 32 bit ms-access on a 64 bit machine and we get the same error when we try to get at the 64 bit dll with a 32 bit ms-access. Maybe Glen has the 64 bit ms-access as verified by the link I just provided.
http://portal.presentationpro.com/kb/a24/w...it.aspx#version
Go to the top of the page
 
bowlesj
post Sep 13 2017, 10:29 AM
Post#13



Posts: 247
Joined: 20-May 08



Thanks for the link to the 64 bit office issues. It helps me decide if I should buy a dedicated machine only for ms-access 64bit and multicharts 64 bit (and its 64 bit dll) while still running 32 bit as I am now on my normal machine.
Go to the top of the page
 
River59
post Sep 13 2017, 11:03 AM
Post#14



Posts: 1,344
Joined: 7-April 10
From: Detroit, MI


Good luck moving forward!

--------------------
Remember ... Armstrong, Aldrin and Collins flew to the moon and back with a computer system less complex than a modern, programmable toaster ...
Go to the top of the page
 
GlenKruger
post Sep 13 2017, 11:10 AM
Post#15


Utterly Crispy UA Forum Administrator
Posts: 8,766
Joined: 29-September 01
From: Edmonton,Alberta,Canada


Ok had a few minutes to spare while still waiting for nurse so I tried your sample out.
I placed the 64 bit dll under my C directory and after having to fix your DECLARATIONS to include the needed PtrSafe part of the declaration as a minimum it worked and passed all the button clicks.

I am using Windows 10 Enterprise 64 bit and Access 2013 64 bit.

--------------------
Human nature, it is a funny thing and the hardest thing to program to prevent.
Glen Kruger KNKConsulting
MS Access MVP 2013-2018| Wrox Techincal Contributor
Go to the top of the page
 
GlenKruger
post Sep 13 2017, 12:17 PM
Post#16


Utterly Crispy UA Forum Administrator
Posts: 8,766
Joined: 29-September 01
From: Edmonton,Alberta,Canada


The code for the 64 bit dll worked after further testing the 32 bit dll did not work so not being able to see how the dll was written I can't advise any further.

--------------------
Human nature, it is a funny thing and the hardest thing to program to prevent.
Glen Kruger KNKConsulting
MS Access MVP 2013-2018| Wrox Techincal Contributor
Go to the top of the page
 
bowlesj
post Sep 13 2017, 12:42 PM
Post#17



Posts: 247
Joined: 20-May 08



Thanks Glen. Thats great.

Unfortunately I am not a C programmer and have not learned to write dlls so I don't know what you mean by this
"after having to fix your DECLARATIONS to include the needed PtrSafe part of the declaration as a minimum it worked and passed all the button clicks."
Can you paste an example in here? I the mean time I am going to google to learn about it if I can. Googling "PtrSafe part of a dll the declaration"
I found something at this link but I decided to not put any guesses in here since it may confuse people (I can't test from my end yet).

I don't think the 32bit dll is suppose to work with the 64 bit ms-access. I just put that in there so anyone who might have a use for this dll (and who has ms-access 32 bit) would have an example. Again farther up at post #3 I included some documentation on the dll.

Thanks,
John
Go to the top of the page
 
GlenKruger
post Sep 13 2017, 11:33 PM
Post#18


Utterly Crispy UA Forum Administrator
Posts: 8,766
Joined: 29-September 01
From: Edmonton,Alberta,Canada


Hi John the declarations are in your modules so I had to add the PtrSafe to them so Access 64 bit would regconise them. It has nothing to do with the dll.

Here is what I did in the 64 bit module:
CODE
Option Compare Database
Option Explicit

Private Declare PtrSafe Function GV_GetNamedBool Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal intOther As Boolean, ByVal strElementLoc As String) As Boolean
Private Declare PtrSafe Function GV_SetNamedBool Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intSetValue As Boolean) As Long

Private Declare PtrSafe Function GV_GetNamedDouble Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intOther As Double) As Double
Private Declare PtrSafe Function GV_SetNamedDouble Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intSetValue As Double) As Long

Private Declare PtrSafe Function GV_GetNamedInt Lib "C:\GlobalVariable_64bit.dll" _
                                        (ByVal strElementLoc As String, ByVal intOther As Single) As Long
Private Declare PtrSafe Function GV_SetNamedInt Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intSetValue As Long) As Long

Private Declare PtrSafe Function GV_GetNamedFloat Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intOther As Single) As Single
Private Declare PtrSafe Function GV_SetNamedFloat Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intSetValue As Single) As Long
                                      
Private Declare PtrSafe Function GV_GetNamedString Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal strOther As String) As String
Private Declare PtrSafe Function GV_SetNamedString Lib "C:\GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intSetValue As String) As Long

This is the bare minimum you need to get your code to work on Access 64 bit.
What the PtrSafe part of the declaration does is to assign 64 bit memory location on you computer.

--------------------
Human nature, it is a funny thing and the hardest thing to program to prevent.
Glen Kruger KNKConsulting
MS Access MVP 2013-2018| Wrox Techincal Contributor
Go to the top of the page
 
bowlesj
post Sep 14 2017, 03:43 AM
Post#19



Posts: 247
Joined: 20-May 08



Thanks so much Glen. Microsoft will be happy too since I will make the purchase from their website after getting 100% assurance I will be getting the 64 bit version with the download. I would prefer a CD but what can you do?

Your explanation is interesting as well. I was more or less guessing the same as you did after reading the quote below from this link. However I have learned over the years I can never really be sure until I see it work so I wanted to wait and avoid cluttering this thread with bad info.
QUOTE
Which Longs should become LongPtr? It's actually pretty easy to determine what requires LongPtr and what can stay as Long. The only things that require LongPtr are function arguments or return values that represent addresses in memory. This is because a 64-bit OS has a memory space that is too large to hold in a Long data type variable. Arguments or return values that represent data will still be declared Long even in 64-bit.

I dropped the code in my 32 bit access and it does not compile but I assume that will be corrected when I bring it into the 64bit ms-access.

For those who know MS-Access and who also might be interested in technical analysis (TA) of the markets this thread will be of value since this dll is used in the two best TA programs in the world (MultiCharts and TradeStation).

Thanks again,
John
Go to the top of the page
 
AlbertKallal
post Sep 14 2017, 04:12 PM
Post#20


UtterAccess VIP
Posts: 2,551
Joined: 12-April 07
From: Edmonton, Alberta Canada


A few things:

You likely should write the VBA to work with 32 or 64 version without having to modify such code. In other words, develop and maintain one code base. The code should work on either platform and should not matter if one is running x32 or x64 Access.

The result (or shall we say goal) of above would be that you do NOT need two sets of code nor any “conditions” in the general code routines to work.

Of course having said the above, an x32 bit process cannot consume or link to an x64 bit dll. And of course an x64 bit process cannot consume or link to x32 bit dll’s.

Next up, for ease of support, you can (should) modify your external dll definitions to work WITHOUT a hard coded path name. As noted in this thread “some” confusing occurred in this regards. In other words, to run the code we have to place some .dll’s in hard coded locations

Eg:

Lib "C:\GlobalVariable_64bit.dll" _

Today we OFTEN see users computers locked down in which you are NOT allowed to place files in drive C:. This is ESPECIALLY the case with .dlls – placing dlls in a root location is a virus party waiting to happen!

And what about the common use of Terminal Services? Such a setup OFTEN means again that use of drive c: is NOT allowed, and again placing .dll’s in root/c: again is likely not allowed.

So as a maintainable goal, the “ideal” would be:

No hard coded location for the .dll’s – we should simply JUST have to place the two dll’s into the SAME folder location as the front end. If the folder is moved, renamed or whatever the code should continue to run.

The source code should work on both x32 and x64 version of office – no equipment to maintain two versions of the code. And we should not need “two” sets of sub routines – one for x64 and one for x32.

Of course if you compile to a accDE (which most suggest for any type of customer software), then you will have to compile x32 versions using Access x32, and for office x64 you have to compile with Access x64. If you use/distribute an accDB then you do NOT have this issue nor requirement.


So with above in mind?

Try the attached example:

Simply un-zip to any location or folder. Click on it – it will run – end of story! It will work on any computer running 2007 to 2016 regardless of OS, version, bit size etc.

How does the above “magic” work?

First up, let’s talk about Access and consume external .dll code.

Well, Access is able to consume TWO VERY distinct types of .dll code libraries.

The first type is what we call COM, or Automation, or ActiveX objects (all 3 terms can be interchanged – they are the same underlying technology that Access supports). This type of consumption is the most common for Access developers. So in Access you might want to use Word, or say some type of component like a tree view. For this type of external code, you will use from the VBA editor tools->references.

This type of code library thus requires that the .dll be “installed” and MORE important registered on your computer (so it appears in that VBA tools->references system). Often you have to regsvr32 the .dll in question. Of course such dll’s or application MUST be written to support “COM” interface and automation.

To “use” such objects in code you go:
CODE
Dim   myWord       as new word.Application ‘ early binding

Or

Dim MyWord   as object
Set MyWrod = createObject("Word.Application")  ‘ late binding


I should add that a 3rd type of .dll consumption would be .net dll’s, but they quite much follow the above convention (they are registered as COM objects via regasm (as opposed to using regsvr).


In this post/case, we are using the other type of .dll Access supports. This is a “simple” simple external (usually compiled with c++) .dll. Such external code routines are not ActiveX/COM objects, and you do NOT have to regsvr32 such objects. And you don’t use “com” interface such as CreateObject(), but use declare statements to the specific .dll in question. Such dll’s are usually created with C++ but you “could” create them with some hacks to VB6. I should also note that you can ALSO create such dll’s with .net code (a special loader is required to be part of your build – and I often use this approach).

The “major” issue with such external .dll’s is your declare statements “usually” include a hard coded path name in your VBA declare statements (and this CAN be avoided).

In the context of this post, we of course are using an external linked .dll and NOT com objects. So no regsvr32, no regasm required. And while location of the .dlls is not important, might as well “assume” and “adopt” that the .dlls will be placed in the SAME location as the accDB file (front end application).

Ok, so first step would be to “clean” up the code to use the correct declare statements when running x32, or x64 Access.

So we have this:

CODE
#If Win64 Then
  
  
   Private Declare PtrSafe Function GV_GetNamedBool Lib     "GlobalVariable_64bit.dll" _
                                       (ByVal intOther As Boolean, ByVal strElementLoc As String) As Boolean
   Private Declare PtrSafe Function GV_SetNamedBool Lib "GlobalVariable_64bit.dll" _
                                       (ByVal strElementLoc As String, ByVal intSetValue As Boolean) As Long

     .etc .etc . etc.
#Else

    Private Declare Function GV_GetNamedBool Lib "GlobalVariable_32bit.dll" _
                                           (ByVal intOther As Boolean, ByVal strElementLoc As String) As Boolean
    Private Declare Function GV_SetNamedBool Lib "GlobalVariable_32bit.dll" _
                                           (ByVal strElementLoc As String, ByVal intSetValue As Boolean) As Long

   .etc. etc. etc.
#End If


In fact, if we did NOT have to support Access 2007 then we ONLY the ONE FIRST set of declares to use the dll’s are required. (and we would not need the if/then # compiler directives).
Edit - above is not 100% correct - we still need/want the if/then to select the correct dll for the declares.

However, since this is 2007, then we will have two sets of declares as per above in the if/then compile settings.

(Also note how I removed the hard coded location from the declares).


Ok, so now our VBA declares will work for either x64 or x32. And we don’t need “two” sets of routines.


Next part:
The next goal is to make the code run WITHOUT a hard coded path to the two .dll’s. This will allow the code to run in any folder, and again without having to change or modify the code.

Since we are the developers – then we can “choose” where we will “assume” the .dll’s to be located. I think a “reasonable” assumption is to assume that the .dlls will reside in the SAME folder as where the front end Access application resides.

This magic trick involves two steps:

Removing the hard coded reference to the .dlls

On Access start-up we TELL Access to LOAD the correct .dll for use. Once the .dll is “loaded”, then all of the declare routines will function as desired.

This magic trick thus requires us to use a windows API call, and the name of the API is appropriate called LoadLibrary.

So we have this routine – and we call it from the forms on-load event (or where ever you place your “general” startup code routines).

CODE
Public Function CustomLoadDLL() As Boolean

   Dim strDllPath       As String
   Dim hLib            As LongPtr
  
   strDllPath = CurrentProject.Path & "\GlobalVariable_"
  
   #If Win64 Then
       strDllPath = strDllPath & "64bit.dll"
   #Else
       strDllPath = strDllPath & "32bit.dll"
   #End If
      
   hLib = LoadLibrary(strDllPath)
   If hLib = 0 Then
      MsgBox "Unable to load dll" & vbCrLf & _
             "Missing dll is:" & vbCrLf & _
             strDllPath, vbCritical, "Missing dll"
      CustomLoadDLL = False
   Else
      CustomLoadDLL = True
   End If
  
      
  
End Function



Now, in our VBA start up code before using ANY of the routines, we execute a command to “load” the correct .dll like this:

CustomLoadDLL



Once you executed the CustmLoadDLL command, then all of the declare statements will use the loaded dll, and you eliminated the hard coded path location of the .dll in the declares.

Note that this ALSO vastly simplifies the code.

Our button code now becomes:

CODE
   Dim blnValue As Boolean
  
   intStatus = A_GV_SetNamedBool("TestBoolean", True)
   blnValue = A_GV_GetNamedBool("TestBoolean", False)

    If blnValue = True Then
        MsgBox "Boolean Test Successful."
    Else
        MsgBox "Test Failed."
    End If


Note how there is NOT two sets of code required anymore (so two sets of functions to maintain is removed). You ONLY need above for both x64 and x32 versions now.

So the application now just runs, and runs no matter where you place the folder.

Try unzipping the folder – running it. It will run on the following versions of Access without issues:

Access 2007
Access 2010 x32
Access 2010 x64
Access 2013 x32
Access 2013 x64
Access 2016 x32
Access 2016 x64

QUOTE
It helps me decide if I should buy a dedicated machine only for ms-access 64bit and


No, you not setup a whole new computer. You likely will need 5, 10 or 15 computers for testing. A camel in the desert is likely to need water. A personal assistant writing letters is likely to need Word.

And a developer creating software is likely to need SEVERAL clean new computers during a SINGLE day. For that you will adopt virtual computing. Virtual computing for developers is about like a cameral needing water – you need clean new test computers on a daily basics. With virtual computing you can spool up a brand new computer with x64 office less time it takes to write this post. If you have windows 10 pro, then Hyper-V is included, and I HIGH recommend this choice. (Your computer should have a min of 8 gigs of ram). Another great choice is Virtual Box (free from Sun/Oracle).

In both of these cases you WILL have to install OS into the virtual machine from scratch. So if you have a extra copy of windows 7 or some such – I recommend you use that (so your cost issue is having a licensed copy of windows to install into the VM).


Here is a screen shot, I am running your program in x64 bit Access and x32 Access on my laptop at the same time:




And here is the Hyper-V manager showing that I am running your sample on win10Home Access 2013 x64 bits. Note the other machines I have are various windows server 2008, 2016 systems I use for testing etc. All of these test servers etc. run on my laptop – I only have one computer – but I do have at least 15 or 20 “virtual” computers for testing different setups.




Enjoy!

Albert D. Kallal (Access MVP, 2003-2017)
Edmonton, Alberta Canada
kallal@msn.com
Attached File(s)
Attached File  Access_GV_TestsAll.zip ( 251.19K )Number of downloads: 8
 
Go to the top of the page
 
3 Pages V  1 2 3 >


Custom Search
RSSSearch   Top   Lo-Fi    11th December 2017 - 09:34 PM