My new computer is a 64-bits one working under Windows 7.
I have build and debugged a home automation project with Visual Basic 2008 on my old computer (32-bits Vista) which runs without problems on a small notebook with a 32-bits Win 7 system.
Now under 64-bits Win 7, the debugger doesn’t find the .dll’s of the I/O cards (VM167’s and VM110’s) in the sysWOW64 folder at runtime. Copying the .dll files to the x86 folder gives a kind of format error (the file pointers are wrong or something like that).
Despite these problems, the compiled version works without problems on the 32 bit Win 7 notebook and all the (32-bit?) examples and demo’s work fine even on 64-bit Win 7…
I have tried to know the origin of the problem on the Visual Basic express help website (even changed to VB 2010 which didn’t solve the problem). What they say there seems that the debugger on a 64 bits system can’t point to a 32 bits .dll, as the pointers have a different format. But how to circumvent that is not very clear (they point to ‘remote’ debugging, even on the same computer).
[quote=“VEL255”]You have to change the compiler setting “Platform” to x86.
Please see this thread how to do it: viewtopic.php?f=3&t=5363[/quote]
Thanks for the reply! Had a small problem, as there was no “build” option in the menu, but that was solved in another discussion on the MSDN forum:
You may want to mention you need to be Tools–>Settings–>Expert Settings to see the Build option. Also, many people may need to download and install the ACE driver for 32 bit ODBC support.
The debugging on 64-bits Win 7 is working fine by now for the x84 platform, only one problem is left:
For the VM110/K8055 modules, I use the K8055D.dll, version 4.x (decimal version number 16777216). That works fine for all commands, except for a call to SetCurrentDevice(x) (where x is a long integer 0-3) which gives the following error message:
PInvokeStackImbalance was detected
Message: A call to PInvoke function ‘WindowsApplication1!WindowsApplication1.Form1::SetCurrentDevice’ has unbalanced the stack. This is likely because the managed PInvoke signature does not match the unmanaged target signature. Check that the calling convention and parameters of the PInvoke signature match the target unmanaged signature.
Eliminating this command works fine for all I/O commands with one attached VM110 in the testconfiguration, but in the final configuration three VM110 modules are connected. Which makes it mandatory to use the SetCurrentDevice(x) command…
BTW, changing x to 16, 32 or 64 bits signed integer doesn’t help…
You are using the latest DLL version (4.0.0.0).
I think you have downloaded the “Complete SDK Pack (Rev 4.0)” from this site: velleman.eu/distributor/supp … 8055&type=
There in the folder \Examples\K8055DemoVB_2008\K8055Demo is a VB example.
In this example there is used the SetCurrentDevice function.
Private Declare Function SetCurrentDevice Lib "k8055d.dll" (ByVal CardAddress As Integer) As Integer
If (k And 8) Then
RadioButton12.Enabled = True
If Not CardFound Then
RadioButton12.Checked = True
SetCurrentDevice(3)
End If
End If
Does it work if you compile and run this example?
The debugger crashed on a 64 bits Win 7 system, but after compilation it worked without problems on a 32 bits Win 7 system
Indeed by changing the ByVal Cardaddress to Integer, the problem was solved…
Maybe one of the secrets of 64 bits Win 7, that the “long” integer as pointer there is 64-bits, while on 32 bits Win 7, a “long” integer as pointer still is 32 bits?