LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

It would be useful if the Search Results window would show the number of callers not in memory (screenshot 1).

 

1. The Search Results window, with extra information about the number of callers not in memory

Find all instances 1-edited.png

 

Screenshot 1 was generated by right-clicking the icon of 'SubVI.vi' and selecting 'Find all instances'. The dummy project is shown in screenshot 2. Screenshot 3 shows the Find Callers window that pops up when right-clicking SubVI.vi in the project and selecting Find>Callers.

 

2. The project

Find all instances 3.png

 

3. The Find Callers window

Find all instances 2.png

 

When refactoring, it is often necessary to find and replace all instances of a VI, before removing that VI from the project. A typical workflow for me would be:

  • Open the main VI of the application (to load in memory as many subVIs as possible)
  • Open the VI to be replaced/removed from the project, right-click its icon and select 'Find all instances'
  • Navigate to each instance replacing/removing the VI as necessary
  • Ctrl-Shift-E to select the VI in the project, right click the VI and select Find>Callers.
    • This sometimes brings up callers such as tester VIs that are not loaded in memory by the main VI of the app. In this case:
      • Open each caller previously not in memory. Use 'Find all instances' again.
      • Final check: Use Find>Callers one last time to ensure no callers.
    • This sometimes shows 'No items were found'.*
  • Remove VI from project and disk

*If the number of callers that are not in memory was displayed in the Search Results window, and if that number was 0, it would remove the need to check via 'Find>Callers' before removing the VI from the project.

 

The 'Find all instances' feature would become more complete if it displayed information about callers not in memory.

 

Thanks!

The idea is to add a return value option to user events:

Create User Event.PNG

Event Structure.PNG

Generate User Event.PNG

If there are multiple event registrations, the return value is passed through them. Pretty much like existing filter event.

 

Optional icing on the cake:

Spoiler

The Generate user event could be split up in a send and receive part.

 

A time out could be added to the receive as well. 

 

Waiting for return data could be optional. The data will still propagate though all registered event structures. 

 

Disclaimer

Spoiler
I've read all "User Event" search hits on the idea exchange. Closest\only related one I could find was Register-User-Event-as-Filter-event, which is mostly concerned about discarding the event. But the idea exchange search is terrible, so it could be right under my nose...

 

I have two arrays I'd like to pivot into an array of clusters of a particular typedef. I could index and bundle it myself, but it's just weird that I can't use this builtin function just because the typedef has an element that's an array.

 

Also, it's kinda weird that it won't take a typedef as prototype. Casting it after takes up about as much room as doing the bundle in a loop!

 

I can see some reasons that letting us pass in 2D arrays would lose the tight optimization of the original (maybe it can compile-time determine the size of the cluster elements if none of them are arrays... except that you can put in object data. I guess either that's a reference under the hood, or there's some other reason)

 

Or maybe it's that it could cause confusion between making a 1D array of clusters with 1D arrays, or making a 2D array of clusters of single elements? That seems like it could be solved either by only doing the former, or requiring a typedef in that case, to disambiguate.

If you are instantiating classes dynamically or calling VIs dynamically through VI server, you may need to include the source files under "Always Included" when creating a build. If you are dealing with a large number of files in a multi-developer environment, you might also be using an auto-populated virtual directory. The problem with this is that everything under directory will be included in the build. Say you are building a hardware abstraction layer with 100s of different instrument drivers, you will likely have all sorts of different files like programming manuals, unit tests, project files, lower level instrument libraries, and VI trees. You might not want all of these files included in the build. Some of the files might not even compile (ie. VI Trees), which will prevent you from creating a successful build. If you are instantiating the classes dynamically, all you really need to do is include the lvclass files since that will automatically bring in the dependencies for that class. You could separate these files, but it would likely be a less cohesive directory hierarchy. For example, if a developer is implementing a driver they will probably want to access the programming manual under the same directory hierarchy, while at the same time, a programming manual probably wouldn't be beneficial to a user when the build is deployed so you might not want it included.  Being able to define 1 or more file type patterns on either auto-populating virtual directories or on the build specification UI for source files, would quickly resolve this issue.

When right-clicking on a VI in a class, there's an option to "Remove From Library".  This option removes the VI from the library, but leaves the file on disk.

 

95% of the time that I'm removing a file from a class, I'd also like to delete it from disk.

 

The wording might need a bit of work, but it'd be great if there was an option to simply "Delete" or "Remove From Library and Delete".

 

