LabVIEW Idea Exchange

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

Certain keyboard shortcuts are standard across operating systems and applications. When doing text entry, LabVIEW implements ctrl-c, crtl-v, and ctrl-arrow keys for text selection and manipulation, but does not allow ctrl-a. I have implemented this for string controls. 

 

I would like to see this be the default behavior for all text entry. 

 

In LabVIEW, ctrl-a currently selects all objects on the FP or BD. But when the cursor is in an active text field, ctrl-a should select all text in that field. This should include strings, tables, graph labels, control labels and captions, numeric controls and indicators, free labels, and so on, and should work in development and at runtime.

Online version of LabVIEW 2024 Q1 Help -> LabVIEW Help menu item only points to the LabVIEW Programming Reference and NOT to LabVIEW User Manual.  This means that searches for topics like: "LabVIEW Style Guide" or "Memory" or "Performance" inside LabVIEW do not point to these topics inside the LabVIEW User Manual.  Currently to access any of these topics it is necessary to do an internet search which yields results in the LabVIEW User Manual.

The title says it all: The property dialog of controls should allow inspecting and changing the default value.

 

Here's how it could look like.

 

 

Sometimes I wand to re-define a default value without actually changing the current value.

 

current steps

  • copy the current value elsewhere
  • enter the desired default value
  • right-click...data operations...make current value default
  • restore the original value (could lose data in case of DBL!)

After implementing the idea

  • right-click...properties...enter default value...OK.

 

 

 

Hi all,

 

What I'm asking for is an optional indication of reentrancy in the context help window.

 

contextHelpReentrancyIndicator.png

 

 

This would save the user from having to open VI Properties on several VIs, and would be particularly useful when viewing the VI hierarchy.

 

 

I realize that Greg Freeman suggested something similar.  My intent here is to narrow down several ideas from that conversation down to a single suggestion.


(I hope I still didn't manage to post a duplicate. Apologies if I did.)

 

Thanks,

 

Jim

Currently text in an "unbundle by name" node is centered. This makes for poor readability when there are several elements being unbundled.

 

Centered.png

 

I think that changing the justification from center to left does improve readability.

 

Left Aligned.png

 

Note 01: This apply to bundle by name as well.

Note 02: implementing this idea my gave us this one for free.

I would be surprised if this is not a duplicate but I was unsuccessful finding it.

 

The subject says it all. Simply add a scrollbar to free text labels. I sometimes use a string constant for free labels simply because they can have a scrollbar.

 

scrollbar.png

The idea is quite simple to implement, I suppose.

 

Dimensions-tipstrip.png

 

 

 

 

 

 

Two main benefits:

 

1. allows you to know the exact size in pixels that the front panel will get at runtime, while the manual resizing of the FP occurs.
This feature should take in account VI's Windows Appearance options (Window has title bar, Show toolbar when running, ... etc). It helps you to set the FP size for the (different) screen on wich the program has to be run.

2. this feature can help you to set the BD size for the smaller screen on wich you know you'll have to edit the program.

Up to now you can only set a minimum FP size, and use it as a sort of "pixel size reference". However this is the internal net size of the panel, toolbars and title bar excluded, and the final setting is a bit tricky. You can also programmatically change the FP size, but this is of little use, if you don't want to risk that some control disappear out of the panel boundary.


The second benefit is only for those of you that use LV on different PC (Lab and laptop, for instance) like me...  and, like me, hate having to scroll the BD for editing it :-). Usually I set the BD size to the maximum possible dimensions of the smallest screen I use.

 

 

Cheers

Windows 10 now handles long file paths although it has to be enabled with via various possible registry or group policy edits. Windows applications have to opt in. LabVIEW source code should be able to utilize long file paths.

Today, when you change a numeric control not to use the default limits, it allows you to enter your new limits, but it doesn't actually respect them unless you change the response control on the right side, which can be easy to forget.

 

I propose that the default value of the controls should be "Coerce", not "Ignore":

 

Default to Coerce.png

 

 

This makes sense, because if the user unchecked the check box, they probably want the limits to coerce and in case they don't, the limits already default to the maximum range of the data type, so they can't be coerced unless the user changes the limit value anyway.

 

I would also suggest considering that if the Response control is set to Ignore, the value should be disabled and greyed, to inform the user that changing it won't actually do anything. I would suggest getting rid of the Response control entirely, but it can be relevant if you only want to change some of the limits.

 

I would also consider changing the coercion of the Increment to Nearest by default, since it's probably the most common option, but that could be debated.

IMO, the Diagram Disable Structure causes bugs, because the output tunnels of the Diagram Disable Structure are set to "Use Default if Unwired", and the default values are very often not desireable, as can be seen in the screenshot, below:

 

 

See this blog article, for more details:

 

http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/

Drawing on an idea from Visual Studio... If I have a hierarchy of VIs in memory or a project open, it would be useful for navigation to have a shortcut key that brings up a quick dialog where I can type in a full or partial file name and hit Enter and that named VI will be brought to the foreground. This way you don't have to care about path on disk or navigating to find the VI in the VI Hiearchy or project tree. The dialog would just know about all the VIs currently listed in your project or currently in memory and open the path that matches the filename. 

 

Unlike MSVS, LV has the problem of VIs with identical file names in different libraries. Tab name completion (type a bit of the library name, hit tab to finish that name, then type part of the desired file name) could solve this. Alternatively, if you type in a filename shared by multiple VIs, you get a second dialog to choose  which one you want (like the selection dialog that appears when you double click on a dynamic dispatch subVI node). 

 

LV also has an issue with the same VI being loaded in multiple application instances. I suggest that the shortcut key always take you to the VI in the current app instance and fail if the VI is not in the current app instance (and by current I mean whatever app instance the VI that currently has focus is in).  It should never open a VI in another app instance as that can lead to confusion about what is being edited... to change current app instances, you would use the project tree to deliberately open the VI, just as you do today. 

 

My first instinct for the shortcut would be ctrl+shift+o because of its relationship to Open, but given that this might be frequently used, having a shortcut that doesn't involve two modifiers would probably be preferred by most people. MSVS uses ctrl+/ for this accelerator.