Re: Using Labview 8 with MS Visual Studio .net 2003 to create .lsb file



I really don't understand your reasoning for going with CINs on this anymore!

You say that you would get problems when using your C++ interfaces from
a DLL due to compiler differences. While I understand that compilers do
have different ways of linking C++ code, I do not understand why this
would be a problem with DLLs and not with CIN's as long as you restrict
your DLL build toolchain to the same compiler environment you use to
create the CIN code. Yes you can not directly call C++ dlls from the
Call Library Node but you can create an intermediate DLL that translate
the C++ object methods into standard C functions and then call it that
way.

What would be the advantages of doing this you ask?

1) you have only one DLL to create instead of many CIN code resources.
2) Modifications to the DLL do not require you to go into every single
VI and reload the code resource into a CIN. In fact as long as a
specific function is not altered at all in respect to its interface you
do not ever have to touch the according VI at all anymore.
3) If you use cdecl as calling convention you can create a project that
compiles on multiple platforms and provided you maintain the same
function interfaces for all platforms you can use one single VI
interfacing to the different DLLs/shared libraries on all the different
platforms without one single manual operation in LabVIEW. You just name
the library file in the Call Library "myname.*" and LabVIEW will look
and dynamically load and link to the appropriate shared library/DLL on
that platform.
4) Testing DLLs is much easier as you can use standard envrironments  to drive those tests.
5) A LabVIEW compatible DLL interface is virtually 100% compatible with
almost any version of Visual Basic and other similar development
environments.

So why spend any more time in trying to get CIN issues resolved with
every new version of Visual Studio as it generally breaks due to
different parameter settings and difference in custom build step
handling?

Rolf Kalbermatter
.



Relevant Pages

  • Re: QueryInterface failure.
    ... Not sure what you mean by a DLL desribing all interfaces. ... Microsoft MVP, MCSD ... Compile the common IDL file that containing all the shared interfaces ...
    (microsoft.public.vc.atl)
  • Re: DLL Vs. COM
    ... > functions from a DLL, ... I would guess at interface consistency (standardised interfaces like ... A perfect example from my own work is that all video sources that are ... In the case of the shell I can be the DLL ...
    (microsoft.public.vc.atl)
  • Re: Unzipping without external DLLs?
    ... Yet all the stuff mentions some kind of DLL or whatever. ... Visual basic creates a type library when you create a VB server object, thus eliminating the need for an IDL file. ... A C-like language used to define interfaces and co-classes for COM. Ole View is a COM utility that reverse-engineers a type library into a readable form of IDL. ...
    (microsoft.public.vb.general.discussion)
  • Re: WCF Advice
    ... I would definitely have the data types and the contracts in one dll. ... The service and the client would share the dll that has the interfaces and data structures that are passed between client and service. ... If you are publishing your metadata through Metadata Exchange, then you can have VS.NET connect to your service and create the proxy and all data types needed automatically. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Anyone tried cygwins DDLs?
    ... what you mean by saying that CINs are much slower than DLLs? ... experience with either CIN or DLL development. ... create a CIN with cygwin I definitely agree with you that he will run ...
    (comp.lang.labview)