WebDirect Drop-down List and Popup Menu Alternatives

Lounge (Discussions)
1

Generally I'm quite happy with WebDirect. However, a big limitation is surprisingly poor support and bugs in Popup menus and Dropdown lists.

Problems include:

  • only 10 items are shown in the dropdown
  • font size is weird
  • you can't scroll the list - in fact on Desktop, if you try to scroll (with a gesture or scroll wheel) the dropdown closes!
  • instead you have to click the tiny down arrow icon which shows the next 10 items
  • keyboard support is poor - only up and down arrows are supported for PopupMenu style (no type-ahead).
  • on Mobile, the menus do not use the OS native picker

Example dropDown menu on WebDirect

image
image680×576 36.3 KB

Any suggestions to improve this?

2

Trying out some options...

Popover Button with scrollable Portal

To make this work, change your Text field into a popover button. Set the title of the button to a merge field calculation set the value of the field:

image
image546×234 13.7 KB

Add a portal to the popover, with the number of rows you want to display, and enable 'Allow Vertical Scrolling':

image
image798×284 26 KB

Add a button script to the portal field that sets the field value and closes the popover:

Set Field [Table1::Field1; ValueListTable::value]
Close Popover

Add Conditional Formatting to the portal field so that it highlights when the portal row's value matches the field value:

image
image906×304 27 KB

(not shown) do some more formatting cleanup to remove extra field and portal outlines.

The end result is not bad:

Image:

image
image602×838 30.4 KB

Video:

Pros:

  • you have complete control over the number of visible rows, font and formatting
  • scrolling through the rest of the portal rows works normally on desktop and mobile

Cons:

  • no keyboard support
  • if the selected item is scrolled off the bottom, it will not be automatically scrolled into view.
1 Like
3

Portal approach is useful however I would suggest putting these into card windows instead for reusability and allowing them to work within portals and other popovers.

In our large webd solution we use cards as picker windows for common things, notably staff/users . It can be launched from any context and is completely generic. The script will accept a reference to a field name (eg. GetFIeldName ( xxx:yyy ) ) , it launches the card, and allows user to search/select a staff member. Upon selection, the card closes and we do a set field by name of the required field to set it. works great in portals too as they do not lose their row context. It also means you do not need to establish a TO for your various contexts just for a portal in a popover.

1 Like
4

We use a lot of portals in popovers. It's user-friendly and light-weight for development and maintenance. We use almost entirely use them instead of value list controls. We have a virtual table especially for the purpose of presenting portals of option lists to the user.

Like @weetbicks we also use a lot of card windows. However, we lose some of the magic because we always do a record commit prior to opening the card window. That means we always have to record the active object, active portal row, etc. Then we have to reset everything when the card window closes, which is a pain. The reason we self-inflict the pain is that it means that we don't get bitten by data integrity issues arising from "user-does-what-user-wants."

2 Likes
5

Curious why your commit is required? I guess it depends on what you are editing in the card, but if it is just a simple picker-style dialog for selecting from a list, I don’t see why you would need the commit ? I’m sure it’s something in the KAMAR secret sauce :slight_smile:

6

We have a multi-file solution and we pass any data related processing away from the UI into other files or the server for processing. If we have an active record open in the UI the subscript/server can't do its thing. Or more likely, the subscript/server does it's thing on every record except the one that the user is looking at because it's locked open.