Leaderboard

Thoric, the way I do this is using Actors, where the Actor using scripting methods is running in the LV environment. Consider an actor as just an API around a shared resource, used to abstract and encapsulate state and resources. Defining an API to the Actor as a TCP/IP messenger with endpoints to handle message types (the native LV2013 Embedded Web Servers work swimmingly for this purpose) provides an API with the subset of functionality that you want to perform with the shared resource. Following your example above, one message type into the Scripting Actor would be "CreateNewVI", and the payload passed with this message are all the by-value parameters needed to constrain the creation of a new VI. That message from the remote caller is marshaled to the Scripting Actor running in the IDE, which has exposed an API through HTTP endpoints. The new VI could further be manipulated through additional messages, or information about it could be returned to the caller by-val. Limitations? Unlike .NET Remoting, we don't have native type safety between two remote applications, or "direct access" to the object itself. Additionally, this new level of indirection requires more programming -- you're creating a new by-val wrapper API as a subset of the by-ref shared resource API of Scripting. But this is both good and bad -- from a security standpoint, it's fantastic (since only the desired subset of VI Server is exposed, we have built-in declarations for things like access/error logs, security policies, access policies...). From a debugging standpoint, I'd argue it's far simpler, because all API calls are transactional with no distributed mutable state -- that's just a boon of actor-oriented design for ya. Whether or not this strategy is suited for your problem domain is sensitive to many factors (more business than technical) -- though, know that what you're wanting to do is possible (at the same time, technically elegant and concise), and i'm glad to talk more on specifics.

The set variant VI would need the same input, either "numeric format" or "numeric precision".

The LabVIEW Run-Time Engine excludes functionality that is purely for editing use...for example, there are no palettes in a built EXE. I'm guessing this is done to keep the Run-Time Engine size down. For better or worse, LabVIEW Scripting is considered editor functionality, and as a result, is not currently included in the Run-Time Engine. FYI, the VI Analyzer Toolkit includes a test called Built Application Compatibility that will check your application for any functionality that is not included in the Run-Time Engine.