Problem with different Labview platform

[Virginia_Solomon]

Maybe this issue must be address to NI.

I have this library calling a register DLL. The purpose of the library is to convert a type of movie file from hard drive(*.mcf type) to image stream then to show and eventualy to save it.

The DLL is designed by NAC camera designer, which is a high speed camera. The code is based on properties, methodes and events from DLL.

Code works well in Labview 8.6.1, in Labview 11.0.1, Labview 12.0f3. Unfortunately code does not work in Labview 11.0.1f2 which happens to be the one I am developing my applications.

I will post the code developed by NI Japan (camera also is designed in Japan) and the mcf file as well as the DLL which must be registered.

The code is compiled in 8.6.1.

Register first the dll then open the NAC MCFF Control_E.vi.

Brows the mcf file

Press Open button

Slide the frames one by one for showing the images content of the mcf.

If you want to open under other labview then 8.6.1 then copy the folder and run a mass compile under that version then open the same top vi.

Please, show me what is different for different versions of labview then in my version does not work.

Than you,

Virginia

[Virginia_Solomon]

I am sorry but attachments are big and I am going to add them one by one. Here you have the DLL which must be registered and the MCF movie..

After this I will send the rest.

Thank you,

Virginia

[Virginia_Solomon]

Here is the library from which the NAC MCFF Control_E.vi top vi must be calld.

Than you,

Virginia

[Blake-C]

What camera are you using? 
Are the LabVIEW versions you've tested this code with on the same machine? 
When you say the code "doesn't work", what do you mean specifically? Do you get an error? Do you not receive an image?
Can you find the VI propagating this error? 
Try using highlight execution and debugging the VI using probes to see if you are getting values where values should occur and find where you start getting null values or errors. 

[Virginia_Solomon]

I am using NAC high speed camera designated for very rapid events.

Code crashes under Labview 11.0.1.f2 (NOT 11.0.1.f3 as I mentioned before).

There is at one moment a pointer generated by my attached dll (FX_MCFF_FC.dll) as response call back to Convert event which it is taken in the code by the main loop into the case bmpif. Here the subvi nac_NI_BitmapRead.vi has a call library function node to gdi32.dll (windows\system32). This is the call that crashes the code in Labview 11.0.1.f2.

For Labview 8.6.1 the same vi works well, no error.

In Labview 11.0.1 generates an error which can be ignored then the image looks correct converted.

Labview 12 works similar as 11.0.1.

I gave you everything for being tested. The library is 8.6.1.

For testing different platforms you have to copy the original library then run a mass compile with the labview you want to open to.

Thank in advance,

Virginia

[rolfk]

Just because it doesn't crash does not mean automatically that everything is alright. You just might be unlucky that the memory corruption does not happen in a vital part of the LabVIEW memory.

Now, when loading your LLB in LabVIEW on my machine, the first indication that something is wrong would be the error message that C:\Windows\System32\gdi32.dll could not be found. And indeed this is a system DLL that should never be referenced by the full path but simply by the DLL name alone. So change the Library Name or Path in the CLN inside the nac_NI_BitmapRead.vi to just "gdi32.dll" (without quotes). And when you are at it, change the first parameter to be a pointer sized integer too, since this IS a pointer.

Now look in the configuration dialog in the Function tab a bit further down and notice that the Calling convention is set to C. 99% of all Windows userspace APIs are really stdcall under Win32 and fastcall under Win64. A "bug" in LabVIEW versions before 2009 attempted to automatically fix wrong calling conventions from C to stdcall, based on certain naming attributes of the actually exported function in the DLL (and no, LabVIEW does not show those decorated names but the human readable name). The problem with this fix was that it did not allow for calling (admittingly seldom but nevertheless possible configurations) of DLL functions that happen to follow this naming scheme but were explicitedly declared cdecl by the programmer.

Try it and tell us if that will help.

[Virginia_Solomon · Accepted solution]

Thank you Rolf,

You were right, everything is good now.

First thing I suspected was this pointer I received as event from conversion which I frequently noticed can be negative number the way I monitored. I consider that number as being a pointer to the bitmap info cluster of the converted image and I wonder how come it could be negative. I noticed it was negative no matter of Labview versions. But it looks it is more a handler to bitmap info of the converted image. Actually I asked the NAC SDK designer about his pointer but it is very complex chain for obtaining information and the SDK does not have any information in that area.

Thank you very much,

Virginia

[RavensFan]

Then you should mark Rolf's message as the solution to your question rather than your own thank you message!

First you will need to go to the options menu to the upper right of your last message and unmark it as the solution.  Then you'll be able to mark Rolf's message as the solution.