LabWindows/CVI Idea Exchange

Post an idea

Hi,

The CVI runtime engine calls the Windows API function SetProcessDPIAware() that tells Windows that the application is DPI aware in Windows Vista and later. This seems to be forced upon all applications built with CVI, whether they are actually DPI aware or not. Most applications built in CVI using the default tools are not going to be DPI aware out of the box, and setting Windows to another DPI setting than what the programmer used to create the UI will cause many graphical glitches and possibly make the application unusable. The purpose of this request is to suggest to NI that the CVI Runtime Engine not call SetProcessDPIAware() so that the programmer can handle (or not handle) DPI scaling as they see fit. If the programmer does nothing, the application will then, by default, be scaled using Windows DPI Virtualization. This is not optimal, but it would leave the application usable and looking like how the programmer intended.

This is per this discussion here:

http://forums.ni.com/t5/LabWindows-CVI/Forcing-DPI-Virtualization/td-p/3079742

Thanks.

Opacity on filled polygons

NI is not a C/C++ Editor-Debugger company. And, it will never be able to invest the man power needed to get there. NIs strengths are its Instrument UIs, its libraries, and it's visual application UI pieces. The LabWindows/CVI tool looks and feels like tools from the mid 90's (ie. like an old Borland C editor, but even less featured). It lacks the toolset found in VisualStudios, NetBeans, and Eclipse. And, it will always be behind.

The Verigy93k tester was like this several years ago. They wrote their own C/C++ editor, and it was at a mid 80's level. When a team was asked to rewrite the UI and bring it up to date, they made a novel choice (they recognized that they were not a UI platform / editor company), and they moved their product under Eclipse. Teradyne Flex did something similar a year or two later moving under Excel and Visual Studio. The thing is this, both companies realized that they could make more money focusing on their real strength. They added libraries and apis to work in the platforms framework, and changed/adapted the platform framework to work for them. ie. Teradynes Flex test tool does not say "Excel/Visual Studio", it says it is a Teradyne product based on MS Excel and VS. And, they have adapted the platform to their needs adding on the extra Windows/UIs/... to meet their needs. Same with the Verigy 93K.

In Teradynes case, they went back to the drawing board. So, we will ignore this (even with their success). In Verigys case, all their existing APIs worked in the new platform, and the user didn't need to change anything when they upgraded. But, suddenly the Editor and Debugger were up to date, with latest greatest features. It was a huge change overnight.

LabWindows really should make a shift to Eclipse. Keep your old legacy stuff at first, but working under Eclipse. Add in "Views" and "Tools" to supplement what Eclipse doesn't give you for free. And, remove unwanted or confusing plugins from the eclipse base. (This is what advantest did.) Leave in features that make Eclipse great, like error view, and the ability to have several "perspectives". And really focus the man power into making a product that will blow the others out of the water. NI has what it takes to make great Instrument editing/debugging windows in Eclipse. But, NI doesn't have the 1,000's of people and millions of man hours required to make an Editor/Debugger that will compare to the Eclipses/VisualStudios of the world. As a business they should focus on what will make them a differentiator, and reuse what is accepted and common.

Anyway. My 2 cents on how you could really improve LabWindows in a few short months. (Note: Verigy spent all of 9 months and 9 engineers on their C/C++ integration into eclipse... I know... I was there at the time.) If you took the LabWindows team, and a year or two... Imagine how much better of a job you could do.

Hello,

I have a very elaborate Front Panel, developed in LabVIEW 8.6, which I'd like to import into my LabWindows/CVI 2013 development environment.

The background is that the new company colleagues are very proficient in C and want to use LabWindows/CVI to re-program the current state of the software and maintain and update only using LabWindows/CVI in the future.

This would be very usefull, since it would save a lot of time and keep the naming of the elements in the front panel as-is. For the customers it would mean, having the same tool they are used to work with and receive much faster and better service when it comes to changes or additional functionality.

If there is already a way to do this I'd be happy to have a step by step guide.

According to the feedback from the forum, this still doesn't exist. (http://forums.ni.com/t5/LabWindows-CVI/Can-I-convert-a-LabVIEW-Front-Panel-into-a-LabWindows-CVI-User/td-p/3044003)

Changing parent panel

In CVI 2013 is option “Run -> Attach to Process…” and new is option “<< Running >> -> Detach from a process” during debugging, which is very good to debug TestStand sequence and CVI DLL, advantageous if I need to update CVI code and do not have to launch TestStand again and again after new CVI code is builded. Hovewer, to attach CVI DLL to a process is always necessary to do next steps: Run -> Attach to Process…, then select process from a list (seqedit.exe) and click OK. I would appreciate similar option as “Specify Executable to Debug…” or key shortcut to attach process directly to TestStand in one click or using simple key shortcut.

Beautiful tooltips

View All (2)

Size of UI Controls

This issue is that old that we all forgot about it...

But this thread brought it back to my attention and I'd like to suggest two improvements:

Setting the width or the height of a control does not always succeed because there are limitations concerning the minimum and maximum size.

Suggestion 1:

If a function fails it should return a warning. However, calling e.g. status = SetCtrlAttribute ( panel_handle, PANEL_RING, ATTR_WIDTH, 5 ) returns success (0) even though the width of the ring control will be much larger than 5 pixels. For checkboxes, the situation is even worse because checkboxes are drawn right aligned to a transparent rectangular frame. So calling status = SetCtrlAttribute ( panel_handle, PANEL_CHECKBOX, ATTR_WIDTH, 500 ) will result in a transparent drawing rectangle of width of 500 but with the checkbox size remaining at the default size. Since the checkbox is drawn right aligned to this transparent frame the checkbox eventually may disappear from the panel (setting the width to say 10000 will not draw anything).

