I noticed this a while ago while trying to write a promoted event to make EditTables a little more frendly to users expecting to be able to tab from field to field:

The first time you tab into an EditTable the cursor goes to Row 1 Column 1 as expected.

If you go on to another field and end up tabbing back to that same EditTable, you enter with the cursor at the last Selpos from the previous visit, instead of 1,1. Any attempts to modify this behavior by resetting SELPOS or PREVSELPOS to 1:@Fm:1 in events associated with either visit seem futile.

I am not doing anything special to set focus to the EditTable, just whatever always happens when the user presses 'Tab' from the previous field.

It occured to me that this might actually be intentional… it is returning you to the spot where you last entered data, sort of like a placemark. (This could actually be useful in some situations.)

But alas, if you clear the form between visits to the EditTable the row is reset to one, but the column stays at 2 or 3 or wherever it was the last time. I guess then it is a bug instead of a feature, but I was not certain enough to put it on bug tracker yet. : This is just a question.

I am a 'mouse guy', but some of the users called me on it right away. I guess it pays to try things the 'keyboard way' now and then!

This is on 7.2 by the way. I noticed there was a little discussion here about some problem with SELPOS and 7.2 awhile back, but I did not see what finally became of it.

Thanks!

Jim

I just tested this. Put this script on the lostfocus of an editline in the tab order just before the edittable.

UNUSED=SET_PROPERTY( @WINDOW : '.TABLE_1', 'SELPOS', 1 : @FM : 1 )

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Hmmm… crude but effective, I like that! I thought it might have the side effect of sending focus to the EditTable in question if you moused over to a different control, but it doesn't.

You DO have to have a control that can get focus and fire a LOSTFOCUS event in the tab order right before the EditTable. That means it can't be invisible or disabled or just displaying a symbolic field.

I have many, many EditTables, so I was trying to take care of this at the promoted event level. I have SRP's OLE controls too, but that is a bit of a migration to do all at once on so many of them, and almost all are databound. I am trying to make the old and new blend in as well as possible during the transition.

Maybe I can do something in a promoted LOSTFOCUS event that checks the NEXT property to see if it points to an EDITTABLE control. It could even chain down through a few controls if need be.

I was kind of hoping somebody would take pity and just fix whatever is wrong with the SELPOS.

I noticed this behavior in one of my apps a few days ago also.

It is a pain since previous releases didn't have this behavior.

View this thread on the Works forum...