Jump to content

G Interfaces for LabVIEW 2020


Recommended Posts

LabVIEW Community Edition 2020 is now available for download. The commercial edition will follow sometime in May. We prioritized the Community release for all the engineers stuck at home under quarantine.

LabVIEW 2020 introduces interfaces as a companion feature to LabVIEW classes. I and Allen Smith will be presenting what would have been our NIWeek presentations as a webcast this Friday.

Two topics, one time:
Intro to Interfaces (Stephen Loftus-Mercer)
Interfaces and the Actor Framework (Allen Smith)

Friday, May 1 10am, CDT
Join here (Microsoft Teams required): LabVIEW 2020: G Interfaces

[EDIT] The same link above will let you watch the recording for the next 90 days. After that, NI will find some place to more permanently host the video.

Youtube Link

If you have any follow up questions, Allen and I are both monitoring a specific forum thread on ni.com for this presentation for the next couple weeks.

To start learning about interfaces today, please see

  • the Fundamentals>>LabVIEW Object-Oriented Programming section of the LabVIEW 2020 shipping documentation
  • the shipping examples in
    examples\Object-Oriented Programming\Basic Interfaces
    examples\Object-Oriented Programming\Actors and Interfaces

If you are someone who already knows about interfaces from other programming languages and want to understand why G interfaces work the way they do, you may be interested in reading LabVIEW Interfaces: The Decisions Behind the Design.

  • Like 2
Link to comment
1 hour ago, Michael Aivaliotis said:

It would be great to have a project menu item, goto parent interface:

How would this work if a class has multiple interfaces? Maybe instead of a right-click menu option, some kind of visualizer that only shows the class's interfaces?

Edited by Mike Le
Link to comment
16 hours ago, Michael Aivaliotis said:

Why can't we get this class relationship view inside the project tree? It seems useful.

The project tree is an all-files view. Not every file is a member of a class. There are VIs in libraries, loose VIs, non-LabVIEW files (like readme.txt). We talked about a class view in project back at start of LVOOP project and repeatedly since then, and we repeatedly decided the project window was the wrong place for that. That is the reason the LabVIEW Class Hierarchy window exists. 
 

For a better view overall, checkout OpenGDS or NI-GDS toolkits (although neither is updated for interfaces at this time).

Link to comment
17 hours ago, Michael Aivaliotis said:

It would be great to have a project menu item, goto parent interface:

16 hours ago, Mike Le said:

How would this work if a class has multiple interfaces? Maybe instead of a right-click menu option, some kind of visualizer that only shows the class's interfaces?

 

Wouldn’t be “Go To...” it would be in the project item’s Find menu with Find>>Callers. Like all of those, Find>>Parent Interfaces would jump directly if there was only one and pull up a results list if multiple. 
 

We had it on the proposed task list and cut it out of this release. It goes in the iteration bin to compete with other priorities. 

Link to comment
11 hours ago, Aristos Queue said:

Wouldn’t be “Go To...” it would be in the project item’s Find menu with Find>>Callers. Like all of those, Find>>Parent Interfaces would jump directly if there was only one and pull up a results list if multiple.

That works.

11 hours ago, Aristos Queue said:

The project tree is an all-files view. Not every file is a member of a class. There are VIs in libraries, loose VIs, non-LabVIEW files (like readme.txt). We talked about a class view in project back at start of LVOOP project and repeatedly since then, and we repeatedly decided the project window was the wrong place for that. That is the reason the LabVIEW Class Hierarchy window exists.

Ya, I get it. But a new view wouldn't hurt for those passionate OOP users. Similar to the Files tab, you could have a Class tab.

Link to comment
  • 7 months later...
On 5/2/2020 at 4:57 PM, Aristos Queue said:

The project tree is an all-files view. Not every file is a member of a class. There are VIs in libraries, loose VIs, non-LabVIEW files (like readme.txt). We talked about a class view in project back at start of LVOOP project and repeatedly since then, and we repeatedly decided the project window was the wrong place for that. That is the reason the LabVIEW Class Hierarchy window exists. 
 

For a better view overall, checkout OpenGDS or NI-GDS toolkits (although neither is updated for interfaces at this time).

Well, it would be along the line of Visual Studio then. There you have the sub-view, typically located on the left top side with the Solution Explorer, Class View and Resource View tabs (all configurable of course so it may look different in your installation, but this is the default setup.) 

It's not like you can't claim that the LabVIEW project window drew quite a bit of inspiration from that Solution Explorer window in Visual Studio. 😃

Link to comment
On 12/14/2020 at 3:31 AM, Rolf Kalbermatter said:

Well, it would be along the line of Visual Studio then. There you have the sub-view, typically located on the left top side with the Solution Explorer, Class View and Resource View tabs (all configurable of course so it may look different in your installation, but this is the default setup.) 

It's not like you can't claim that the LabVIEW project window drew quite a bit of inspiration from that Solution Explorer window in Visual Studio. 😃

What you’re asking for is the dockable panels that NXG had. NXG was able to use more of that VS pattern. But LabVIEW doesn’t have the same setup. A class tree isn’t another view of the project tree — where do you put all the VIs and libraries that aren’t part of a class?

Link to comment
On 12/22/2020 at 4:42 AM, Aristos Queue said:

A class tree isn’t another view of the project tree — where do you put all the VIs and libraries that aren’t part of a class?

To be honest, I would probably not put them anywhere in that view. It’s called Class View for a reason. 😀

It hadn’t really occurred to me that you would want to have the non-class VIs visible in there. Is that a flaw or just out of the box thinking?

  • Like 2
Link to comment

It’s a project window, not an arbitrary information pane window. And while we could make it an arbitrary info window, there are usability issues with that. VS doesn’t create a single window/pane with various modes. It has many panes that can be rearranged as different dockers or windows. As a project window, it should provide different views on the whole project, not one aspect of the project. 

It is software — we *can* do anything. But various UX reviews suggest this particular approach would be a less-than-ideal solution. Is the downside worth the gain? Our answer up to now has been, “No, don’t introduce a bad hack, just wait and do it right in NXG.”

A variation that is in line with UI design expectations would be a splitter bar in the window that has the project pane above and the class pane below. The project pane would still have two views (virtual and files). Or a completely separate window. Or introducing a docking/undocking system. Any of those are things that would be more likely to fly. Do any of those appeal? Obviously a full docker pane system would take longer to develop. 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.