New feature re: LV as a General Purpose Language

[Val Brown]

How about a "Text-based Program" window like the Formula Node? This could allow for prior written code (perhaps only in C/C++ for ease of implementation in the beginning) to be dropped into a BD via "cut and paste" with the LV engine calling the appropriate link/compile process (hence restricting this, at least initially to the C/C++ base that underlies LV itself).

IF this were possible -- and implemented -- it would instantly allow for the inclusion of all of THAT pre-existing code and that could be very appealing to folks coming from that background.

[shoneill]

I second that with one small addition.....

I've often wondered why I need so much screen space when programming ActiveX. I'd love to have an ActiveX text structure which accepts some ActiveX reference as input and from that point allows me to address the objects and methods in text mode. Just imagine how much easier this would make ActiveX programming in LV....... Of course, method and property prompting would be required based on the objects in use.

I'd very much welcome something likt this in general. Like an advanced Formula node.....

Shane.

[Mellroth]

QUOTE(Val Brown @ Nov 14 2007, 09:23 AM)

How about a "Text-based Program" window like the Formula Node? This could allow for prior written code (perhaps only in C/C++ for ease of implementation in the beginning) to be dropped into a BD via "cut and paste" with the LV engine calling the appropriate link/compile process (hence restricting this, at least initially to the C/C++ base that underlies LV itself).

IF this were possible -- and implemented -- it would instantly allow for the inclusion of all of THAT pre-existing code and that could be very appealing to folks coming from that background.

What you want is Windows support of the "Inline C" structure?

http://zone.ni.com/reference/en-XX/help/37.../inline_c_node/

/J

[Val Brown]

QUOTE(JFM @ Nov 14 2007, 02:58 AM)

What you want is Windows support of the "Inline C" structure?

http://zone.ni.com/reference/en-XX/help/37.../inline_c_node/

/J

Yes, that would definitely be "10,000 lawyers at the bottom of the ocean"...

[Aristos Queue]

QUOTE(Val Brown @ Nov 14 2007, 09:04 AM)

Yes, that would definitely be "10,000 lawyers at the bottom of the ocean"...

I followed up on this. There are no plans to extend this feature beyond the small embedded-type platforms. The Call Library node exists for calling C code; that is considered to be both sufficient and more standard than an inline compilation of C code would be. Having support for the inline C would involve shipping a platform specific C compiler with every version of LabVIEW, and we don't have any interest in doing that. The embedded targets already have a C compiler built into them because that's how we get onto those specific targets, and the inline C node was originally conceived as inline assembler for efficient access to I/O registers on tiny platforms.

[Val Brown]

QUOTE(Aristos Queue @ Nov 15 2007, 12:25 PM)

I followed up on this. There are no plans to extend this feature beyond the small embedded-type platforms. The Call Library node exists for calling C code; that is considered to be both sufficient and more standard than an inline compilation of C code would be. Having support for the inline C would involve shipping a platform specific C compiler with every version of LabVIEW, and we don't have any interest in doing that. The embedded targets already have a C compiler built into them because that's how we get onto those specific targets, and the inline C node was originally conceived as inline assembler for efficient access to I/O registers on tiny platforms.

Yes, that all makes sense but the current support for external code is somewhat lacking for anything other than simple ActiveX objects. I have a specific library that I would like to support but it will involve me writing all of the wrappers for the properties and methods because the DLL Import Wizard can't correctly interpret the code. I'm sure that the original developer of THAT code would be happy for me to send it off to NI so that a more convenient import process could be developed -- I had previously submitted several SRs in re: to this problem.

It would be a real benefit to many (I'm sure) if this kind of extension could be implemented re: the DLL Import Wizard.