LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

table row selection

Solved!
Go to solution

I know this has been asked (I've read all the other posts on this same issue), but I'm not having luck with the "official" way of doing this.

 

I am trying to make an entire row of a table (set in Hot mode) to become selected if any of its cells are clicked.  Here is my callback:

 

int CVICALLBACK TableTest (int panel, int control, int event, void *callbackData, int eventData1, int eventData2)
{
 	Point cell;
	
	switch (event)
	{
		case EVENT_LEFT_CLICK:
			GetTableCellFromPoint(panel,control,MakePoint(eventData2,eventData1),&cell);
			if (cell.x == 0 && cell.y == 0) return 1; // Not on a row/col
			SetTableSelection(panel,control,VAL_TABLE_ROW_RANGE(cell.y));
			break;
	}
	return 0;

 What I'm seeing is that the SetTableSelection just doesn't do what it's supposed to do.  I can break the function at the GetTableCellFromPoint and I can see the correct row get put into cell.y, but then selecting the row fails.

 

I found a good comment on this other thread about the control mode of the table.  That poster claimed that if the table is in non-Indicator mode, my callback should swallow the event.  Ok, I tried that and it sort of works.  I can see the row selected, but it's a strange highlighted effect, not a solid dark gray cell background. See the attachment (I've highlighted the row that had been clicked).

 

Which leads to more questions.  On a Hot table, with traditional events that are NOT swallowed, which event is creating the dark gray background selection of a cell?

 

For grins, I also tried putting my table into Indicator mode and not swallowing any events. But there there is no selections at all.

 

So I'm just very confused about this.  What am I doing wrong?

0 Kudos
Message 1 of 6
(6,124 Views)
Solution
Accepted by topic author ElectroLund

I don't think you're doing anything wrong, except for the fact that you're not swallowing the event when you change the selection. But even though your code doesn't show it, you've said that you've done that anyway, so this is probably a moot point.

 

Conversely, I don't think you should swallow the event when the user doesn't click in a row or column. Since your callback doesn't override the mouse click in that case, I think you should allow the table to handle the event. Also, I think your condition should be (cell.x == 0 || cell.y == 0) instead -- the difference between the two conditions happens when the user clicks on a row or column header, and the table should already do what you want it to do in that case.

 

The only reason you're seeing the outline instead of the full color inversion is because it looks as if the table isn't the active control in the panel. And that's how all table selections are drawn when the table doesn't have the focus. If you tab through to the table, after you change the selection doesn't the outline change? Also, if you try running some example program with a table (for example, samples\userint\gridview.prj). As you move the selection in that table and then tab away from the control, doesn't the same thing happen?

 

Luis

Message 2 of 6
(6,103 Views)

LuisG wrote:

The only reason you're seeing the outline instead of the full color inversion is because it looks as if the table isn't the active control in the panel. And that's how all table selections are drawn when the table doesn't have the focus. If you tab through to the table, after you change the selection doesn't the outline change?


You are right.  I didn't include the event swallowing line in my code above.  But I have it in my code.

 

I found that if I reordered the tab sequence for all the controls, such that my table was first, then I got better results with the selection coloring.  But you are right, it was as if the table control didn't really have focus, even after a left click event was successful (wouldn't that force the focus to be on the table?).

 

If I tab away and back (or some order thereof), then the selection color would sort of correct itself.

0 Kudos
Message 3 of 6
(6,091 Views)

@ElectroLund wrote:
But you are right, it was as if the table control didn't really have focus, even after a left click event was successful

You can use SetActiveCtrl ( panelHandle, controlID); to make sure your table is the active control

Message 4 of 6
(6,087 Views)

Ah, that works nicely.  Thanks!

0 Kudos
Message 5 of 6
(6,085 Views)

You need to explicitly make it active since you are swallowing the mouse click. If you weren't swallowing the mouse click, then yes, the click would have made the table active.

Message 6 of 6
(6,075 Views)