LabWindows/CVI Idea Exchange

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

I made this suggestion some time ago - but had it combined with another idea. Part of the suggestion was implemented so I am trying to revive the remainder here... Smiley Wink

 

For me it would be useful to have at least two different line types for the separator in ring controls, i.e. not only a solid line, but also a dashed (and possibly a dotted) line: This would help to group different entries into groups (solid line) and subgroups (dashed line). The idea would be to provide some more escape codes resulting in the different line styles.

 

Thanks.

In earlier versions of CVI source files needing compilation were marked in a different color, unfortunately this feature has been removed in CVI2013. The suggestion is to re-introduce this feature...

 

Benefits:

Changing an include file immediately shows affected source files

It's always clear how time-consuming it is pushing the RUN button, i.e. if there are files *and how many) to be compiled first

Hello,

 

when using the two subwindows of the source code editor I frequently need to scroll both windows the same way because my screen isn't high enough Smiley Wink This means that I scroll down one window, switch to the other window, and scroll again.

 

It would be much more convenient having the possibility of simultaneously scrolling both windows. I imagine that pressing the SHIFT key modifier would allow for synchronously scrolling both windows while scrolling without the SHIFT key would show the present behavior.

 

What do you think? I think it's no big deal of implementing it Smiley Wink

Some years ago I proposed this idea that has been partially implemented in CVI 2013.

For this reason I'm going to propose the third point of the original idea again:

 

  • the current function where the caret is, displayed in the toolbar. It will be nice if you use a combo so that the user can jump to a different function with a simple mouse click (see attached image)

 

I use this feature in an open source C/C++ editor (Code::Blocks) that I use for other projects, and I think it's really useful to reduce the coding time.

CVI currently provides a way for alligning controls (using the dotted matrix). But, with large UIs, this method is inefficient and users must align controls over large distances by hand from the Property Browser. I propose an upgrade that would help users achieve alignment by drawing lines that unite the control being moved and any other control that happens to be close to alignment with it (Figure 1).

This feature would increase usability and productivity (which seems to be decreasing by increasing the size and complexity of UIRs).

 

 

Visual Studio's alignment for the C# Interface Editor

Figure 1: Control alignment in Microsoft's Visual Studio 2010, for the C# interface editor.

Tables are often used to display test results organized in columns, which means the user very often has to search a particular column for a specific value. At present the "search vertically" checkbox is not checked by default in Find in Table Cells dialog, which means the user has to explicitly select it otherwise the search could locate the wrong cell.

 

What I would like to have is the ability to programmatically set the relevant default options on the dialog before it is shown. With this I mean:

  • Show/Hide/Dim some elements
  • Preset some value (like checking the Search Vertically option)

 

FindInTable.png

 

( Tested with CVI 2012SP1. Not yet installed 2013 )

  1. Open a project
  2. Go to Options
  3. Select Build Options...

 

If all the "C Language Options" are unchecked

Checking "Build with C99 extensions" check box should automatically check the "Require function prototypes" check box. If not, if a function is not prototyped before invoked then the compiler will generate an error (which is good and safe for the user).

This idea is similar to the fact that one cannot check "Enable OpenMP support" until C99 option is checked

 

Later on, if a user load a project with C99 support set but "Require function prototype" uncheck I guess CVI should let him know that it will set the "Require function prototype" for him in the Build options (simple dialog box for example).

 

Regards, Philippe

 

Capture.PNG

Not a big deal in my point of view...

 

  1. Create a new workspace
  2. Create a new .c file
  3. SHIFT F5
  4. Give a name to the c file when needed
  5. Make sure it does not have a capitalized first letter (dummy.c for example)
  6. CVI then create dummy.cws, dummy.prj and dummy.exe

However, the name of the project in the workspace tree has a first letter capitalized (upper case)

See below the screen capture

 

This may not be what the user want to see

This is purely cosmectic since opening the cws or the prj file with a text editor one can see the workespace/project use the correct name (no upper case letter)

The only solution so far is to manually go to Edit then "Project.." and modify the project label

 

Does it make sense?

  1. Yes because the user may have naming convention for project names, project hierachy on disk etc...  and he may want to be sure to see thoses reflected in the workspace tree 
  2. Yes because by default CVI should not act in the name of the user. If the user want upper case letter for the project name then he should type it otherwise CVI should simply follow the user instructions (and not add upper case letter at the begining of project filename)

 

Regards, Philippe

 

 

Capture.PNG

 

Bonjour,

This is a minor thing (I mean aesy to improve)

 

On the Welcome page when you click the "Browse" folder icon the file dialog looks for .prj by default :

 

Capture.PNG

I believe it make sense to look for "Workspace" by default

Doing so one can find out his workspaces directly (NewSamples.cws for example) rather than get the Open File dialog box on screen, then select workspace in the type list then look for his .cws

 

Does it make sense?

Yes because even single project based project are included in a workspece so it does not change anything for the one looking for "simple" project

Yes because more and more CVI users have more than one project in a workspace and so changing the default behavior will save time (1 or 2 seconds) for most of us.

 

Regards, Philippe

 

The place where tooltips are needed most is on menu bars, since the text you can put there is fairly limited and right clicks can not be used to provide help as can be done with buttons. I would love to see this added to CVI soon.

