I have a little 'tree' list in a field, using inline images to display disclosure triangles next to non-terminal nodes. It all looks fine. When a user clicks on the line, I distinguish whether they were clicking in one of the disclosure triangles - in which case I toggle it, and refresh the field with the sub-tree revealed or hidden - or elsewhere on the line, in which case I do something with the selected item. This works fine too.
The only thing is this: when the user selects a line (by clicking somewhere other than the disclosure triangle) I want it do display selected, ie using the hilited line. But when they click on the triangle, I don't want to change which line is selected (at least unless the selected line is hidden as a result of the toggle); I want people to be able to conveniently view the tree structure, opening and closing sub-trees, without modifying which item they've currently got selected. Here I get stung because the engine hilites the line as soon as they click on it. I can store the 'real' hilited line in a property, and if the click was on an toggle arrow, restore the hilited line (which I possibly need to adjust, since the result of toggling an arrow above the current selection is liable to move the selected line up or down) but the effect is very weird. The selection flashes up to the line the user toggles, then down to the selected line. This is all made much worse by the fact that the field automatically scrolls each time the hilitedLine is changed, not merely to bring it into view, but to centre it. I thought: fine, I'll just switch off the auto hilite. But it appears that if you don't have auto hilite, you don't get any hilite. As the documentation for hilitedLine says "If the field�s listBehavior property is false, this property has no effect"; while the documentation for listBehaviour says "If the field�s autoHilite property is set to false, the setting of its listBehavior property has no effect.". In other words, you can't have hilited lines unless you have listBehaviour, and you can't have listBehaviour without autoHilite. Whaaaa. Why shouldn't we be able to have listBehaviour without autoHilite? After a lot of time mucking about finding workarounds, the best I could come up with involves replacing that single field with two fields (one for the text and images, one for the hilite) in a locked scrolling group; itself grouped with two graphics to provide the border and consistent white background (the second graphic just required because of what appears to be a minor bug in the way scrolling groups display); together with script to tie it together, and to resize the fields and reposition the scrollbar every time the text is changed. It's all a big faff, needs touching up if I want to change the shape of the list slightly, and the end result is still not quite perfect (that is not quite as smooth as an ordinary list field). So, could I request a modest change in a future version: to allow us to have list field functionality, without auto-hiliting, so that our apps can take control of the hiliting behaviour? (I believe the auto-centering has already been whinged about.) (And if anyone can suggest a better workaround, point me to the simple thing I misssed (or explain further about the scrollbar messages) I'd be very grateful.) TIA, Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com | Fax : +44 (0)1273-728866 _______________________________________________ improve-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/improve-revolution
