Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 05/25/2010 in all areas

  1. You mix two very different things together here. The first sentence is in fact a little outdated and only telling you half the truth although technically still correct. Because you can pass LabVIEW native datatypes to DLLs since about LabVIEW 5 too. That is when they added the "Adapt to Datatype" to the Call Library Node and since then the CLN is in fact equivalent in this aspect to CINs. So the sentence is right that CINs get the native data passed to it but forgets to mention that that is possible with CLNs too, and this sentence is in fact a remainder from the time when CLNs indeed did not have that option, due to system limitations in the at that time supported platforms including the Windows 3.1 and Mac OS Classic versions of LabVIEW. The second talks about structures containing C array pointers which you can get sometimes when calling existing shared library APIs. Since LabVIEW does not represent arrays and strings as C pointers there is no simple way to create such structures in a LabVIEW diagram. But if you do create the DLL yourself, you are of course free to define the type of your function parameters and in such a way can use the LabVIEW native datatypes for your shared library function parameters by choosing Adapt to Type. This is an choice you do not have at all with CINs as they ALWAYS receive the parameters as native LabVIEW datatypes. So it is not that CINs give you something you do not have with the CLN too, but that the CLN also allows you to call many API functions directly that use C array and string pointers as parameters. But this only works if the C pointers are directly function parameters, not when they are embedded inside clusters you pass to the API. As last remark a handy trick when creating CLNs using the Adapt to Type feature or any of the LabVIEW native datatypes such as String and Array Handles: 1) Wire up the Call Library Node with the datatypes you want it to have 2) Right click on it and select "Create .c File" 3) In the file dialog select a file name to write to and LabVIEW will write a C prototype with all necessary parameter typedefs and the extcode.h include to disk so you can go on and copy/paste it into your C source code to be sure to start with the right prototype.
    2 points
  2. Name: Icon Editor API Submitter: jgcode Submitted: 25 Jan 2011 File Updated: 29 Jan 2011 Category: *Uncertified* LabVIEW Version: 2009 License Type: BSD (Most common) Icon Editor API Repack Extended. The original Icon Editor API has been recompiled to User.lib. This code makes calls to v.i's/.ctl's in the Icon Editor plugin directory which is not of a symbolic path. This may lead to linking issues and therefore the API was extended to accommondate this. The Icon Editor API has been extended to provide additional functions such as Class Library Refnum wrappers, Global Stores and helper VIs. See http://decibel.ni.co...t/docs/DOC-8647 for the source code of the Icon Editor API. Code snapshot taken as of 15/05/10. Note: This original Icon Editor API code be updated by NI in the future. The password for the Extended Icon Editor API Library is "jgcode". Click here to download this file
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.