DLLs with similar prototypes

[zarnon]

My company uses a third-party device that has recently been upgraded to a new version.

Both versions have their own DLLs, which are not compatible with the other version of hardware.

We are upgrading our software to work with the newer version, but must remain backwards-compatible for our existing customers.

Unfortunately, the company that makes the device did not see a reason to support both versions in one program, and the 2 DLLs contain several functions with the same names,

which results in an obscene amount of link errors.

Is there a way to implement both DLLs in one project, or am I doomed to maintain two versions of all our applications?

[JettR]

Hey Zarnon,

I hate to be the bearer of bad news, but two dlls with the same name in the same project is going to be trouble.  It would be difficult to have both of the dlls in the same project.  Can you try renaming one of the dlls?  Good luck.

[JonathanN]

Hi Zamon,

One option that you can consider is to dynamically load and call the DLLs instead of statically linking to the DLL (i.e. including the import libraries in your CVI project). To dynamically load and call DLLs, you will need to use the LoadLibrary and GetProcAddress Windows SDK functions. When following this method you don't have to call the functions by their names but you rather declare functions pointers that represent the loaded functions. Refer to the How Can I Access DLL Functions in a LabWindows/CVI Program Without Including the Import Library in th... KnowledgeBase and the FAQ: Using Dynamic Link Libraries with LabWindows/CVI tutorial.

Hope this helps!

Best Regards,

[zarnon]

Thank you very much.  I've been messing around with LoadLibrary() and so far it looks like it's going to work.

After compiling, I started getting 'Double' faults from displayPanel, but was able to find a fix for it in this topic:

http://forums.ni.com/ni/board/message?board.id=180&view=by_date_ascending&message.id=32670#M32670

This person was also using LoadLibrary() in their code.  Somewhat interesting.

[zarnon]

I'm probably just talking to myself at this point, but this may be useful to someone.

I was avoiding the double fault by having Windows Visual Styles enabled, but ultimately didn't like it because it won't let you recolor many controls.

I tried using LoadExternalModule instead, but it had the same problem.  However when I used the example project for LoadExternalModule, it worked perfectly.

I discovered the reason the .uir for that project doesn't blowup, is because it only uses classic controls.

I tested all the controls on the example's uir, and found that adding any control that has a classic counterpart caused it to bomb.

Whatever it is that LoadLibrary and LoadExternalModule call up, it only knows how to draw the classic controls.

[LuisG]

Zarnon,

The 'Double' fault you're getting when you use certain controls is unrelated to your use of LoadLibrary or LoadExternalModule. It happens when icm32.dll is present (and presumably in a bad state) at the time that your panel needs to draw one of the lab-style controls. These are the default set of controls in CVI. They're all the ones that are not localted under the "Classic-Style Controls" submenu, or the ones that have an _LS suffix in the control name (if you're using NewCtrl).

Even if do you use lab-style controls, you can avoid this bug (for most, but not all controls) if you enable the Windows Visual Styles option. But as you pointed out, you then have the limitation that you can't pick your own control colors. So your best bet is probably to use classic controls -- at least for the ones that you need to change the color.

Luis

[LuisG]

Hello again,

You might want to check this thread also. It looks as if copying icm32.dll to the application directory also fixes the problem.

Luis

[zarnon]

icm32.dll is the root of the problem, but those 2 functions must be doing something to call icm32.  Panels drawn before calling those functions are fine, panels drawn afterwards throw the double fault.

I saw that other thread earlier today and tried it out with no luck.
I thought maybe my icm32.dll was corrupted, so I got a copy from another computer, but still no luck.
Finally, I downloaded an earlier version from dll-files.com and everything ran smoothly.

I feel like I've been a pain in the butt about this, but one of the affected projects is a dll, so it was important to get a fix that would hamper my customers as little as possible.
I doubt they'll have any problems with including an extra file, so this is good for me.

Thank you all for your help!

ps. If you care, the 2 bad dlls were version 5.1.2600.2709, the one that worked was 4.0.0.408.