Suggestion 2:

Complement the documentation, the idea is given below:

Constant: ATTR_WIDTH
Data Type: int
Description: The width of the control body in pixels.
Valid Range: 0 to 32767
Control Type Restrictions: Not valid for controls of type CTRL_VERTICAL_SPLITTER and CTRL_VERTICAL_SPLITTER_LS

For checkboxes, the minimum size is ... pixels, and the maximum size is ... pixels.

For ring controls, the minimum size is ... pixels.

...
LabWindows/CVI Compatibility: LabWindows/CVI 3.0 and later

Control Types: All

View All (3)

While editing the code, pressing Ctrl+Shift+U or selecting Right-Click+Find UI object jumps directly to the object identified in the code (either the control constant name or the associated callback name).

This works well if the control is on a single panel: the correct panel is shown in the working area of the editor scrolling through the file if needed. If the target control is on page of a tab control, however, the UIR editor opens in the upper left corner of the UIR file; actually the correct control is selected on the tab page, but if it is located out of the editor screen area in the UIR file you need to manually scroll right- and/or downward to show it.

Please correct it: it's not always obvious where the target control is located in the UIR file, wespecially if this one is rather complex, with several panels/controls.

View All (3)

Attaching controls to a splitter in the UIR editor can be a pain if the panel has several controls on it. I'll make an example using CVI example SendMail: trying to add a vertical splitter and attach all controls to it in order to rearrange the panel when the user resizes it. This is the original panel, you can see the vertical splitter in the upper right corner:

First of all, if several controls are selected, they overlap in the right panel of the editor in a way different from the original panel. Here you can see that the decoration indicated by the arrow overlaps two string controls that I'm not able to operate on to select desired attachment mode. This means that I need to proceed to attach controls in steps, hoping new controls added are not overlapped by previous ones. Alternatively I can move controls in the right panel to encover hidden ones, but this ingenerates confusion as controls are no more in the original position besides being a waste of time.

Second item: if selected controls are on the "wrong" side of the panel, they are all grouped (and possibly overlapped) on the closest boundary of the right window. See this example: Send and Quit buttons are only partially visible on the lower left corner of the right window and additionally they are overlapped (in the small box how they appear if I select one of them and move it upwards):

I suggest that this function is improved with these additions:

Honour the z-plane order of the original panel when controls are selected for attachment and moved to the right side
Maintain original controls position when moved to the right panel. Consequently:
Have both scrollbars enabled in Controls on the Splitter window in order to navigate to the controls; at present only one of them is enabled, whether vertical or horizontal depending on the type of splitter

Graph legend

Hi,

It would be handy at times to be able to get a string of a numeric control which represents the value exactly as it is displayed in the numeric control. For example if the control shows "123.456E+9" or then there would be some way to get that exact string (other than reading the value as a number then formatting it into a string, of course). I envision this could either be a new function call, or perhaps a non-settable attribute that can be obtained with GetCtrlAttribute(...) (the latter would of course benefit from being able to use GetCtrlAttributeLimited(...) ). Thanks.

At present, autoscaling works with respect to the full provided data set, i.e. if all data are shown on the graph.

If say the X axis is set to manual scaling such that only a subset of all data is plotted, autoscaling of the Y axis still considers all data even if they are not shown, see the discussion here.

Hence it is suggested to provide an additional auto scaling mode which considers only the data actually visible on the graph, say VAL_AUTOSCALE_VISIBLE_DATA, complementing the current VAL_AUTOSCALE which actually is a VAL_AUTOSCALE_ALL_DATA

View All (3)

I want to be able to do the following:

Right-click on a control on my user interface and select “Add Event Case to Control Callback” (if a callback function already exists)
CVI brings up a dialog similar to what you see at Code>>Preferences>>Default Events to select an event for that control
Check the box for one or more events for that control, click OK, then
Have CVI find the existing control callback function and add a case to the switch statement for each event I checked

If you haven’t written any code in the callback already, you can just change the default events and re-generate (replace) the control callback.

However, if you have already written code for one event case, the only way I can find to add an event case is to do it manually. I go to Code>>Preferences>>Default Events or use the Operate tool to look for the constant name of the event that I am interested in, then I go back to my code and manually type out “case EVENT_CONSTANT_NAME: break;” with the name of the event and hope I remember it correctly and spell it right.

CVI is all about minimizing user errors and reducing development time by, you know, not making you type things out yourself, so I think this functionality would be a useful addition.

LabWindows/CVI Idea Exchange

Give the programmer control over DPI scaling

Opacity on filled polygons

Make the change to Eclipse (or some other common framework platform)

provide a wondfull statusbar, just as a cvi control,not activex, and the new statusbar can be a container to add others in it's item.

can add progressbar, checkbox,radio... in table or tree cell?

can add progressbar, checkbox,radio... in table or tree cell?

Can I convert a LabVIEW Front Panel into a LabWindows / CVI User Interface File ?

Changing parent panel

Small improvement to automate debugging option in CVI 2013

Beautiful tooltips

Allow setting text attributes on multiple controls at a time

Size of UI Controls

Correctly show control on a tab page when coming from source code

Individual support of major / minor grid line attributes

Improvement needed on "Attach controls" function for splitter controls

Graph legend

Ability to obtain the value of a numeric control as a string

Provide new scaling mode (VAL_AUTOSCALE_VISIBLE_DATA) for SetAxisScalingMode

Add the functionality to "Add Event Case" to existing control callbacks

Show Completions For #include Headers