add the 'view control callback' to menu items from uir editor

saves alot of time for searching the CB manualy in huge projects

The option tooltip is very good feature what is the problem is it is only for the controls. If I want to show tooltip for listbox then it is fine but what if someone wants to show tooltip for active rows. It simply doesn't. 

 

This is very basic but one of the disadvantage of labview over .NET.

 

This needs to be fixed

As discussed here, distributing the code of

 

#include <ansi_c.h>
int main ( int argc, char *argv [] )

{
    printf ( "%s", "Hello world" );

 

generated in CVI2013 results in a distribution kit of 74 MB minimum...  Using the NI default settings results in 219 MB...

 

Yes, I do have TB drives, but I dislike bloated software.

Hello,

 

usually I work on my projects on two different computers (home/work or development/lab). I would like to see a possibility to more easily move my project back and forth, say by providing two new menu commands

 

File / Import Project and File / Export Project

 

I imagine that the Export command generates a zip file consisting of all files required to build the executable (and a distribution) and also exports the editor preferences (probably without the window positions because different computers may have different screen resolutions) etc. The Import command then should load the *c., .cds, .cws, *.fp, *.h, *.prj and *.uir files, import the editor settings, adjust the library menu and load any instruments.

 

Thanks!

So far the documentation is written line by line with a tag at the begining of each line. See below : 

/// HIFN Document your function here.
/// HIFN You may use multiple lines for documentation.

 

It could be nice to add a tag attribute that helps to define regions (or blocks) of documentation. See below :

/// HIFN BEGIN
//  Document your function here.
//  HIFN You may use multiple lines for documentation.
/// HIFN END

 

Once done this would help to copy/paste large section of existing documentation. Regarding the "// " that need to be added I believe that a macro or a new editing option ("comment multiline" or "comment selection" like in VBA) could do the job 🙂

 

Regards, 40tude

 

 

So far there is no way to take advantage of the CVI  style sheet when embedding HTML tags in the documentation of our functions 

The situation is as follow : 

1 - If the user does not use HTML tags every thing looks good BUT, for example, there is no way to display correctly a sample source code as it is done in the documentation of LoadPanel for example (see below). Same thing for the icons and other cool stuff available in "../cvi2013/bin/libref/tooltp.css"

 

Capture.PNG

2 - On the other hand, if the user use HTML tags in the function documentation then the display look "weird" and there is no easy way to improve the display.

 

My proposals

1 - Alow the users to leverage the .css file that come with CVI. This mean document/explain the style and the ressouces available (icon etc). This also mean that when the users embed HTML tags in the documentation then the help should include the CVI .css file and then the user documentation (like it is done for the CVI function call documentation)

2 - Another option could be to create a new documentation tag that help users to describe their own .css file. The problem here is that it would break the consistency within the documentation. I prefer option one.

 

I hope its understandable... 🙂

Regards, Philippe 

As discussed here earlier I am using tooltips that show 'dynamic' information, e.g. the permitted data range of the respective control, available user actions..., These frequently depend on several other controls and parameters.

 

Right now, all other affected controls etc. need to call a function to re-build the tooltip text, and to more than 90% this is wasted effort because the tooltip text is changed again before it may get displayed...

 

Thus I would like to suggest a 'dimmer callback', similar to the menu dimmer callback. This 'tooltip dimmer callback' should be called just before the tooltip is going to be displayed, allowing to build/update the tooltip text only when needed.

 

Thanks

Hi.  I find occasionally that it would be handy to be able to add items to the event que through the debugger.  Like, for example, to call a callback function as if the user had interacted with the user interface.  This would be especially handy for remote debugging, where I could add in an item in the que as if a button had been pushed on the user interface without having to physically walk over to the debuggee and push the button on the screen.  I'm not sure the best way to implement this, and I can picture some pretty sophisticated interfaces.  However, something simple could be perhaps a screen like the function panel for CallCtrlCallback(...) where I could enter in the Panel handle, Control ID, Event, etc. and have the event added to the event que?  Thanks.

The functions available today are OK in terms of functionality but limited in terms of syntax/grammar

 

For example : 

  • No support for multiline patterns
  • No support for '\s' in patterns
  • No support for [:alnum:] in patterns
  • No Posix conformance (ISO/IEC 9945-2:1993 for example)
  • No way to select among various syntaxes (grep, awk, ECMAScript...)
  • At least the ECMAScript grammar should be fully supported

 

I would like to propose to change the Regular Expression compiler with a brand new one

Keep the existing API (but support much better grammar)

Extend the API of the current intrument driver if needed or if it make sense (a Find/Replace function could be a nice for example)

 

 

Philippe

As discussed here, the new and nice auto indent feature does not always work consistently. I suggest to improve this:

 

  • at present auto indent considers the first 40 characters of a line only; if indentation is later, say at column 44, auto indent fails. I suggest to loosen this restriction and consider up to 100 characters
  • at present, different comment styles are treated differently. Although /* */ is THE valid C comment, auto indent can be configured only for the // style comment, it ignores this setting for /* */ comments. I suggest to treat both types of comments the same way

Thanks!