Changing Table Cell Attribute in Callback

[Jackson_Peacock]

Hi,
I have a table full of string cells. Only strings of certain formats are considered valid for this application, so I would like to highlight invalid cells to make it obvious to the user if there are any problems with the current table setup. I check all the cells when loading data into the table from a file, and set the color of the text using SetTableCellAttribute and ATTR_TEXT_COLOR. I also need to check values when they are typed in by the user, and my customer would prefer for this to happen as they are typing, ie on an EVENT_VAL_CHANGED instead of an EVENT_COMMIT. However, I am having the problem that if I modify a cell's attribute while it is being edited, the changes are forgoten, and the display becomes confused. Is the
re any way around this?
thank you,
jackson

[LuisG]

Hello, Jackson

I tried the code below in the table's callback, and it worked fine for me. Are you doing something different? If so, can you send me a snippet that I might be able to reproduce?

if (event == EVENT_VAL_CHANGED)
{
PointSet (&cell, eventData2, eventData1);
GetTableCellValLength (panel, control, cell, &length);
if (length > 20)
SetTableCellAttribute (panel, control, cell, ATTR_TEXT_COLOR, VAL_RED);
}

Luis Gomes
NI

[Jackson_Peacock]

Hmm, that is almost exactly what I am doing 🙂 here is the code in my callback:
if (EVENT_VAL_CHANGED == event){
cell.x = eventData2;
cell.y = eventData1;
GetTableCellVal (panel, control, cell, str);
if (pcm_get_code (str) < 0) {
color = VAL_RED;
} else {
color = VAL_BLACK;
}
SetTableCellAttribute (panel, control, cell, ATTR_TEXT_COLOR, color);
}
I tried the code that you have and I have the same problem: it works fine until I type more than 20 characters, but then everytime I set the attribute, the cell reverts back to what the value of the string was before I started editing it.

I am using CVI version 6.0 and the I have both the table and the c
ells set to Hot. Thank you for looking into this I hope you are able to replicate the problem without too much more trouble.
jackson

[LuisG]

I'm sorry. You're absolutely right. I didn't pay attention to the value being changed. I was only noticing that the color was being changed and that the new color was being preserved as the editing continued.

It looks like you found a bug in the table, which will be fixed. For now, however, you can try a couple of quasi-workarounds, but there is no complete workaround.

You can ensure that the edited value is preserved by terminating the edit session prior to changing the color:

...
if (length > 20)
{
GetCtrlAttribute (panel, control, ATTR_TABLE_RUN_STATE, &state);
if (state == VAL_EDIT_STATE)
SetCtrlAttribute (panel, control, ATTR_TABLE_RUN_STATE, VAL_SELECT_STATE);
SetTableCellAttribu
te (panel, control, cell, ATTR_TEXT_COLOR, VAL_RED);
...

The problem is restoring the edit session on the cell. You can sort of do it by calling

SetCtrlAttribute (panel, control, ATTR_TABLE_RUN_STATE, state);

after changing the color. But the cursor will not be in the same position, and the entire text will be highlighted. You can kill the highlighting by faking a key afterwards:

FakeKeystroke (VAL_LEFT_ARROW_VKEY);

But the cursor will still be at beginning of the cell, which might make it jarring to someone who is trying to type into the cell.

If your user doesn't need to continue editing, then it's a bit easier. In that case, instead of restoring the run state, you should just make a different cell active, so that the highlighting goes away.

Neither of these are very good workarounds, but hopefully you might be able to use one of them. I'm sorry for the bug...

Luis Gomes
NI

[Jackson_Peacock]

Okay,
I've come up with a good work-around. To start with I read the current value of the string before I set the attribute, and then set the string value afterwords. There is one slight problem with this though. If the user adds a character to the end of the string, then when I set the attribute, the string resets to it's last value, which is one character less in length that the new string, so the curser ends up being pushed back one space before the new string is set. To get around this, I read the old string after I set the attribute and check if the two strings are identical except that the new string has one more character at the end. If it does I generate a left arrow key event. So the finished work-around code is:

...
GetTableCellVal (panel, control, cell, str);
SetTableCellAttribute (panel, control, cell, ATTR_TEXT_COLOR, VAL_RED);
GetTableCellVal (panel, control, cell, str2);
SetTableCellVal (panel, control, cell, str);
for (i=0; str[i] && str[i] == str2[i]; i++);
if (str[i] && !str2[i]) FakeKeystroke (VAL_RIGHT_ARROW_VKEY);
...

Thank you for your prompt responce. This is one of the best developer support systems I have seen; even better than many open-source software developer lists.
jackson