(In the meantime, I'll continue to "Explore...", then "Remove From Library", then delete from my file system.)

 

carls___1-1590689294408.png

 

When working with classes, you can modify "Access Scope" for VIs either by right-clicking on the VI, or by going to Items Settings section of class properties.

 

carls___0-1590686557507.png

 

However, in order to change override settings for a VI, you must go to the class properties page.  These are not accessible through the right-click menu on VIs.

carls___1-1590686651627.png

 

It'd be quite convenient if these override options were also available through the right-click menu.


I think it would be really useful to have a Quick Drop shortcut installed by default that toggles label visibility for selected items. I know you can select multiple objects and right click> Visible items> Label but this takes me several seconds.

 

How I imagine it would work
Select GObjects on front panel or block diagram --> Ctrl+space, Ctrl+L --> label appears if it wasn't visible or disappears if it was visible.


If multiple items selected with a mixture of visible and non-visible labels, use the same logic as what happens when you try to embolden partially bolded text : toggle all to the opposite of the most frequent state.

 

I might write something that does this, but it would be really great if it was standard. 🙂

hi forum

 

always find it difficult to read the subdiagram label whenever the structure exceeded 2 screen widths (when avoiding stacked sequences). Can we have subdiagram labels that will always be visible, like its text will center itself within the subdiagram label portion that is within the viewable workspace, or left adjusted when the label text length exceeded the subdiagram label space.

It would be great if we could close the documentation editor window by entering <Shift> + Enter.  Several other LabVIEW IDE dialogs and text entry objects work this way already.  We can open the properties with a keyboard shortcut, and if we were last using the documentation, no mouse work is needed, except to close the dialog.  When I already have both hands on the keyboard, it would be nice to not have to grab the mouse just to close the dialog.

 

 

 

Edited to suggest using unused modifier key, Ctrl is already taken.

We often use property nodes to change controls appearance/behavior in a while loop but because of their added overhead, we don't want to do it every iteration, just when other values change. To get this effect you have to wrap the property node in a case structure and ti in the appropriate variables. this is bulky and hard to read at times especially because it encourages using "no names". Or you can create a sub VI with the right rappers on the inside but you have to pass in a reference. It would be great if there was a built in enable input on a property node (ideally without increasing the sizeof the top part). I even toyed with using the error in to get the desired effect (tying in a error or no error constant chosen by a case structure) but thought better of it (I think it gives the desired effect but sometimes you want to use the error input for timing control or actually as an error.

It seems like a simple request that would really clean up a lot of my code or improve performance if you are setting properties every cycle.

In many software packages, if you do a cut (ctrl+x) then paste (ctrl+v) it will move the item and then sometimes subsequent paste operations will make copies (sometimes they act like the clipboard is empty after a single paste)

In labview it is more like it makes a copy and deletes the original. This is somewhat unexpected behavior for me (maybe others find it normal). I would like to use it to move items around without having to drag somewhere in between (say if I want to move a terminal or local variable from one case to another I have to drag out while braking wire connection change cases and drag back in)  

For a control, if it had property nodes, connections in connection pane, events, or local variables all these connections brake or are deleted, and the new item is no longer connected to anything. If you do it on a property node, the new node is un-linked to anything. A local variable is the worst of all in my opinion. It deletes the original local variable but makes a new control that the new local variable is linked to. this seems like it would rarely if ever be desired behavior (you get the same problem just copy/paste on local variable as well). On the other hand just making a new local variable linked to the same control would be great for both cut/paste or copy/paste. 

LabVIEW do a lot of background changes on all VIs in the memory even if the user did not change anything.

You can recognize this when you close a VI and LabVIEW asks you for storing it or some of its SubVIs.

The can be prevented by enabling the options "Tread read-only VIs as locked" and "Do not save automatic changes".

Having an active read-only flag on several thousand VIs and removing / setting it manually is not really funny during daily development work. Wouldn't it be possible to prevent storing automatic changes independent from the read-only flag of the VI?

My use case: I have to open my Project sometimes in LV32 and sometimes LV64 to develop / run and compile the code. Each time LV wants to store all VIs when they have been stored with the other Bit-Version before. In each case I'm using LV2019SP1. The compiled code is already removed from all my VIs.

 

Andi_S_1-1585921460715.png

 

To my surprise there's no type specifier on the In Place Get/Replace Variant Attribute.

 

I post it as an idea even if I'm sure there's a good explanation about it. I would find it convenient if the Get Attribute type would match the one Set.

 

Is it because the new value could be of any other type? At least on the left side, if we could just specify the type as the regular Get Attribute it would be nice.

 

JICR_1-1583872024126.png

JICR_2-1583873251354.png

 

 

 

If I create a zip file for my build distribution in a LabVIEW project, I can choose "Zip entire project" for Source Files.  In this case, the lvproj file is included.  However, if I don't check that box and instead pick specific files to include, the lvproj file is not included.  

 

Sometimes, there may be installers and other drivers included in the project that I don't always want to include for size reasons during development. 

 

I'd like to be able to choose whether or not to include the lvproj file when making a zip.

I want to suggest Case Structure Selector comparison to dynamically changeable values.

Now Case Structure Selector compared to constant Boolean/eNum/Numeric/String values.

I suggest to compare the Selector input to External Inputs, for Example:

If String control wired to selector equal to C control then do the C tab content.

vladgu_0-1576400089344.png

 

I have experienced similar problems many times when I need to compare the selector to a dynamically changeable variable.

Of course, there are other solutions but I think my solution may be useful.

alternative flavor to the current text type control/indicator...

 

analog clock.png

 

 

Provide  Stop option if camera not found in IMAQdx open Camera. In loop condition not able to stop vi

cameranotfound.PNG

 

 

I know this idea has been coined already in A new head-controlled while loop, though it was closed becasue it didn't receive more then 4 kudos. That was 3 years ago and I didn't get any vote because I wasn't aware this post was out there. I'd like to re-open the discussion. Or for how long do we close suggested topics because at the time, there was not enough interest? It is not al that difficult and yet we are 2019 and NI still didn't solve this (as well as taking the square of a united input doesn't square the unit).

 

