LabWindows/CVI Idea Exchange

Hello,

Frequently I have the need to debug array elements, such as parameter [ 1 ].

Right now, the data tooltips only shows the address of this array, but not the individual value. For this I have to open the variable view and scroll to the element of interest. This is extra effort...

Hence I suggest to also show the value of the specific indexed element in the data tooltip, e.g. parameter = 0x00611990; parameter [ 1 ] = 2.0

Thanks

Hello,

searching through the C code for specific controls first and foremost requires the knowledge of the control's name... If there are some hundred it may get difficult to remember and thus I typically have to check the UI for the constant name. Clicking on the control shows its name in the status bar, a welcome feature, but unfortunately I cannot directly use this text for searching...

What I suggest is allow copying this status bar field using CTRL+C; then it's possible to switch to the C code, press CTRL+F and CTRL+V... (The property browser is not really useful here because it only lists 'NUMERIC_7' and misses the associated panel)

Another, even more powerful feature would be to add a right click popup menu either to this status bar field ('Search C code for this constant') or to the control popup itself: Besides 'Generate control callback' etc. I'd like to see another entry 'Find control in C code'

Thanks!

Hello,

this is a minor issue but still it can be very inconvenient... Very inconvenient because it almost always happens to me that if editing a menu bar I inadvertently mess it up. This is because if one is inserting a new item or child item, after pressing the 'Insert Item' or 'Insert Child Item' button the active control is set to 'Constant name', see below.

But I am never editing the 'Constant name' but always the 'Item name' (and callback function, modifier key...). Hence I almost always start typing the item name until I realize that I was editing the wrong field.

So my suggestion is to consider changing the active control after one of the insert buttons has been pressed to 'Item name'.

Summary:

Hovering over the breakpoint diamond, a tooltip should display the breakpoint condition.

Description:

Useful breakpoint information, such as the breakpoint condition, line number or hit count could be displayed when hovering over the breakpoint diamond in the source editor. Otherwise, you would get this kind of information by looking at the breakpoint in the Breakpoints Window or the Edit Breakpoint Window.

If a panel is made part of a tab (InsertPanelAsTabPage) or if a panel handle is obtained from a tab (GetPanelHandleFromTabPage), there are some restrictions as to how you can use that panel. Some of those restrictions could be lifted if the panel knew which tab it belonged to.

I suggest the addition of the following (or similar) attributes:

GetPanelAttribute(Panel, ATTR_PANEL_PARENT_TAB_CTRL, &TabCtrl);

GetPanelAttribute(Panel, ATTR_PANEL_PARENT_TAB_INDEX, &TabIndex);

And of course you can already get the parent panel with:

GetPanelAttribute(Panel, ATTR_PANEL_PARENT, &ParentTab);

So, now that a panel knows the tab it belongs to, some obvious associations can be handled by the UIR library:

• Calling DiscardPanel should, internally, call DeleteTabPage instead of the current undefined and illogical behavior
• SetActivePanel should do a SetActiveTabPage instead of the current buggy behavior
• SetPanelAttribute(.., ATTR_DIMMED) should do a SetTabPageAttribute(..., ATTR_DIMMED)
• - etc...

This would allow the user to select at runtime if he wants a Multiple Panels application (MDI) or a Single Panel/Multiple Tab application (tabbed SDI) and almost no changes are necessary to the code.

Summary:

Improve the Breakpoints Window, so that breakpoints can be more easily managed.

Description:

1. Change the Breakpoints Window, from a modal dialog to a dockable window (similar to the Watch Window). Debugging can be more easy this way.

2. Allow breakpoints to be grouped, disabled/enabled and edited in user defined categories. This allows users to easily collectively manage several breakpoints at a time. It also helps the user to logically group breakpoints, depending on various issues issues that he might be working on.

3. Breakpoints could also be sorted from a pop-up menu by filename, line, hit count, etc.

Summary:

Quickly find and open a file in your projects by typing in substrings of the name of the file.

Description:

Implement a quick way to find files in a CVI project, by typing substrings of the filename.

A certain keystroke combination should launch a popup-dialog (similar to the picture below), displaying the user a list of files that contain certain substrings. This helps significantly when having to deal with large projects containing many files.

Summary:

Display more struct member information during source editing and during debug.

Description:

While editing source code, CVI only displays the struct members, but no information regarding the type of the member (or declaration information, line file and line).

Add a tooltip to the right of the pop-up displaying the struct members in the source editor to display this information. Similar to this picture:

Also add support for displaying nested structs and even display the member values while debugging, in form of a tree, when execution is suspended (CVI currently only displays the memory address of that struct variable).

Summary:

Implement and add easy access to multiple clipboards inside the CVI ADE.

Description:

The CVI ADE (at least the source editor) should keep the most recent sequences of text that had been copied (Ctrl+C) to the clipboard.

It should also allow access to the multiple clipboards through some pop-up menu, displayed at a certain keystroke combination.