X___

Try decimate array?

On 1/21/2014 at 7:50 PM, JackDunaway said:

 

I stumbled upon one resolution to this issue (air quotes, "issue") recently:

1. Restart LabVIEW
2. From the Getting Started Window, select "Tools >> Advanced >> Clear Compile Object Cache..."
3. Clear both User and App Builder cache (my hunch is that the App Builder cache is not necessary; but why not)
4. Restart LabVIEW
5. Open the guilty lvproj
6. Mass compile the project root
7. Now, "Find Items Incorrectly Claimed by a Library" -- no more spurious ownership issues

 

Anecdotally, it's not sufficient to clear the cache while the project is loaded (or, perhaps it might be sufficient with a subsequent reboot). Your mileage may vary.

This actually doesn't work as a general solution (one exception is enough to invalidate the rule, and I just experienced it).

However, as stated before, I believe that as long as they don't break the code, LabVIEW's compiler hallucinations can be ignored.

LabVIEW's motto: Move slowly and break things!

Another example of tricks with units.

The above formula works fine. If I want to check the value of the Boltzmann constant by adding an indicator where indicated:

Things look fine but they are not:

tested in LV 2021 SP1 64 bit

23 hours ago, David Boyd said:

Also, sorry X___, I realized belatedly that you're NOT an anonymous user.  A few of my elder brain cells were recalling old days where NI's LabVIEW forum reflected comp.lang.labview on Usenet, and postings from there ended up with a default anonymous identity.  (Perhaps that's what inspired you?).  No offense was intended.

Dave

I date back from the pica.army.mil email list but never used Usenet.

I am so not anonymous that I had a bunch of members of that mailing list drop by in one of my old labs say hi and gift me with a NI screw driver (this was back in the day where NI was gifting their users with goodies and trying to cultivate their relations with universities, just to give an idea of how far back I am talking about).

I was already pestering about LabVIEW shortcomings (to my defense, that was pre-undo).

Nothing changes...

49 minutes ago, ShaunR said:

Nope. I just provided the back-save of your submission.

Noted.

On 2/10/2024 at 10:53 PM, ClinTrialist said:

If you have the Professional Version of macOS LabVIEW or have purchased the macOS Application Builder, you can build standalone applications using a post-processing VI that will run on any x86_64 (Intel) or arm64 (Apple Silicon) MacBook Pro, etc. through at least the last release of LV for macOS: 2023 Q3. 

I am not sure I get it. What is that "post-processing VI" you are talking about?

Can this been downgraded to 2021 or earlier?

It starts looking like somewhere else on the internet (https://developer.ibm.com/languages/cobol/😞

10 hours ago, Mads said:

Now that 2024 Q1 is released maybe we can just skip to that 😮 It will be interesting to see if the issues highlighted in this thread has been resolved(?).

So it is the new way to not release any info whatsoever ("NI did not create this content for this release") on new releases?

I did not see any beta forum either during that all time. This is important to me, as I need to find funding for migrating my code base to a new environment, and any official evidence that NI/Emerson has dropped the ball to a new low (if I can forge this hybrid expression for the occasion) is useful.

Check this thread though:

I wasn't able to take advantage of any multicore speed up and as for many NI toolkits, documentation is aspirational.

I think it is actually more trivial: the behavior I was observing is indeed related to an ancillary window opening, but that was triggered by a user-selected menu item. If I programmatically open the window, the "Mouse Leave" event doesn't appear to be fired (as expected).

In fact, going to the menu bar triggers a "Mouse Leave" event. Why not. However, for some reason, the "Mouse Enter" event is not fired if the selected menu item is actually inside the window (which is almost always the case). This is what got me confused (or rather my code).

So I guess my question is thus: why is the Mouse Enter event not fired when the user releases the mouse button after having selected a menu item?

It's a very dead thread but it's the one I found when trying to figure out why a "VI Mouse Leave" event is fired when I open another VI programmatically even when not activating that VI.

Since that has been suggested as being the source of the OP's problem (but then NI suggested it was a bug with the Abort method), I am wondering whether this is expected behavior or a bug (which would then still be alive in 2021 SP1 which I am currently using).

If this is a feature, I am trying to understand the logic: a VI is opened and set to not be inactive, yet the Mouse is supposed to have magically moved to that VI's front panel, even if it is nowhere close to it?

As mentioned earlier, I have happily left the Apple eco-system at the end of 2020, but one of my users is a die-hard macOS fan and has decided to try running my 2021 SP1 64 bit executable on a M1 MBP running Parallels Desktop 18 (Windows 11 VM).

The code looks like it works fine, until some weird differences with the native Windows app start popping up.

For instance, a variable loaded from an XML file is internally converted to a value that is ever so slightly different than the one it adopts on a PC (as seen in a printout of the value converted to ASCII). In an another instance, the comparison of two floating point values, loaded from two different files, which "passes" a preset criterion on PCs, fails the test on the VM...

I don't see that there is any way to easily predict this type of problems and foolproof the code against them, so I believe I will just not recommend trying to use Parallels Desktop VMs to use my code on a Mac.

On 12/26/2023 at 2:45 PM, Mahbod Morshedi said:

I wanted to use one wire to carry all my data, so I made an array of clusters, a variant typed and a tag string' to' and did a tag search to find the data and get the variant. To convert that back to my data, I will have to have the original data type feed to "var to data". I want to get this done programmatically. Case structure is a no-go, so I was thinking of bundling all the data, finding the order of the data via the tag, and unbundling that way. Now, I think it was my naivete, and I should not be so lazy and manually do it when I add a new data type.

Have you considered variant attributes?

11 hours ago, drjdpowell said:

I will fix the inconsistance, either by making comlex numbers full not supported or fully supported. 

I have given up on using complex numbers in JSONtext after discovering this problem, so I am fine with either way but if there was a way to throw an error for unsupported types, this could prevent people like me from building on sand (of course I should have more testing of my code, but I am a one man orchestra, so that is not always an option).

Note: the last point appears somewhat related to this issue:

https://bitbucket.org/drjdpowell/jsontext/issues/108/from-json-textvim-does-not-return-an-error

On 12/20/2023 at 2:30 PM, X___ said:

[Bug Report/Feature Request]

The following diagram is self-explanatory:

It returns an error 402843:

JSONtext.lvlib:Scalar JSON text to Variant (not inlined).vi:5750001<ERR>
Unhandled Type: "Double Complex"

At least it does return an error. When the complex numbers are within an array inside a cluster, the corresponding data is ignored and the default (empty array) is returned instead without any error.

Note that the To JSON text.vim doesn't complain and outputs the expected "1 +2 i" string.

 

Raised here: https://bitbucket.org/drjdpowell/jsontext/issues/103/what-to-do-about-complex-numbers

[Bug Report/Feature Request]

The following diagram is self-explanatory:

It returns an error 402843:

JSONtext.lvlib:Scalar JSON text to Variant (not inlined).vi:5750001<ERR>
Unhandled Type: "Double Complex"

At least it does return an error. When the complex numbers are within an array inside a cluster, the corresponding data is ignored and the default (empty array) is returned instead without any error.

Note that the To JSON text.vim doesn't complain and outputs the expected "1 +2 i" string.

For context, I should have mentioned that the reason my account was not associated with an active subscription license is because my college admin hasn't found the patience to fight with NI to get it re-activated properly. I suspect they will eventually give up (and that I am the only one still using LabVIEW in my Department, or others just reverted to the community edition).

As a result, we haven't got an active license for that reason for a couple of years (not that I would have ventured into committing to newer subscription-only versions).

As explained elsewhere, I had to personally take care of making sure our years of continuous subscription (or rather permanent license) was not wiped out in the process. It actually was, because of the failure to renew our license, so NI had to create a NEW permanent license number of 2021 and earlier. Yet, there is apparently no way for it to be stored on NI's web servers or associated with my account...

I consider myself lucky to have been able to reach a capable employee who managed to verify that the information I was providing was correct and went the extra length to share a private link to an installer (first a web installer, and next, after I told him than not all machines are internet connected, a downloadable installer).

I wouldn't be this will last.

Similar story here. A hardware vendor suggested I tried the 32-bit version of LabVIEW to figure out a problem I had encountered. I went to the website to download the installer of my permanent license LabVIEW 2021, only to be greeted with grayed out download links and a message according to which:

Quote

Previous versions are available only to customers with an active subscription license or service agreement for this product. Purchase a license or update your service information in your NI User Account to access locked versions.

It turns out there is no way to update any service information, so I called NI tech support and magically got someone to pick up the phone right away, listen to my description of the situation and after verification, offer to send me a link to the installer download.

I am still fighting with Microsoft OneDrive to get to that installer download, but the bottom line is that NI Emulsion is apparently willing to waste the time of their tech support employees to access software installer that they were entitled to according to the initial term of their license. Until they won't?

6 hours ago, mhenz said:

It was fixed a view days later (f1 or f2 patch). I actually use the f2 patch (version 21.0.1.f2). 

edit: bug was in 21.0.1.f1 and fixed in 21.0.1.f2

I confirm. Thanks.

Any update on this bug? I can't figure how to check the status on the Emulsion website.

Thanks for the feedback

Looking into the code of the Three Button Dialog Core.vi, I found a conditional case structure messing up with the displayed string which I must have added in a late night debugging session and forgotten about.

Disabling it restored the expected behavior.

For a while I thought that LabVIEW had been spooked...

Here is the output:

No better luck with long messages:

here is the result:

notice the "Standard" added to the text.

Windows LV 2021 SP1 64 bit

7 hours ago, ShaunR said:

 We need innovators (like the guy that invented malleable VI's for funsies) only in their 20's and 30's - not 70's.

We need to be realistic and pragmatic.