LogMAN

I don't know of a way to do this OS independent. Here is a VI that gets the monitor and workspace area for any monitor, given a screen coordinate. Of course, this only works on Windows. Workspace.vi

Cross post: https://forums.ni.com/t5/LabVIEW/Data-Variable-Toolkit/td-p/4032397

I don't think that is possible. That said, the sources are located at <vi.lib>\AppBuilder

Not that I have ever done it, but the sources are located at <labview>\resource\dialog\PreferencesDialog. There is even a page template, so it might be possible somehow: <labview>\resource\dialog\PreferencesDialog\PreferencePages\pageTemplate.vit

Indeed, there is (to my knowledge) no way to achieve what you want with pure dataflow. You could put your string in a DVR and make it part of the parent state. As long as you keep the DVR contained inside the class, its behavior is well defined and can be documented. Of course, anyone who uses the class needs to be aware of the caveats.

Yes you can. Have a dynamic dispatch EventHandler.vi that handles the events from Parent in Parent:EventHandler.vi and a Child:EventHandler.vi for every child. Use Call Parent Method in Child:EventHandler.vi parallel to the event loop of the child. Only the Stop event needs to be handled by each child. Here is an example I put together (saved for LabVIEW 2013): Reusable Events 13.0.zip

Actually, if you turn your cluster back into JSON you can compare it to the original JSON string to see if there are any differences. The string is empty if every element is defined in the source string. Try this: Extract Parameters.vi Notice the "Differences" string, which lists all differences (missing elements) in your source JSON string.

@ThomasGutzler here is a version that does most of what you describe. The order of elements inside Parameters doesn't matter. You can use enums. It doesn't matter if the JSON string has additional elements (no error) However, you don't get an error if an element is missing ("two" in your example). That would require something like a "strict" mode, which I don't think is supported by JSONtext. Unfortunately code is removed from VI snippets on LAVA, so here is the VI. Extract Parameters.vi

You can change your terminals to dynamic dispatch at any time by choosing This Connection Is > Dynamic Dispatch Input/Output (Required) at the terminal block. You'll find that this option is only available for class inputs and outputs. To change your VI from static dispatch to dynamic dispatch, simply change both - input and output terminals - to dynamic dispatch.

Not necessarily. Controls, Indicators and local variables have "built in logic to prevent front panel updates when continuously updating the same value. This prevents front panel re-draws". You can achieve similar results by deferring FP updates. Of course, writing to the control or indicator directly is the most efficient solution, because they "do not need to de-reference pointers, nor make copies of the data in memory". For your specific case, perhaps you can update the UI less frequently to reduce CPU load. Displaying a new value every 100 ms is more than sufficient for most applications. If you have a lot of graphs, pictures, etc., consider reducing the amount of data and update them only when necessary.

Here is a KB article regarding the differences between controls and indicators, local variables and property nodes: Control/Indicator, Local Variable, and Value Property Node Differences There is also an article that explains the different threads in LabVIEW and what they are used for: How Many Threads Does LabVIEW Allocate?

The front panel should be visible during the test to ensure that it is actually redrawn. It should also contain the necessary number of indicators to make both cases are comparable. If you reuse the same reference multiple times and defer panel updates, it only measures the iteration time of the For-loop + a single redraw, which is not the same as updating the UI on every loop iteration. Here is a version of your VI that has 100 boolean indicators on the front panel and is visible during test (it is also important to have all indicators visible on screen during test): MethodPerformance.vi On my PC the differences are much smaller with this version (if you set the number of elements to 1, the number of updates is roughly the same).

You need at least four characters. Try "DLLs".

Did you enable foreign key constraints? You need to set PRAGMA foreign_keys = ON Otherwise foreign key constrains are ignored. https://www.sqlite.org/pragma.html#pr>agma_foreign_keys

Tested on two machines, same version, same issue. Selection box is an issue only on one machine, though. Found another strange behavior: When using View >> Always Show Labels and View >> Actual Size, this happens: 😕 Thanks, that fixed it for me too. However, only after opening the Launcher.vi. It didn't work by simply opening the example project. Than again, restarting LabVIEW unfixes it. Turns out, it sort of works when you open the class hierarchy window from inside a VI (an empty VI works as well). Steps to reproduce: Start LabVIEW Create new project Add new class to the project Open the class hierarchy window => notice that the window is broken Create a new VI Open the class hierarchy window => fixed 🤷‍♂️