LogMAN

20 minutes ago, Neil Pate said:

This was probably decided by the same committee that came to the conclusion that nobody really should be using Virtual Folders anyway. 🙄

You mean the same committee that works with Visual Studio all the time? I wonder where they get their ideas...

5 hours ago, JKSH said:

One feature I miss dearly in NXG is the ability to create type definitions inside classes. Want a typedef'ed enum inside a class's namespace? LabVIEW CG says "No problem", LabVIEW NXG says "No can do".

Yes, that is a bummer. Actually, the thing they call "G Type" serves as a strict typedef, but it is really just a class that doesn't inherit from gObject (it inherits from Void). Since classes cannot be nested in LabVIEW CG/NXG, the only way is to put both of them inside a common library.

Now, where have I seen this concept before...

1 hour ago, pawhan11 said:

Cross post from NI forums.

You should include a link to make it easier for others to find: https://forums.ni.com/t5/LabVIEW/This-class-control-or-constant-is-permanently-broken/m-p/4040676

1 hour ago, pawhan11 said:

Have You ever seen this error?

No, this is the first time. However, I used the LabVIEW Resource Editor to look at the default data of those controls and they expect the class library inside a project library ("BBP Database Processor.lvlib").

<DefaultData>"%00%00%00%011%1CBBP Database Processor.lvlib%12Operations.lvclass%00%00%00%00%00%00%00%00%00%00%00"</DefaultData>

1 hour ago, pawhan11 said:

I do not recall doing some extraordinary class manipulations when this error happened

You probably moved the class out of the library without saving its members (not sure about the exact steps, actually). You should revert your code to the last known good state. Hopefully you have version control in place. Alternatively you could try moving the class library back inside the project library. That might fix the VIs.

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

39 minutes ago, GregFreeman said:

Yes, this is the solution I keep wanting to land on except it doesn't cover the case where Event C wants to do something with parent state which is updated from an event. Using your example, assume event A is triggered and the string value becomes state that belongs to the parent. Now assume event C triggers writing that string to a file. The child event handler loop will not have access to the string that was updated in the parent event handler, since the wire was split. I am starting to think that I am trying to make what is more of a by-reference paradigm and fit it into a by value language, and the right solution if this is really needed is to use a by reference class.

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.

15 hours ago, GregFreeman said:

What I haven't figured out is, can I reuse OnA and OnB without having to register for Event A and Event B in the child class's event structure?

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

4 minutes ago, LogMAN said:

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.

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.

12 minutes ago, Taylorh140 said:

But this is the same as a changing value. And Dereferences would be hardly noticeable as a speed impact.

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).

1 hour ago, torekp said:

I searched for "DLL" in titles of posts to the forum on Application Builder etc, and got 0 results.  Which is wrong -- I know because I have posted a topic with "DLL" in the title!

What gives?

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:

😕

2 hours ago, Jim B said:

I'm not sure what happened to fix it, but I had the Actor Framework Fundamentals example open decided to try it... and it worked. So I tried creating a new empty project and class and... it works. 😲

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

🤷‍♂️

Got (the same?) issue with LV 2019 Version 19.0.1f1 (32-bit):

One thing I noticed, if you try to box-select inside this window, it behaves irrationally, like a panel that was moved to far on the X or Y axis. Maybe that's a clue?

On 1/29/2020 at 6:15 AM, Michael Aivaliotis said:

Ok this is so random how I found this, but I was able to reproduce it. I'm hoping others on here can reproduce it as well.

I see the same issue with Version 19.0.1f1 (32-bit).

5 hours ago, Aristos Queue said:

Say what?! Why in the heck is that a thing?! Since I really don’t want to dig into the C++ code to find the answer, does anyone know what it means to interpret a double as a timestamp?

http://www.ni.com/product-documentation/7900/en/

"LabVIEW 7.0 or earlier used a 64-bit double (DBL) to represent time, yielding 15 digits of precision. The number of seconds between 1st Jan 1904 (the timestamp Epoch or year zero) to 1st Jan 2000 is 3027456000. Representing this as a DBL would use 10 out of the 15 digits of precision. That leaves a very small resolution space to perform hardware timings using most of the resolution by simply going from 1904 to today.  Representing time as a DBL was not ideal since it did not meet industry requirements."

Most of them are actually LabVIEW specific and do not change based on OS settings. I suppose these are used to make LabVIEW look the same on all platforms. Some of them also emit special behavior.

For example, 0x01000037 (system owner) is an opaque color that automatically adjusts the color of an element to the color of its owning container. Changing the color of the container then also changes the color of the contained element without having to address it individually. Maybe this is also useful for XControls.

2 hours ago, Rolf Kalbermatter said:

I don't think there are any other values above 0x1000002 that have any meaning in LabVIEW.

There are, actually, quite a few: https://labviewwiki.org/wiki/Color#Environment_colors

Quote

Is LabVIEW a Functional or Object-Oriented language?

It's a dataflow programming language that supports both functional and Object Oriented programming paradigms. Like C++ but not confusing

On 10/15/2019 at 1:29 AM, Michael Aivaliotis said:

I don't think OO by itself will make LabVIEW popular, but where does LabVIEW end up on the reasons for popularity as presented?

LabVIEW will likely never be popular by the definition in this video, because it is not just a programming language but an ecosystem of hard- and software. It requires a lot of trust in NI and partners. You'd have to compare it to other proprietary programming languages with similar ecosystem for it to be "popular" in comparison.

On 10/15/2019 at 1:29 AM, Michael Aivaliotis said:

Or better yet, what can make LabVIEW more popular?

The first thing that comes to mind is interoperability. Calling external code from LabVIEW and vice versa still requires a decent amount of Voodoo (see the SQLite Library or OpenG ZIP as prime examples). To my knowledge there is no "plug-n-play" solution for these kinds of things. This is when the second best solution is often good enough.

On 10/15/2019 at 1:29 AM, Michael Aivaliotis said:

Is that something that anyone should care about?

NI is of course interested in making LabVIEW more popular to grow business. As users we should be interested in making it more popular so that NI and the community can cope with ever-growing requirements and to open up new (business) opportunities. At the same time there is also a risk of growing too fast. The more popular LabVIEW gets, the more LabVIEW is used for tasks it wasn't originally designed for. This will inevitable result in more features being added which increases complexity of the entire ecosystem. If this process is too fast, chances are that poor decisions lead to more complex solutions, which are more expensive for NI to implement and maintain in the future. At some point they have to rethink their strategy and do some breaking changes. I assume this is where NXG comes into play.

Is this good or bad? I don't know. It probably depends

There is a forum where they want to discuss conversion tools, best practices et cetera:
https://community.atlassian.com/t5/Bitbucket-articles/What-to-do-with-your-Mercurial-repos-when-Bitbucket-sunsets/ba-p/1155380

At git-scm they suggest using hg-fast-export. git-remote-hg seems to be popular as well. Someone wrote a script to automate the migration process to GitHub without using GitHub import. Although I'm not sure how well it performs it can be worth a try: https://magnushoff.com/blog/kick-the-bitbucket/