Visual LANSA Forum

We created a VL Web app in LANSA V15: We show a list using the primitive #PRIM_LIST, because the end user can change list values. We activated the ShowPages property to true so the enduser can scroll in case of too many entries for one page: The problem is that if the user decides to change a list value, the keyboard takes almost half of the screen and this can result in not showing the list entry that needs to be changed: It seems that I can only include 3 images, so next see next message here to see the rest......

So....

So when I select an entry in the list I change the ShowPages property to False, so all 6 entries are still visible: The problem now is, that when I have change the entry value, I can remove the keyboard, and I want to visualize the ShowPages again (set this property back to True). But removing the keyboard on this device does not trigger any VL event, so I see my total list again without the posibility to scroll to the next page: Does someone know if it is possible to trigger the disablement of the devices keyboard, so I can set property ShowPages back to True?

1. Are they clicking somewhere else to close the keyboard? Can you use getfocus on those elements?
2. Are they expected to enter a certain number of characters in the value that they are changing so you can do a keypress and when they type 10 characters you can do what you need?
3. Timer, but you can't really know how long it's going to take to enter the value.
4. Timer on keypress, if it takes more than x seconds between keypresses, assume they are done?

Hi Art,

1. No, change change a value in the list (touchscreen) and use on the keyboard the little down key to disable the keyboard on the devise.
2. No. For each line they can change 3 numeric values.
3. Is not an option indeed .
4. Not an option as well

Kind regards,
René

Hi Art,

a suggestion:

1. change the list row items to READ ONLY
2. on list.itemClick show a dialog that has the Product number and the fields to change with cancel/done buttons - you can also include NEXT/PREVIOUS so that you can move to the next item without going to the list.
3. when the dialog is closed, you can update the entry in the list (without needing to do anything else).

this has the advantages:
1. the dialog only has a few on screen fields, so the keyboard size will not be an issue
2. you are not needing to determine if the keyboard is shown.
3. allows the user to confirm or abandon their changes
4. allows for the list to take the full screen. (if you update the list when the dialog is closed, you may be able to do this 'in memory' rather than going back to the server to repopulate the list.

Note: it doesnt *have* to be a dialog, it could be another view (if dialog, use Fullscreen as the position).

Hi Brendan,

Good suggestion, did not think about that yet.

Thanks,
René

Changed this into: