I have recently received this interface board, and successfully loaded the drivers on to my Windows 10 laptop using the SDK. The demo program runs as expected. However, I have put together a small Visual Basic program, using the DLL library calls in the pdf document, but on running the program in debug mode, at the first call to a DLL function Open() an exception is generated with the following message:
“An attempt to load a program with an incorrect format Exception HRESULT: 0x8007000B”. I have tried placing the VM167.DLL in alternative locations, e.g SysWOW64 and System32, as well as placing a copy in the project folder, but the behavour is unchanged.
It seems to me that Visual Basic 2008 Express does not like the VM167.DLL file that has been supplied as a download from your site. I would be greatful for some indication of how the get the routines in this DLL rcognised by Visual Basic
Many thanks,
Ian
It seems the issue is that VB 2008 is building the project to compile on “Any CPU” and the DLL is intended for x86 systems only.
Your project needs to be compiled for x86 systems only.
Please do the following to resolve the issue:
In the Tools --> Options --> Projects and Solutions–>General Check “Show advanced build configurations”
Select Tools --> Settings --> Expert Settings to see the Build option
In the Build menu click Configuration Manager…
In the Active solution platform select New…
Select x86 from the first ComboBox
Click OK
Good Morning Support Team,
I thank you for taking time to consider the problem I outlined a couple of days ago. You have identified correctly the source of the problem, and I have managed to configure the build for x86 systems, and I am pleased to report I can now interact with the VM167 card in the manner I had hoped for. However, I was not able to implement the fix exactly as you outlined; After implementing the first line, I was unable to find the Settings/Expert Setting in the Build Option. Some other online correspondent suggested that a project needed to have been loaded to get access to the build menu, and this helped me to add the x86 configuration.
It occurs to me that this point could be included in your PDF for the DLL - say, in the same section that you warn users that the DLL is not accessible from the Visual Studio environment? Additionally, would it be possible to issue your DLL’s that would in fact operate correctly for a development being carried out in a Visual Studio environment, since this is the standard for today’s developers?
Many thanks again for pointing me to a solution to my difficulty,
Regards,
Ian.
Thank you for the feedback.
Glad you resolved the issue.
Sorry, my mistake. - The option to choose Expert Settings / Basic Settings is only in VB 2010.
The current VM167.DLL works fine in a Visual Studio environment.
Please see the example projects how DLL calls are made
And please note the following:
- The VM167.DLL is a 32-bit Windows DLL.
- The main application must be compiled to 32-bit.
- Change the default target platform AnyCPU to x86.
If you compile as AnyCPU and run your application on 64-bit platform, then you won’t be able to load the 32-bit DLL file.
If you compile as x86, then the 64-bit system will run your application in 32-bit mode, and you’ll be able to load the 32-bit DLL file.
Good Morning Support Team,
Again, I thank you for taking time to respond to the few points I raised in my earlier note on this topic. To me, by far the most significant comment of yours concerns the ability of Microsoft Visual Studio, when configured as a 32 bit environment, to be able to operate with your DLL’s. This is at variance with the statement in the VM167_DLL_Manual.pdf, which states: “Microsoft Visual Studio users please note: The VM167.DLL is a standard Windows DLL, you cannot reference it.” On the basis of this statement I installed the Visual Basic 2008 Express, but I already had the 2019 Viisual Studio installed. I will transfer my code to this latter platform, and ensure it is configured for 32 bit and x86, as you suggest.
Many thanks,
Ian
This notification was added to notify Visual Studio users that the VM167.DLL is not a .NET assembly file. The file extension of an assembly file can be .DLL, which is very confusing.
According to this document you can add a reference to the following types of components and services only:
.NET class libraries or assemblies
UWP apps
COM components
Other assemblies or class libraries of projects in the same solution
Shared projects
XML Web services
There should not be any problems using the Visual Studio 2019 instead.
Good Morning Velleman Team,
Quite some time has passed since I communicaated with you on this topiic. In the meantime, my telescope focus control system using the VM167 asan interface between my astronomical processor and focusser has worked fine. However, I now wish to add some extension to the functionality, and also my development system has been upgraded, so I no longer have original Visual Basic environment - this is now Visual Studio 2019. As you indicate in an earlier discussion, Visual Studio reference muust be either .NET or Com assemblies. I now ask whether you can issue a replacement to the original .dll which is either a COM or .NET acceptable format?
Many thanks,
Ian Whiteley.
I’m sorry, at this time there are no plans to release NET assembly or COM component for the VM167.
It is possible to use the original DLL in Visual Studio 2019 environment.
Just open the solution in VS 2019 and use the upgrade option to convert the project to Visual Studio 2019 format.
Here are two screenshots showing how the VM167 demo project was converted from VS 2008 format to VS 2019 format:
Good Morning Support Team,
I thank you very much for considering my input and allso for the response you suggest, which I have followed. I pointed my VS2019 installation to a copy of the VS2008 project folder for my application. What happend was not at all like the sequence you showed in your reply. After an initial dely of perhaps 5 seconds, the screen showed the text of my app; there were no questions regarding Solution Changes or Migration Report.
However, after connecting the VM167 ccardto the USB system, I initiated the debug activity. My on-screen window and its buttons appeared on the screen, and after clicking my “Connect” button and exception was raised. I had hoped to attach a copy of the screenshot showing the error highlighted by VS2019 - unfortunately, I cannot find a means of doing this - however, if you tell me how to send you an image file, I will do so later… Previously, the error was that the dll could not be found. As you can see, the error now is an objection to the format of the dll.
Does this behavour suggest anything further that I might try?
Many thanks,
Ian Whiteley
First save the screenshot on your computer using any image editor e.g. Paint.
While editing your post, place the cursor where you would like to insert the image at, and click the image icon on the toolbar.
Then locate the saved image and click Upload button.
Here is the screen shot I referred to in my earlier post:
I hope there is sommething useful in this fragment.
Cheers,
Ian
It seems the issue is that in VS 2019 the target platform is set to “Any CPU” or “x64” and the DLL is intended for 32 bit, x86 systems only.
Please make sure to select platform x86.
And please make sure the VM167.DLL is put to the folder Windows\SysWOW64.