LabVIEW Idea Exchange

This idea is similar to two other ideas:

1) http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Support-for-HTML5-and-SVG-in-Web-Publishing-Tool/idi-p/1437488

2) http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Remote-Access-to-LabVIEW-using-HTML5/idi-p/1944781 ,

However, this idea has the following unique aspects/extensions:

1) In the past, it appears that the decision needed to be made between a Native App (like Data Dashboard) or a Web App. However, I believe both should be developed by NI. See http://www.ericbrynsvold.com/2011/11/native-vs-web-app/ and http://www.webmonkey.com/2010/08/how-do-native-apps-and-web-apps-compare for more details and an examination of the pros and cons. Facebook has both a native app and a mobile app and the user interface looks the same! So, the important thing is, it’s not one or the other, with both having their place.

2) Don’t develop the LabVIEW web app fully and then release it. Follow the path taken by the Data Dashboard for LabVIEW and release bits at time. This way we get something to use relatively quickly. Just simple numeric controls and indicators and Boolean controls and indicators would do to start with.

3) Put as much development effort into the web app as is currently going into the native app (Data Dashboard for LabVIEW).

4) The web browser user interface should reflect the contents of a VI. Also, multiple VIs / sub-VIs can be addressed. This last part is important since different devices may need different interfaces. For instance, for my upcoming home automation project, the user interface for the bedroom would be different to that for the home theatre.

Although Native Apps like Data Dashboard give a rich user experience, the effort required to handle multiple platforms can become onerous, as detailed in https://forums.ni.com/t5/Smartphones-Tablets-and-Mobile/Troubleshooting-and-Support-Data-Dashboard-for-LabVIEW/ta-p/3515264#comment-23928 . The Web App does not have to have the performance of the Native App. What is lost in performance (and I think this is not a big issue) it gains in universality.

I believe the need for both LabVIEW remote access using native and web apps, the concept of releasing early and releasing often and putting the same level of effort as the native app are the essence of this idea.

It important that the web app be able to use a standard web browser without any plug in. This way any mobile device can be targeted.

Wouldn’t it be great to use any web browser to provide a great remote user interface for LabVIEW?

Inspired by a breakpoint discussion I looked at some Menu Selections that I do not use.

View>>Getting started Window... is one of them.   Don't get me wrong! I like the GSW it has many useful features like all my pinned items, online links, the RSS feed.... Basically all the features that justified the new GSW in the first place BUT, it opens "Modal" and closes after the first action  If I want to do a few things I need to reopen the GSW and of course I can't do anything else while the GSW is open

BUT! I thought to myself, "Jeff," I said to myself "wouldn't it be just peachy keen if the GSW opened Floating (Hide while LabVIEW is not active) when launched from the Menu?"  After all FP.Behavior is run-time settable.

After much patting myself on the back for such a brilliant thought I figured I had better share that super-dooper idea with the community!

Currenly we have the option to set default control style (System, Modern, Classic). But it would be great to be able to specify a control as the default for a particular data type.

Use Case: whenever you convert a boolean constant to boolean control, you get a boolean radio button when your default controls are the System controls. Unless you have at least two options to choose from, a readio button is kind of pointless. So, call it a preference, but I always end up changing it to a check box, copying the label/caption to the boolean text (so you can click on the text to change the value, I guess people have learnt to expect it), and then hiding the label.

Wouldn't it be great to specify these parameters in preferences and always get a checkbox with the boolean text visible (and label hidden?), and boolean text being the same as the label? OK, may be I'm asking for too much, but at least getting a checkbox would be a good start.

An extension of the idea could allow us to specify may be a custom control as the default control for a data type. This already works when creating constants or controls are the wire whose data type is a typedef.

Hello,

For the moment, when you want to create a Packed Library you have first to create a LVLIB. 

The PackedLibrary build specification is based on a LVLIB ...

It would be nice to be abble to create a Packed Library the same way as a Shared Library (DLL). 

• Be abble to choose every VI to publish : The exported VIs are automaticcaly 'public'
• All other depending VIs or 'always included' VIs would be private ! 

Thanks a lot.

Manu.

It would be a timesaver to have a Search 1D Array In Reverse! Obviously we can code this ourselves, but a LabVIEW function would make it handier (and hopefully faster).

Hello all,

I'd like to suggest some improvements to the run-time menu editor dialog:  (This is found under Edit->Run-Time Menu...)

1.     Allow the window to be resizable.  (Scroll bars are no fun)

2.     When using source control (Perforce in my case), prompt the user to check out the .rtm file upon the first edit. (Same behavior as when editing VIs)  At present, if I forget to check out the menu file I get a very ugly dialog followed by an "Emergency Backup Destination" prompt.  [insert muttering of naughty words]

I'm then faced with two choices: Either I can save an "emergency backup," as the prompt refers to it, or lose all of my changes and edit my menu all over again.

3.     The manner in which the tree manipulation works seems kind of wonky to me.  I've been using it for a long time, but I'm getting to the point where I stop and ask, "Why does it do that?"  For instance:

Let's say I select the root node of my "Edit" menu which has several items under it, and I've got that menu open.  If I press the yellow, down arrow, the whole Edit menu relocates itself under my File menu.  The file menu is above the Edit menu!  Why does pressing "down" move the menu up?  Intuitively, I'd expect the entire Edit menu to move as a unit and appear after my View menu, exactly as it would if the whole "Edit" subtree was closed.  (This is hard to explain and I understand if my explanation is likely confusing.)

4.     When dragging and dropping tree nodes, there's no visual cue as to where the item will land.  You start dragging the node, mouse over the general area and cross your fingers.  Alternatively, you can eschew dragging and dropping altogether and opt for the yellow arrows of wonkiness.  Okay, in fairness the arrows are usually alright.

5.     I would really like to see Edit->Undo and Edit-Redo on this editor dialog.  Having to revert entirely and reopen the file can be frustrating.  Mistakes happen often, especially when dragging and dropping.

6.     This is less important to me than the other suggestions, but... is there any reason why the menu files couldn't be encoded in XML?  Right now they're not very text editor friendly.

Of course, as I offer these suggestions I intend no disrespect toward whomever developed the dialog - I'm simply perceiving room for improvement.

Thanks very much,

Jim