Detecting change in edit position of a table control

[WNM]

In a nutshell, I'm looking for something like an "edit position has changed" event for a table control.

I know about using a mouse-down event to detect when the control and a cell within the control is first selected, but assuming the control's "MultiLineInput" property is set to false, a user can also change the edit position by pressing the enter/return key to advance to the next cell down in the table. I have not found a good way to detect this type of change if it does not accompany a "value changed" event for the text within a cell.

Yes, I know about key up/down events for the control but I have not found a way to use them without negatively impacting the ability to edit text strings with the cells. I also don't want a loop running off to the side just to monitor the edit position and report when it has changed.

While I'd really like to know how to do what's described above, I could settle for knowing how to effect a "scroll lock" on a table so that when a user presses the RETURN key while the edit position is at the last row of the table, the table does NOT scroll up by a row. So far I don't think this is possible either.

[smercurio_fc]

Have you tried using the event structure's Timeout case to monitor the edit position? If it changes then you could trigger a user event. You wouldn't need a separate loop in this case.

[Ben]

off-screen boolean with key navigation set for return?

THis will terminate the edit and move keyfocus to the boolean.

Ben

[Darin.K]

---

@Warren Massey wrote:

While I'd really like to know how to do what's described above, I could settle for knowing how to effect a "scroll lock" on a table so that when a user presses the RETURN key while the edit position is at the last row of the table, the table does NOT scroll up by a row. So far I don't think this is possible either.

---

If I recall correctly, the Table control will not scroll if the vertical scrollbar is not visible, it simply moves to the first row of the next column.  If you want to prevent this, or allow some scrolling with a limit you can use the Key Down? filter event as follows:

Feed the VKey data to a case structure, in the default case just pass it straight out and into the VKey data node on the right side.  Add a case for "Return".  In this case make your comparison on the Edit Position, if you want to prevent scrolling feed the value 'Enter' out to the VKey data node, otherwise pass Return.  To get the Enum constant for 'Enter' simply right-click the VKey data node and Create Constant.  In this way, hitting Return in the last row becomes Enter and stops the scrolling.

[nathand]

Have you tried using a Filter event for the Key Down case?  Here's an approach that loops back to the top of the same column when Enter or Return is pressed at the last row of a table.  It should not otherwise affect data entry.

(Of course, the snippet creation did the usual thing where implicit property nodes become explicit ones... sorry for the mess)

[WNM]

I had used the timeout case to watch the various table properties (including edit position) while investigating the various table control behaviors but that still smacks of a polling solution that I'd rather avoid if possible. I had used the words "loop running off to the side" because I thought it would better convey what I wanted to avoid. I suppose I could make this a less stinky solution if I pop up a dedicated data-entry sub-vi just for the table entry process and have the table outside the sub-vi just be an indicator. That way the polling is only occurring while the sub-vi is active.

I just tried the off-screen Boolean setup for key navigation tied to the ENTER key and that breaks the ability to jump down to the next line in the table (assuming it's not the last line) as a user populates an empty table. I'd rather not do that because it forces the user to mouse back over to the next line in the table as the table is initially populated (with exactly 11 entries).

This just strikes me as functionality that should probably be present and if it is truly missing then perhaps some ambitious NI employee might consider adding it at some point.

[Darin.K]

Like all things, polling is fine in moderation, in fact it is the correct "dataflow" way to do things.  There are two problems I usually encounter:  greedy polling and the fact that sometimes the "deed has been done" and you have to correct after the fact.  The timeout event is a simple, and often effective means of throttling the polling.  If you have Mouse Move events inside, for example, this may be a problem.  This type of throttling gives you maximum responsiveness when nothing is happening, and sluggish response (relatively) when a lot of Events are happenning.  What I typically do is use a separate loop which is throttled by the Wait For Front Panel Activity function with a relatively long (200-500 msec) timeout.  This gives me responsive polling when Front Panel activity is happenning, but is nice and quiet otherwise.

The beauty of Events, of course, are the simplicity and the fact that you can sometimes stop the activity before it happens.

[JÞB]

If you dig into Community Nugget  Series: Application Development: Installment2

You'll find an exaple where the scrolling of a table is handled by a Action Engine and mouse events. (It also uses polling to synchronize an array to the table scroll position)  In that instance I wanted the table to auto-scroll unless the operator was scrolling.  It could easilly be adapted to have the opposite effect.

Lots of ways to skin that cat! I like Ben's and Darrin's ideas just offering a third.

[WNM]

---

Darin.K wrote:

Add a case for "Return".  ...  feed the value 'Enter' out to the VKey data node, otherwise pass Return.  ...  In this way, hitting Return in the last row becomes Enter and stops the scrolling.

---

Darin came very close to providing the answer I needed with this answer. He just got "Return" and "Enter" backwards.

In any case he provided the boost I needed. First of all, I needed to find a version of LV that had both "Return" and "Enter". LV v7.1.1 (a very reliable workhorse) does not and that is what I had been working with when I asked the question. I had looked in on v2011 but since its table control looked on the surface to have the same properties as v7.1.1, I didn't dig into it. Anyway, I went ahead and built a test vi using 2011 and found that with some adjustment, I could get it to do what I wanted it to do. The attached PDF shows what went into the VI. 

Thanks!

[JÞB]

nicely done!  and thank you for sharing the ultimate solution.