02-19-2023 09:51 AM - edited 02-19-2023 09:57 AM
@CoastalLabVIEWER wrote:
Not sure if anyone will see this...
As you noticed we will see it, even if you bump a decades old thread with a vague accusations that something that has been shown several times in this discussion does not exist. 😄
Can you explain what you mean by "direct way" and "that's it"? Are you talking about changes at edit time or run time? Of course you still need to adhere to all principles of dataflow to ensure that this code part is actually executed when you think it should.
If this is a massive list box with many cells and you want to do may changes, it sometimes helps to defer panel updates.
(If you have a specific problem, I recommend to start a new thread and attach a simplified version of your code)
02-22-2023 02:02 AM
If your goal is to set the color of a specific cell easily from the LV editor (which is something I might find useful occasionally), then you'll need to write some kind of extension to the editor which can do this. This can be something like a Quick Drop keyboard shortcut or a right click menu plugin. This can then pop up a window where you can select your color. If you use the right click menu plugin, then you can should be able to use the data from the mouse click to already know which cell you clicked on.
02-24-2023 12:47 PM
I've done some more work and my real culprit is the Selection Color property but to a lesser extent the ActiveCell concept. In early times working on this I was setting Selection Color to the same as the CellBG color when I was programmatically changing the colors/fonts and didn't realize what was happening with the panel between iterations of running the VI was having to do with cells that had been clicked and whatever the color of the last cell of the table was when it was being set programmatically.
I thought I real quick fix would be to set the Selection Color to transparent, which does seem to work for the color, but also manages to hide the text in the cell (this is LabVIEW 2012) which is pretty strange to me.
For what it's worth I have managed to suppress the behavior I don't want with deferring panel updates at the right time but it just feels cumbersome. Perhaps there is a different control that I should be using? All I need is a table that I can capture which cell a user double clicks on and change fonts/colors based on that click. I don't want to make any cell activated based on this click.
02-26-2023 05:43 AM
I can't say I understood your first two paragraphs, but for what you say you want, you can simply use a table or MCLB and set it to be an indicator or set its disabled state to Disabled. In both cases, the user shouldn't be able to interact with it. You can then use a double click event (specifically, the Coords terminal) and the Point to Row Col method (create an invoke node for you control to access it) to set the active cell and set the other properties that you want for that cell.
Note that the active cell is not "activated" (i.e. it's not selected), so there's no reason to play with the selection color. It's just the cell (or cells) which cell-specific properties affect.