I'm working on supporting SELECT controls in forms. I've got a working first draft of the changes to the Dillo parser, but it's of no use yet because the Dillo menu widgets are incomplete; the menus report every item as selected and the items don't yet do anything when you select them (unless I've missed something). So I'm wondering how to fix this. We need a way to connect Items to callbacks. We need some abstraction because ListResources and OptionMenuResources will do things differently. The most straightforward thing to do is add a virtual function to SelectionResource that returns the callback to attach to the FLTK items we create. Is that OK, or do we need something more abstract? Assuming the Item will be passed to the callback, we really need a way to get back from the Item to the ListResource. The easiest way is to simply add a new data member to Itens that points to the ListResource. Again, is that OK, or should we be more abstract and not hardwire that implentation into the base class? I'm a fan of abstraction (I used to be a mathematician) but I'm inclined not to go too abstract unless there's good reason, so I think the suggestions above are good enough. Thoughts? If we do the above then fixing OptionMenuResource should be easy; add a data member to record the last selected Item, connect Items to a callback that updates that data member and implement isSelected() to compare the item being queried with the selected item. Is it worth submitting a patch along these lines, or should I do it differently? Regards, Jeremy Henty