LabVIEW
Interface + functions in C for new control
There's no way to do that.
Controls are not compiled C code. And that's just the first problem...
Controls might (almost certainly) contain compiled code, but that's in just one of the sections of a COFF like binary file format. The structure of the files as well as the content\requirements\possibilities of the sections is proprietary. The structure is the easy part...
I'd be interested if you do 'crack the code', but would advice to just give it up...
Search LabVIEW like a graph! 
@Intaris wrote:
As Wiebe says, going the other route is most likely completely futile.
Can still be fun and educating of course 
. Disclaimer: read the license, it might be illegal.
Just to mention, as it does not answer the original question... You (OP, not Intaris) might have asked the wrong question.
There are options to make controls with changed graphics, and to some extend, behavior. What is in LabVIEW might serve your needs.
You could even be looking for functionality that a type def, or a strict type def, provides.
You might try to explain the reason for your question, and get more useful answer...
wiebe@CARYA wrote:
There's no way to do that.
Controls are not compiled C code. And that's just the first problem...
Controls might (almost certainly) contain compiled code, but that's in just one of the sections of a COFF like binary file format. The structure of the files as well as the content\requirements\possibilities of the sections is proprietary. The structure is the easy part...
I'd be interested if you do 'crack the code', but would advice to just give it up...
Actually that was possible in LabVIEW 3.0 and 4.0. The Picture Control was originally created like that. However the interface to add such controls (a different resource type but similar to a CIN) was while object oriented in principle fully implemented in standard C. All LabVIEW controls (and diagram nodes) used to be implemented like that and there was a spreadsheet that configured the actual impementation of each of those objects. This was then put through a pre processor that created the template code to implement the dynamic dispatch tables for the object methods, all implemented in standard C. The whole thing was very error prone, difficult to maintain and highly version specific as each LabVIEW version added new dispatch methods to implement things like Undo, Search and other functionality. This meant that there was almost no way to write such an external control that would be upwards compatible to a newer LabVIEW version, so in LabVIEW 5.0 this interface to add external controls was mostly deactivated and in later versions completely removed. The internal implementation was still done that way for a long time, but I would guess that this part has eventually been refactored in C++ to make the whole thing much more maintainable. Managing object dispatch tables through hand crafted spreadsheets is definitely so very much last century.
But there was never any new attempt that I would know off to allow to add external controls as binary compiled components to LabVIEW, unless you count ActiveX Controls as such a thing, but that is not cross platform in any way.
wiebe@CARYA wrote:
@Intaris wrote:
As Wiebe says, going the other route is most likely completely futile.
Can still be fun and educating of course
Just to mention, as it does not answer the original question... You (OP, not Intaris) might have asked the wrong question.
There are options to make controls with changed graphics, and to some extend, behavior. What is in LabVIEW might serve your needs.
You could even be looking for functionality that a type def, or a strict type def, provides.
You might try to explain the reason for your question, and get more useful answer...
I thought to write my own controls(configurable, extendable, with some extra funtionalitites), use it as dashboards.
Anyway, I hate to be limited, so I would like to try make my own stuff when I have day off.
There's always XControls… Not a fan, but it does allow making your own custom controls with custom behavior.
@rolfk wrote:
Actually that was possible in LabVIEW 3.0 and 4.0.
I believe it's still possible to do even in the recent LV versions, but it would require a very low-level knowledge of LV core and its libraries, i.e. is almost impossible not having the sources. I'm talking about the contents of \resource\PlugInControls directory - when VDM is installed, it does contain IMAQ Image Control related files, which are the part of some private plugin architecture. I tried to figure it out, but it appeared to be super hard, even with my disasm skills (reversing CINs is a kindergarten comparing to it). They also use their own memory manager for some unknown reason. Anyway it'd be very interesting to hear someone's findings on that subject.
@rolfk wrote:
The Picture Control was originally created like that.
...
so in LabVIEW 5.0 this interface to add external controls was mostly deactivated and in later versions completely removed.
I have read your posts about the legacy plugin technology on LAVA: 1, 2 and partly 3, very entertaining research 
When you write that this tech was already dead when LabVIEW 5 was released, does that mean that the corresponding linker code was completely ripped out (as it happened to external subroutines) or it was just hidden and not used anymore (as it happens now with CINs)? I'm just curious, because despite having LV 3 and 4 distros I never had a chance to get hands on early Picture Control toolkit and it appears to be absolutely unreachable these days. 
By the way, what was the "FourCC" resource fork for such plugins?
Actually I believe in hindsight that the code was already disabled for the 4.0 release and eventually removed before the 5.0 release. There seems no code in 5.0 anymore at all that could load such controls.
And the FourCC code was "LVCT" and "LVND" so yes it supported both LabVIEW controls as well as LabVIEW nodes.
But I'm not sure the lvsbutil for 3.x was even able to create the necessary code resources. most likely it required a special tool for preparing the code resource after it was compiled from the C sources and to get the method dispatch table even compiled right you needed several header files from the LabVIEW source code and even more understanding of the internal dataspace heap organization of controls and and nodes.
What you noticed for the IMAQ control is not really an external code resource. It is some sort of version resource place holder or something. The entire code for handling the IMAQ control is fully integrated in the LabVIEW kernel which means it is basically part of every LabVIEW install, it just doesn't work properly without the right license.
