LabWindows/CVI Idea Exchange

Post an idea

Hi,

I'd like to suggest another command strengthening the table control: Because tables can be used also for documentation, it would be helpful to ease the printout of table controls by a dedicated command.

The PrintTable command should not print scrollbars, and it should include

- two integer attributes for the number of columns/rows that shall be printed per page

- a boolean attribute indicating if tables too large to fit on a page are split first horizontally or first vertically

- an integer attribute specifying the font size

- a boolean attribute if the header shall be repeated on subsequent pages

- a boolean attribute if the frame lines are printed or not

- two boolean attributes if the vertical/horizontal grid lines are printed

- an integer attribute specifying the thickness of the frame lines

- the option to generate graphic files (png, jpg): if several pages would be printed this should result in several graphic files

Right now these goals can be achieved only by creating a second, hidden table control with the requested attributes which is then filled programmatically.

View All (3)

View All (4)

In CVI there are two kind of buttons:

the classic text button (i.e. a button with a text where you can't insert an image)
the picture button (i.e. a button with an image where you can't add a text)

But if you try to design a modern interface (like the MS Outlook 2010 ribbon, for example) you need a button where you can have both

an image statically or dynamically loaded from file)
a text string localized through the UIR localizer

Even in the new CVI 2010 SP1 there isn't a convenient workaround (see here, for example).

In LabVIEW, otherwise, this kind of buttons can be easily created.

An interesting feature would be also a setting to set the text position referred to the picture (top, bottom, left, right).

View All (3)

Hello NI,

during program development and debugging typically there is more than just the source window visible, i.e. the lower part of the screen is used by the find or the build output window. Now, if I switch to a different tab/window to edit the UIR file, this build output window will still be there and take valuable space, although it is completely useless for editing the UI. If I close it, it will remain closed even if I switch back to the source code.

I would prefer that 'context sensitive' wndows such as 'find results' / 'build output' ... only show up if meaningful, while they are automatically hidden if not needed, i.e. when a UIR window is displayed, and automatically redisplayed if the source code window is back.

Thanks for possible consideration,

Wolfgang

View All (3)

View All (4)

Would it be possible to allow ".." to be used as a "Custom Copy Directory" in the "Target Settings" dialog box (for dynamic link library projects)? Or in other words, I would like the ability to specify that the Custom Copy Directory should always be one up from the project directory. That way this functionalty won't break when I rename the directory or move the project between computers where the complete path is not the same. A similar thing would also be handy in the "Specify Executable to Debug" dialog box. Thanks.

View All (3)

Currently, there is no way to access the historical data on a stripchart. The only way to manage this data is to maintain a separate buffer and update it whenever you add data to the strip chart, which is inefficient and tedious. Accessing data is possible for graph controls using the data attribute:

GetPlotAttribute (panel, PANEL_GRAPH, plotHandle, ATTR_PLOT_XDATA, &data);

Something similar should be implemented for the strip chart, either as an attribute in the getTraceAttribute function, or as a standalone function (getTraceData, etc.)

Editor upgrade

This issue has been discussed in other threads:

When a stripchart is horizontally resized, the X-scale range can't be changed, so that visible data in shrunk or stretched to the new dimension. But this behavior is not so useful.

It would be better if resizing the chart changed the X-scale accordingly, so that a larger or shorter period would be displayed.

But if you set ATTR_POINTS_PER_SCREEN parameter all the data history is cleared, so that it's impossible to resize the chart.

I think that resizing a chart in the way I described is a quite common need, so I suggest to implement ATTR_POINTS_PER_SCREEN in a way that doesn't clear the whole data history.

ClearStripChart() should be the only function that clears the chart.

View All (1)

The JIT debugger option in CVI 2010 is a nice step in the right direction, but only being able to debug builds that were compiled in "Debug" mode pretty much defeats the whole purpose of the idea. Debug builds are much too slow to be used in production and on my machines, if I ever use a Debug build, it probably already runs under the debugger anyway! Seeing that CVI is not even an optimizing compiler I cannot understand why release builds cannot be properly debugged.

Thing is, the crashes in production are the important ones that I absolutely need to be able to investigate, and CVI does not provide ANY assistance in this area apart from being able to at least generate a MAP file. This is what I currently have to do: I have included code in my application that creates a memory dump and sends it to me when the application crashes or hangs. This dump I can then load into WinDbg and with a few tricks I can at least import the CVI MAP file to get some functions names in the stack traces, but that's it, all investigations have to be done on the assembly level. To quickly decipher stack frames, e.g. to have a look at local variables, I often even have to throw my OWN code into a disassembler (IDA Pro)! I'm really glad that this way I am now at least able to debug most crashes at all, even when they happen far away in a different country, but this aren't the 80s anymore and you can probably imagine that this process is hard and time consuming and very much annyoing. With code compiled in VC on the other hand I can load a MiniDump and have a look at the stack trace, variables and code on the source level without much hassles.

Some ideas that could help:

- Let me (JIT) debug release builds

- Let me load MiniDumps into the debugger or

- create PDB files that I can use together with a debugger that can load MiniDumps (WinDbg, VS)

- Let me not only use an external compiler but also an external linker that generates PDB files for release builds (I don't like this solution as I use C99 features VC does not support, but I'm desperate here)

Okay, rant over for now, I think I really needed to vent a bit. Thanks for reading this far 😉

All the best, Marcel

A tree control can be used to implement radio button controls;

in this situation you can't completely dim one of the items (so that it is grayed and the user immediately sees it is inactive) because the function SetTreeItemAttribute() doesn't allow ATTR_DIMMED attribute.

You can dim the item label using SetTreeCellAttribute(), but the check box stays active (see this discussion).

The EVENT_MARK_STATE_CHANGE can be swallowed, but the check box has the aspect of an active check box, even if nothing happens when you click over it.

I suggest to add the attribute ATTR_DIMMED to SetTreeItemAttribute() so that the whole item can be dimmed (its check box too)

View All (2)

View All (3)

I added the tab control into panel to my project. Overtime, I added 20 items into the single Tab Control. But since were so many items in the tab control, I decided to re-arrange items (indexes) in the tab control by either moving them left or right depending on the alphabetical order. But here is my problem.

Since I re-arranged the items (indexes), the indexes have all changed for all the items. Now I have to go everywhere the function GetPanelHandleFromTabPage is called and manually update the index numbers to match panel handles for the index. There are 20 different places where this could occur. The number of items (indexes) on the tab control could grow even more and may have to be re-arranged again in the future. Just a big pain.

Suggestion for improvement: Provide a another function that can obtain the index of the item on the tab control dynamically. This could be done by using the "Constant name:" issued in the edit tab panel of the edit tab control. So if the items (index) inside the tab control are re-arranged then the index value for that item is carried with the new index value.

Also the index would be included in the header file generated by the panel editor for CVI so that now the index value can be used thus eliminating the hard coded the index value.

View All (4)

LabWindows/CVI Idea Exchange

PrintTable (to printer or to graphic file)

Add an attribute to set vertical alignment for label text

Browse .c window: Allow to copy content from browse window result

A new "Picture and Text" Command Button

Enhancements for LabWindows/CVI Real-Time

Implement ATTR_FRAME_COLOR for more lab style controls

Launch proper CVI version upon double clicking a CWS (or PRJ)

IDE: adapt visible windows to contents

EVENT_SORT for table control

"Custom Copy Directory" improvement idea

Increase the size of the "Select UIR Constant" dialog box

add cell type 'check box' to table control

Add a Method to Access Strip Chart Data

Editor upgrade

Stripchart: change X-scale without clearing data

Proper post mortem debugging support

ATTR_DIMMED for SetTreeItemAtribute()

Tree Control: Copy Selected Rows to Clipboard

remove editor line limit

CVI Function: GetPanelHandleFromTabPage has limitations