09-25-2008 07:10 AM
ritesh024 wrote:the solution suggested by Eugen Graf works Perfect.
Did you see that?
He gave a very neat and clean solution with hardly any bit of coding.
I saw it. Thats why I mentioned that mine is NOT a good solution.
But, his has coding to do, even if it is a little bit. ![]()
Mine is playing only in the FP. ![]()
11-05-2008 09:08 AM - edited 11-05-2008 09:08 AM
I just had the same question myself, and this discussion is very helpful. I chose Eugen Graf's solution, but one thing I'd like to add is that this doesn't prevent the user from tabbing or using the arrow keys to get into a cell that they are not supposed to edit (neither would Partha's). I totally randomly came upon a solution to this problem that will at least work for me. I turned off selection scrolling, and set the size of my table such that two columns are visible, and all the rows I want are visible. Then if you resize the table so that the right edge overlaps the far right column's cell border by a single pixel, LabVIEW won't let the user tab into that column during run-time. I think that with selection scrolling on, that would trigger the table to scroll, but with scrolling off, it just doesn't let you tab or arrow into the cell. This only works for me because I don't want the right-most column editable, and I can show the entire table, but it is an interesting tidbit that may be helpful to someone else.
Chris

11-05-2008 10:13 AM - edited 11-05-2008 10:14 AM
Using the Key down? Event gives you a pretty easy and flexible way. It discards all keystrokes in the first column and row in my example.
Enjoy!
Felix
11-05-2008 11:00 AM
The problem with placing widgets over other widgets on the front panel are the documented redrawing issues. You may experience flickering or slower responses from partially covered controls.
I would opt to go with Felix's method of just ignoring events in the 0th row and column.