When developing a utility to traverse any control using VI Server and save its contents to a file (similar to the OpenG utility using Variant) it is quite challenging to find out the size of the array's data. There are various workarounds, but all of these are relatively tedious and over-complicated. Why don't we have a "array data size" read only value on the property node of an array? This would make things MUCH easier. Shane. Message Edited by Intaris on 06-12-2009 12:33 PM
It would be useful to be able to name (either automatically or manually) the sliders of a Slide control (or needles of a Meter or Gauge). The use-case I have is for saving a configuration file (currently requiring typecast to/from a cluster with names), but it may also be useful to be able to Unbundle By Name. I found this post in the LabVIEW forums showing this idea has been talked about in the past also. Here's an image from that post:
A related idea would be the ability to replace the control with a Cluster control, and vice-versa. Currently, this requires creating a typedef and manually recreating the cluster.
After selecting an entry from the quick drop list I have to re-open it again for each item I want to place. Why not adding the possibility to keep it open showing the last selection? E.g. if I select the TCP Open item most likely I will use a TCP read or write in the next step. I think this could be easily done by copying the behaviour of the Control-/Function palettes which have a Pin to make them sticky.
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.
Please make the LabVIEW Web Server more efficient! I love the idea of the LabVIEW Web Server as it allows me to create powerful, dynamic web pages for my clients. However, I recently published my VI using the "Embedded" option of the LabVIEW Web Server and found that this uses 3 Mbps per instance. An NI support tech was kind enough to point me to the following article: http://www.ni.com/white-paper/3277/en. This article confirmed my fears: the LabVIEW Web Server is transmitting all of the data for each object (even the invisible ones) at the 10Hz update rate of my application.
For this reason, I've decided to use Windows RemoteApps (using the Windows Remote Desktop engine) to publish my VI. In doing so, my network bandwidth is reduced from 3 Mbps to 10 Kbps with zero loss of functionality. However, RemoteApps are a pain to set up and aren't nearly as nice to the end user as a web published LabVIEW front panel. I would like to suggest that you all look at the algorithm behind Windows Remote Desktop and use something similar for the LabVIEW Web Server. In my understanding, Remote Desktop simply sends CHANGED pixels from server to client, and sends mouse and key clicks from client to server. Why would you need anything else?
The current behavior of the LabView development system is to raise all its open windows (VI Front panel and Block diagrams that are not minimized) when one of them attains mouse focus. This issue has be discussed previously here
The issue becomes much worse if the "focus follows mouse" mode of the operating system is activated. In this mode try to work on a non-LabView window on top of some LabView windows. As soon as you accidentally hit one of the LabView windows with the mouse, all of them pop to the foreground, eventually hiding the non-LabView window totally. This is neither necessary nor convenient!
Moreover, all suggested solution in the above links are inaceptable (e.g. minimze most VIs). I need to have open many VIs at the same time and I need to look at them, while e.g. writing documentation in MS word.
Now I hope I'm not the only person who learned to love the "focus follows mouse" mode during years of using linux.
So, to cut a long story short, I suggest to introduce a config option like "raise on focus" that toggles the behavior for all open LabView windows. I do not even ask to treat individual LabView windows differently, since I understand that this is not possible due to the internal window handling of LabView.
Thank you for reading this,
Typically, when working with classes, one tend to work on one class at a time. Consequently, opening a specific dynamically dispatched VI (from another VI) should result by having the class implementation opened (like if it was opened from the lvclass). The Choose Implementation dialog should not be shown (in most cases).
I did some quick statistic, and in most situation, I care about the class implementation (about 80% of the time). In some instance I care about parent or children implementation (about 10-15% of the time). Finally, in some rare instance (<5% of the time) I care about the sibling implementation. Note: I confirm this with a few of my colleagues as well.
So what I am proposing is that by default we should not see the Choose Implementation dialog. When we specifically want to see this dialog we could use either of these methods:
Access it through a menu option (Ex: View>>VI Implementation).
Access it through a right click menu (Ex: Open Implementation).
Use a key modifier such as adding SHIFT (so SHIFT + Double Click or SHIFT + CTRL + Double Click will open the Choose Implementation dialog).
Comment and improvements welcome.
If a class is contained in the private data cluster of another class, this is the LVOOP equivalent to an Association (as OOP concept). I'd like to optionally display this relationship of classes in the Class Hierarchy window. It should also work for nested structures (class in array, cluster, DVR). As used from normal BD programming, different kinds of wire should be used to identify details of the relationship:
green color if it's a by-ref relationship (DVR, SEQ);
double wire if it's contained in an array;
an directional arrow symbol would be necessary to indicate the navigable end.
The following would be nice to have, but partially difficult to implement: In addition there should be a way to annotated the associations to indicate when the intended use is restricted to a child class, such as class that contains objects of the type of the same class. Here the association would point to an ancestor of this class. Either we should be able to put a comment on the 'wire' to document this intention. Ideally we could be able to wire classes with recursive associations (which are not possible in LVOOP, hence this should also not have any effect on the code by only be documentation), and link it to the implemented association wire.
I think there should be some way to select data out of an array on the front panel. Whe I mean by this, is that you can not click and highlight N x M number of cells, then copy and paste (into notepad, excel, etc). It doesnt even work if you right click the array, then press 'data operations >> copy data', unless you stay in LabVIEW.
Right now with VIAnalyzer, there is a built-in test for
General >> VI Properties >> Built Application Compatibility.
This test is supposed to check for issues related to execution as a built application (running in RunTime Engine)
However, it does NOT do any checks against MScripts for the MScript node functions that are not supported as part of the runtime engine, or that behave differently in runtime engine vs development environment. (generally identified by the yellow exclamation mark triangle in the dev environment)
This VI Analyzer test should be updated to include MScript node checking for compatibility against built application / runtime engine.
Having the possibility to hide a pane at run time. For example if you want to hide a Button Palette, a status bar, Tree View or helper pane as specified in this snapshot: Message Edited by Support on 06-02-2009 12:35 PM
I recommend that NI enhance the installer build functionality so it will automatically determine and check off the NI products that are required to make a functioning installer build. It should have options to allow for a installer build that will 1) install all required NI products plus the application code, 2) only install the required NI products and 3) install only the application code. This is important because after all NI products are installed, subsequent builds will contain only updates for the application code. For now, it is a several iteration guessing game for me and all other LV users to try to figure out the list of NI products that need to be added to an installer build.
Hello, It would be nice to add the ability to resize front panel objects, not only by pixels, but also by a percent value. (Like in microsoft office) It should also be nice to add a "Proportionnal" size update. The front panel object resizing (by mouse directly on the front panel) could also include a way to resize an object proportionnaly. (For pictures for example) I think that this feature is available in MS office Word, by using the "CTrl" key in combination with mouse selection : Resizing by mouse selection without "CTrl" ==> Non proportionnal resize Resizing by mouse selection with "CTrl" key ==> Proportionnal resize Manu.
the cleanup tool is useful and getting more useful each release. however, i still find myself having to cleanup section of code doing bundling and unbundling by hand because it requires manually reordering the names within the nodes. even worse, i sometimes reorder things and then run the cleanup tool again and it decides to move things around such that another reordering is necessary (ick!). let's just give the cleanup tool the freedom to reorder the elements itself. for unbundles it's always safe. with bundles care must only be taken if a value later in the bundle overrides a previous element in which case those few elements would have to maintain their ordering (which is a fairly low use-case i would guess).
LV's graph palette feels a bit outdated. Can we have the graph support an option for "google map" zooming and panning? That's what everyone who uses maps are used to... mouse wheel to zoom in and out on the graph, and click/drag to pan.
I realize some advanced zooming options wouldn't be supported by this mode (like just zooming x-axis or y-axis).
Changing the symbols on the tree control isn't easy at all, even the first 40 available ones. It would seem logical that on a double click event, the tree control would know the active item. Unfortunately it doesn't and should be changed. Here's some simple code that illustrates the extra code needed. This necessary code is not anywhere on the NI website or in the examples. Only a lavag.org thread provided a subtle hint...thank you crelf!
IMPROVEMENTS TO LabVIEW "Project Properties->Project->Separate Compiled Code...->Mark Existing Items" Dialog
Idea 1: Column Sort Options
When marking project items to separate compiled code, there are two columns: File, and Status. The "Mark Project Items..." list shows not only your VIs in the project; it also shows all the LabVIEW-provided VIs your project uses. Locating (your) VIs to mark can be tedious for a large project.
If we could click on the column headings and have it sort (forward and backward order) in the same manner as columns do in the "Details" view of Windows Explorer, that would make it much easier to find what we're looking for. For instance, by clicking on the Status column, all Unmarked items could be made to appear first.
Idea 2: Seletively do NOT show LabVIEW-included VIs.
Another idea is to add a checkbox that would cause VIs included with LabVIEW (those not authored by ME) to NOT show up in the listing; only your (local) VIs in the project would show up. The checkbox might be labeled "Include local project items only".
This would allow you to more easily contol the separation of compiled code in your VIs without the necessity of looking at what NI did with theirs...
When I insert a VI into the error wire, I almost always want to insert something from the same palette as the VI that precedes the one being inserted. For example, I usually want to insert a close or release function that is related to the previous VI. Unfortunately the options presented are not very useful since they only offer up the Dialog & User Interface Palette, the Cluster, Class & Variant Palette and the All Palettes. Why not include a shortcut to the Queue Operations Palette if the preceding VI is a Queue VI from that palette?
This seems like an easy one to implement and will speed programming for those of us who still like to use the right click palette menus to program.
I will be the first to admit I am no artist. My panels are either bland or look like crap. I have tried making custom controls and they look like crap. I generally settle for a bland front panel full of default controls, text, and indicators in gray with maybe a light blue background.
It would be nice to have a set of color schemes to chose from, like any modern OS has that would color the panel and controls/indicators in a complementary colors.
Have a simple way for people to make, save, and share color schemes.
Better yet a skinning engine that would allow the very artistic to produce and distribute custom control sets like the modern or new silver set.