Andrew,

I don't know for DLL, but CIN code (ie. .lsb) can be included within a .llb
and LV will first look into the containing .llb for a missing .lsb before
checking other places.
An in-elegant solution would be to have the dynamically loaded VI call a CIN
proxy which in turns call the DLL. The user specifying the VI inside a llb
containing both file. OK it is definitely not very elegant !

The next step is to ask NI to add support for DLL inside .llb/VI (� la CIN)

Chris


> From: Andrew Johnson <[EMAIL PROTECTED]>
> Date: Mon, 22 Mar 2004 21:30:51 -0800
> To: info-labview <[EMAIL PROTECTED]>
> Subject: [W] unknown DLLs & executables
> 
> Normally, when making an executable, LabView will copy any DLLs that
> the linked subVIs required to a data directory that can reside next
> to the executable. This is fine, thank you NI.
> 
> Now, what happens when your application loads a VI dynamically... and
> it needs a DLL? The load will fail unless the DLL is nearby... in the
> "data" directory. Still not a problem if we know with some certainty
> which DLLs might be needed.
> 
> But suppose we do not? In that case, must the entire "resource"
> directory contents be moved to "data", in order to support any
> possible VI? And if that unknown VI uses/needs vi.lib support, then
> should the entire vi.lib directory also be placed next to the
> executable? Is this allowed under the LabView EULA?
> 
> Thanks for any thoughts from people that have already worked these wires...
> 
> -- 
> - Andrew Johnson
> - WireWorks West
> 
> 


Reply via email to