I have been programming a lot in LabVIEW and generally love it, but I also find it quite frustrating that you can not do the classic "check condition first, then run". I alos find the classic arguments not valid.

 

Some argue that it is easily solved using a case structure and while loop, which is not equivalent. One solution is to put the while loop inside the conditional loop, which forces you duplicate the conditional code and good programmers don't like duplicate code. (You could create subVI though, but that is also creating a lot of overhead for both the programmer as the program at run-time). Another solution, as some suggested here, is to put the case structure in the while loop, but then if you are indexing the output, you output a array with one element, whereas you probably wanted to output an empty array. In this case you can work with conditional terminals but that is also a lot of overhead and there is even a bug in LabVIEW when you output multidimensional arrays in this way that are empty and later on try to iterate over it, a for loop will execute the inside of the for loop, although the array is "empty".

 

I also find the argument that it is a rare case not compelling, I myself experienced this often while programming and the whole sense of a while (or conditional for) loop is that you don't know beforehand how many times you will have to iterate it. So it might be as well that you don't even have to iterate it a single time. That sounds reasonable, no? Otherwise you would use for loop. It is actually the other way round: the classic "do while" is a rare case (that's why textbooks first learn the while loop).

 

I also don't agree with the fact that the way LabVIEW works, it is not possible. I understand that you need a value for non-indexing terminals, but that would simply be not supported in this type of loop. A "check first then run" kind of loop would only work with iterating terminals (which can be empty) and shift registers (which can take up the value it was initialized to).

A seperate part of the loop's body must be reserved for the conditional code (for instance a rectangle that is fixed at the left underside of the while loop rectangle), just like in most languages where you have to write your conditional statement in brackets as part of the loop statement...

 

This type of loop would also solve the problem that you often have to delete the last element of your indexed array because the condition for which you probably wanted it, was no longer true (but the loop has excuted first after deciding that).

 

Lastly, it would give new LabVIEW programmers that come from any other language more familiarity with what they know. As this is reasonably a rather big flaw in LabVIEW (see argumentation above) that is some common and basic in other languages and you are likely to stumble on quite soon when you start experimenting in LabVIEW, it might just make you turn around right away, as it was almost the case when I first started programming in LabVIEW and didn't know how the rest of the language and environment is very beautifull and well designed.

Molte applicazioni VI sono utilizzate per testare oggetti simili, ma con i valori dei controlli (panel controls) diversi, adattati per ogni tipo di oggetto da testare.

L'idea è di sviluppare due funzioni, la prima che salvi in un file, ad esempio .INI, tutti i valori dei controls utilizzati nell'applicazione, in un file a cui è possibile assegnare un nome  diverso per ogni tipo di oggetto da testare.

La seconda permette all'occorrenza di richiamare il file specifico per il tipo di oggetto da testare e caricare nei controls i valori salvati nel file.

Tali funzioni dovrebbero essere molto simile a "Make Current Values As Default" e "Reinitialize Values to Default", solo che al posto di salvare i valori nell'applicativo li salva in un file.

I would like to see an option or VI that save / load the state of a VI and there SubVI's at a certain time (all controls I guess).

 

Background:

In the development of measurement software it is important, in terms of reproducibility of measurement results, to implement an option that save all scalable objects at a certain time (device settings also program settings) which depending a measurement.

 

Save program settings:

I know there is a way to do this by calling the VI reference and get the control values with property node and save them. But I don't think that's an accurate way because you have to manually do this with every SubVI's reference if you won’t to save them too.

Btw: in LabVIEW NXG, which I really like, it seems no way to do this because there is no 'Get Control' property node?!

 

Suggestion:

- two VI's which save/load all scalable program settings to/from file (hopefully in the standard data save VI Palette)