ak_nz

I should have clarified my workflow better. The PPL files, once built in the LabVIEW Dev environment, are then copied into a reference location that the specific TestStand project can access (this is normally within the root folder of the sequences or a sub-folder eg. "Components"). The Async steps are then configured to call the VI in the PPL directly. So component building (eg. PPLs but also other types like .NET assemblies) is independent and decoupled from the TestStand environment. That works fine for the projects I have done.

I've had examples working fine in TS 2019 and LV 2020. All LabVIEW dependencies are packed libraries built in the dev environment, then loaded in TS using the adaptor configured as RTE. Have you tried a very simple example eg. a simple VI that runs till panel closed?

If you mean how data is passed via the connector pane - it is all passed by value from a logical stand-point. That includes references, so you get a copy of the reference number in the VI, but it points to the same memory location. I say "logical stand-point" as there are some instances where the compiler will get clever and optimize the call (or places where you have specified it such as sub-routine). However, this doesn't affect how you as a programmer can view the behavior.

I'll preface my answer with - I haven't opened your code (no access to LV right now). So I can't speak to specifics. But my opinion - you should have a single composition root (main.vi) that creates and injects all the main resources at the beginning of execution. Then, that same root manages disposition (including any specific ordering) at application exit. Main either keeps references for later disposal, or each level of your execution 'hierarchy' returns it's injected dependencies recursively to enable that (eg. as part of a Dispose() method).

Personally I don't think of delegation as a pattern, just a natural consequence of encapsulation. In your example, you've included demonstrating polymorphism and delegation. If you want to focus only on delegation, I would probably make some adjustments: Two classes - "Duck" and "QuakingFunction". Duck class contains a QuakingFunction object. It has a 'constructor' or method to set the required object for that task (dependency injection). Duck class exposes the static "Quak" method. This method internally calls QuakingFunction.Quak() method of the object (your delegation). Note - if you make the QuakingFunction.Quak() method virtual, it lets you implement new child classes in the future that Quak differently (Strategy pattern). You inject the one you want at the time. You don't need the derived Duck classes at all in order to demonstrate delegation. The Duck.Quak() method can of course be called with the child class objects so that they too can quack .. like a duck (Inheritance).

I'm afraid you're stuck with NIPM, as far as I'm aware. There used to be a method by which you could install packages manually but I don't know if it still exists. To get around conflicts with ICT at our workplace, we virtualize the dev environment. Then we can do whatever we want (off the network). That might be something you could pursue as well.

I'll add my voice to that. When I ran Sequence Editor, I had an almost violent physical reaction. I don't mind the white as much (yes, I'd prefer something darker). I dislike the lack of clear contrasting colours on buttons, labels and the missing cognitive aids such as grids lines. We were planning to transition to 2020 but we've decided to stick with 2019 instead. Pity; the new Quick-drop aka LV is really nice.

The method is static - you don't need a constructor node so try without that. The exception text isn't in a language I'm familiar with but I suspect it may be due to which thread is executing the clumps. Try also setting the VI execution properties for the enclosing VI to run in the UI thread only.

I assume you're talking about a WPF app. WPF apps are normally launched via the static entry point App.Main() method, just like Windows Forms and Console apps (which by default specify a Main method in the arbitrarily named Program class). The contents of this method is normally generated for you by the compiler, and typically creates an instance of the App class, calls it's InitializeComponent() method followed by the Run() method. The default implementation of the InitializeComponent() method is parse your App.xaml, determine the startup Window class (in your case, MainWindow.xaml) so that Run() method can startup the Dispatcher for the message loop and load your window class. Try calling the static Main() method in your assembly.

We're not a small business, we're part of a large one. Guess there are benefits to such things after all.

VM works best for me. We're lucky that we have covered the Client OS licensing part of things so it frees us up to create a VM per "project" if need be and to share the VM (+ change the product key). You need a good external storage to keep all these VMs backed up, but when transitioning back to an old project it just a case of copying it back over to the dev machine.

Just a note that the C# code shown by the OP isn't magically interpreted differently by the C# compiler and will throw an exception at run-time just as rolfk says and for the reason he says.

Out of interest it has to do with the version of the run-time CLR rather than the framework (which has the runtime as well as bas libraries etc,). LV2012 and earlier - use CLR 2.0 (which exists in .NET Framework 2.0 - 3.5) LV2013 and later - use CLR 4.0 (which exists in .NET Framework 4.0 and later - 4.6.2 inclusive) You can easily download the .NET Framework 3.5 offline installer and add this install to your installer as an action. You can run the offline installer in "silent mode" so that it installs or bypasses if installation already exists.

My preference would be to have a "Set to Default" method of the class that initialises the object with reasonable defaults that you call on teh startup of your application. Then your settings UI can call methods on the object to tweak teh settings as the user desires. As a general rule I dislike the "Default Value" properties of controls because they can be very hard to control and enforce over the development lifetime of an application.