X___

...and graphical programming (sorta)! 

With more funders will come PoE (page here) which would be cool.

Where I learned about the Myriad-X vision processing unit (which the new green deal company, BTW, doesn't seem to know about - or the search box is broken?): https://www.intel.com/content/www/us/en/products/processors/movidius-vpu/movidius-myriad-x.html using DL (the page also refers to additional AI-related products).

I used to have a reputation to find bugs that nobody noticed... 

I am using LabVIEW 2019 SP1 in Windows.

I am trying to reorganize dependent VIs into virtual folders in a project. I have noticed that it is now impossible for me to drag an object in a non visible part of the project. It used to be an exercise in frustration management in the past (with a single pixel-wide sweet spot triggering a painfully slow scrolling of the project explorer objects' list) but it seems to have been solved brilliantly by completely removing the ability to drag and drop objects in non visible parts of the project...

To clarify what I mean, here is a dummy project with empty VIs:

If I now reduce the size of the window such as to hide the virtual folder and show the object I want to move into it:

I can't trigger the window to scroll anymore (all I get is the "forbidden" icon instead of the mouse cursor, which tells me I am trying to do something that is forbidden: it is not. I can drag the object in the virtual folder if it is visible).

Of course in this dummy example, I could expand the window to reveal the VF. But the point is that in typical situations, I have a (large) number of dependent VIs (or other objects) I want to reorganize in virtual folders, and my screen is not large enough to show both VF and objects.

Now a workaround is to Add... (contextual dialog) each file into the virtual folder by browsing the File Explorer, but this defeats the purpose of the Project Explorer, which "neatly" groups files located in many different places into a single flat list.

Now that I think of it, it might all be a clever plan to force us to abandon LV GC to move on to NXG... although I suspect it might not be easier to do there or completely different and counterintuitive.

PS: I am using a VM in Parallels Desktop, so it could very well be a Parallels bug, but I wanted to check with the community whether I am missing something obvious.

These are pretty bold color-coded statements in these troubled times... Kudo to NI:

I got it! Fifth Element

And don't think of visiting the site not logged on... You will be granted by this very invasive splash screen, every time.

5 hours ago, Mads said:

As for the logo, that's totally fine, for many of the reasons you mention. The package manager logo though...🤣

But it is a stylized P nis n't it? (Sorry for thr typoss)

27 minutes ago, Neil Pate said:

cannot unsee this now!

What do you see beyond "package" and "manager" ?

1 hour ago, LogMAN said:

I think it's time for me to watch the livestream footage.

Be so kind as to distill the substance of it in a post here.

I don't think the guy in the picture is going to be here in 100 years. Heck, I am pretty sure nobody at NI today will be here in 100 years.

Come to think about it, NI might not exist any more then. So what a well thought-through slogan to put up on a landing page...

Personally, I think this is way too much color for NXGNI. I fixed that for you:

And StarLogo TNG (The Next Generation)... the ancestor of MIT's App Inventor. After all, NXG is supposed to be so simple that everyone can use it, right?

Whatever. My question was: did I understand correctly that individual VI files shared between projects were going to become hard to use. The answer was no. I then commented that in this case there was nothing new of interest, or at least I could ignore the the gll paradigm.

As for picking a fight, why would I even bother. As you know, I left NI forums after you (AQ) summoned me by private message to stop expressing critical comments. There is a difference between engaging customers and addressing their needs, which I believe is something that would benefit from some soul searching on NI's part.

As for me, I have no interest in wasting any time with NXG until I am forced to abandon CG. I hope that by then I will be sufficiently proficient using other programming environments that are open, free and supported on all platforms. 

3 hours ago, Aristos Queue said:

Yes. It is an excellent change from CurGen that makes source management far easier for all use cases that we have evaluated.

Then I am completely convinced that I have nothing to add to that discussion (which I guess was the purpose of this enlightening statement).

43 minutes ago, JeffP said:

Can you elaborate on your concern?

Generally speaking - directly sharing source across multiple projects can easily lead to making changes in one project which unintentionally breaks another project. The recommendation is that if you have a piece of code that you want to reuse in multiple projects (maybe its a framework or a library) you should separate that code into its own module. The projects would then depend on the built component - a gll for example, so this enables you to maintain versioning and avoid the case I described. Alternatively you could distribute the shared component as an addon, but you would not be able to directly edit the shared dependency from the project which is dependent on it.

You are still able to directly share GVIs between different projects, we just don't recommend that you do it.

Thanks, this perfectly clarifies the matter. Nihil novi sub sole?

7 hours ago, JeffP said:

Directly sharing source VIs on disk between projects is not the recommended way of sharing code in NXG.

Am I reading this right?

It's a start. Humor and the recognition that the world is moving on outside the ivory tower...

It is a different product. It's like if a car company messed up some component and said: sorry, we fixed it the new model. But, hey no ill intent here, just a business model.

It's like moving the Expression Node back in some subpalette of the Mathematics functions that is not existing in the Base LabVIEW version (https://forums.ni.com/t5/LabVIEW/Expression-Node/td-p/3974820).

Completely uncalled for, but, hey, AQ doesn't think that text-based mathematics should even be allowed in LV, so what do we know?

55 minutes ago, Rolf Kalbermatter said:

The OpenG ZIP library is mainly an implementation of a ZIP archive reader and writer but uses at its core the zlib library for the compression and decompression, just as the ZIP library does that is included in LabVIEW. While the LabVIEW provided ZIP library only exports a few high level functions to be accessed, the OpenG version goes a lot further and basically exports a lower level API on which the whole ZIP archive handling is implemented. And in addition it also exports the according ZLIB  inflate and deflate functions that allow you to implement any compression that is based on the ZLIB compression method. It would be possible to implement GZ and similar formats on top of this without a lot of effort, by simply implementing a LabVIEW library on top of these ZLIB methods and some LAbVIEW file IO methods.

Can't use it with 64-bit LV, AFAIK...

Actually, the nipkg.ini is in \ProgramData\National Instruments\NI Package Manager\Settings\nipkg.ini

On 5/19/2020 at 5:20 AM, hooovahh said:

One fix I found was that after you enable the vertical scroll bar, disable it, and then enable it again. 

Can't get that to work systematically. Sometimes it does the trick, sometimes it doesn't. I believe this is worth reporting as a bug.

While this could be a wrong hunch, I wonder whether this might be due to the narrow scrollbar width in the NXG graph legend. Notice that it is narrower than that of a NXG array (shown on the right below). It is definitely narrower than that of the silver style graph legend (shown second from the top left), which is narrower than the modern graph legend (shown last on the left). The latter is of the same width as the classic graph legend.

The reason I am suspecting this is that I have seen something similar in a utility that was supposed to return the clicked element in an array (https://forums.ni.com/t5/Example-Code/Determine-Clicked-Array-Element-Index-in-LabVIEW/tac-p/4040339/highlight/true#M14360) and failed with silver and NXG arrays because the border sizes and other details of controls have changed from style to style, and the underlying routines have not been updated.

In any case, this is annoying enough to be reported.

That was a trick question.

OK. What is the idea of password protecting those CLN and not, say, those in the Analysis VIs. Are we at risk of blowing up the planet?

Are you sure of that? The hierarchy shows System Exec call, so it might be even cruder than a .NET call indeed: