Quirks/bugs in CVI

[Jamie Fraser]

Hi,

I have a few comments on CVI 6.0 that I want to make to ensure these quirks/bugs might be fixed in the next release. It might be that some are deliberate but I would welcome further info if that is the case.

1) EVENT_VAL_CHANGED
This event is generated by numerics and table cells when the user edits, but does not actually change the original value. This is irritating as a trap has to be written to test for an edit but no actual change from the value on entry. Worse still is the generation of EVENT_VAL_CHANGED when the up or down arrow is pressed whilst editing, but the increment value is set to zero. Again a specific trap has to be written.

2) It would be useful if an attribute could be set in table controls to specify the movement of the active cell when Enter is pressed. The default of move down one row is often not what is required.

3) The generation of events in tables before the user edited cell value is accepted by the table and hence the value being retrievable by GetTableCellVal() requires use of PostDeferredCall() which again is awkward.

4) Some of the table specific functions like InsertTableRows() would be better if they were tolerant of passing zero as the number of rows to insert parameter.

5) RecallPanelState() does not set table controls to the same dimensions (rows x cols) as when SavePanelState() was called. I can't think of a case where you would not want the table controls to auto-size.

6) Calling SetActiveTableCell() from within a callback seems to swallow any outstanding events. e.g. if SetActiveTableCell() is called from within a callback case EVENT_KEYPRESS, EVENT_VAL_CHANGED & EVENT_COMMIT are swallowed. Is that normal/unavoidable?

7) If only one cell in a table is selected (i.e. when a cell is highlighted but not in edit mode) GetTableSelection() does not return what I would expect.

😎 Wouldn't zero based rather than one based referencing of table rows and cols be more useful?

9) Halting execution using Ctrl+F12 when more than one thread is running causes blue screen in Win 2k Pro and Fatal Error in XP.

Look forward to any comments.

Regards

Jamie Fraser

[JuanCarlos]

Jamie,

Here are some answers to you comments on CVI I'll get the suggestions to the right people to be taken into account for future releases.

1) EVENT_VAL_CHANGED

According to the CVI help file this "event is generated continuously while the user is performing an ongoing action which results in the value of a control changing". Basically you'll get this event when the user is modifying the control whether or not he submits a new value. I guess it would be nice not to have an event generated when the increment value is set to 0. As an alternative you can hide the up/down arrows when you don't want events to happen.

Also you can use the EVENT_COMMIT event to get an event only when the user is done editing the control. It can save you one of the traps.

2) Enter Key in Table control

I'll file a suggestion for this, I think would be useful. There is a document on this with the workaround, but it would be useful. (http://digital.ni.com/public.nsf/websearch/6DBDBBF27ECB95CA862569F200583D0F?OpenDocument)


3) Event processing and PostDeferredCall().

This is due to the way the events are processed by the table control. the table uses the user event to assign the active cell; so the user event gets called before the event is processed by the table control.



4) InsertTableRows() with 0 rows.

I gave this a try in CVI 7 and I was able to insert 0 rows to a table with no Run-Time Error or a row being inserted. I have not tested this in any other versions.


5) RecallPanelState() does not set table controls to the same dimensions (rows x cols) as when SavePanelState() was called.

The RecallPanelState() currently saves only the values of the controls, but not the properties. It is a very good suggestion to include the row/column info in the panel state.


6) Calling SetActiveTableCell() from within a callback seems to swallow any outstanding events. e.g. if SetActiveTableCell() is called from within a callback case EVENT_KEYPRESS, EVENT_VAL_CHANGED & EVENT_COMMIT are swallowed. Is that normal/unavoidable?

I'll give this a try and let you know how this goes.


7)GetTableSelection() does not return what I would expect.

This is because a single selected cell is not considered to be a selection, in the function help you can see that they stated this, there is always an active cell, but not always a selection.


😎 zero based rows and columns.

I think this is done to be more user friendly. Most Spreadsheet applications are 1 based.


9) Halting execution using Ctrl+F12.

I'm running here Windows 2000 and did some testing on this. I was able to run applications with several threads on it and then halt the execution without any crash or error. I think this will have to do more with some Hardware operations taking place. To generate a system crash in a Windows NT/2000/XP you need to be in kernel mode, a CVI application without any HW access is not likely to be doing operations in kernel.

I hope this helps, let me know the comments that you have.

Regards,

Juan Carlos
N.I.

[Jamie Fraser]

Juan,

Thanks for your comprehensive answer. I have additional comments as below:

1) EVENT_VAL_CHANGED
Although the GUI arrows can be hidden as you say, I think I am right in saying that the keyboard cursor arrows still operate. I personally feel that EVENT_VAL_CHANGED should only be generated when the value is changed and committed to, but take your point that it might still be useful to generate it during a user edit each time the value changes.

3) Accepted. But could there be an attribute that allows the current cell value to be obtained at any point during an edit?

4) I am using CVI 6.0 and if break on library errors is on it definitely breaks if zero rows are added.

6) I'll be interested to learn your findings.

7) Does this method fu
lly follow the MS recommendations (dare I say!). e.g. in Excel you can cut and paste a single cell or cell range in the same way which suggests that a single cell that is selected (but not in edit mode) is treated as a selection with width 1 and height 1. Personally I would find this more useful and consistent.

😎 Fair enough.

9) I will test to see if the crash happens if no DAQ is active (but I think it does). Halting execution does not cause the crash, it is when full edit mode is entered after the halt that the crash occurs.

Thanks for the continued world class support.

Jamie

[Jamie Fraser]

Juan,

Thanks for your comprehensive answer. I have additional comments as below:

1) EVENT_VAL_CHANGED
Although the GUI arrows can be hidden as you say, I think I am right in saying that the keyboard cursor arrows still operate. I personally feel that EVENT_VAL_CHANGED should only be generated when the value is changed and committed to, but take your point that it might still be useful to generate it during a user edit each time the value changes.

3) Accepted. But could there be an attribute that allows the current cell value to be obtained at any point during an edit?

4) I am using CVI 6.0 and if break on library errors is on it definitely breaks if zero rows are added.

6) I'll be interested to learn your findings.

7) Does this method fu
lly follow the MS recommendations (dare I say!). e.g. in Excel you can cut and paste a single cell or cell range in the same way which suggests that a single cell that is selected (but not in edit mode) is treated as a selection with width 1 and height 1. Personally I would find this more useful and consistent.

😎 Fair enough.

9) I will test to see if the crash happens if no DAQ is active (but I think it does). Halting execution does not cause the crash, it is when full edit mode is entered after the halt that the crash occurs.

Thanks for the continued world class support.

Jamie

[Jamie Fraser]

Juan,

Thanks for your comprehensive answer. I have additional comments as below:

1) EVENT_VAL_CHANGED
Although the GUI arrows can be hidden as you say, I think I am right in saying that the keyboard cursor arrows still operate. I personally feel that EVENT_VAL_CHANGED should only be generated when the value is changed and committed to, but take your point that it might still be useful to generate it during a user edit each time the value changes.

3) Accepted. But could there be an attribute that allows the current cell value to be obtained at any point during an edit?

4) I am using CVI 6.0 and if break on library errors is on it definitely breaks if zero rows are added.

6) I'll be interested to learn your findings.

7) Does this method fu
lly follow the MS recommendations (dare I say!). e.g. in Excel you can cut and paste a single cell or cell range in the same way which suggests that a single cell that is selected (but not in edit mode) is treated as a selection with width 1 and height 1. Personally I would find this more useful and consistent.

😎 Fair enough.

9) I will test to see if the crash happens if no DAQ is active (but I think it does). Halting execution does not cause the crash, it is when full edit mode is entered after the halt that the crash occurs.

Thanks for the continued world class support.

Jamie