Nick, Thanks for the suggestions. I am actually duplicating some functionality that is fairly central in an existing application and I described a small slice of what the user feedback. In isolation it does sound complex but it has never been something that I know of causing confusion for our users. At any rate that is what we have on our existing app and what we have on our existing app is what people want from a laszlo based app.
I looked at the link you provided and it isn't exactly what we want, although maybe we will end up doing something like that. So if anyone has any other ideas that would be great. Ideally I want x,y postion to field insertion offset. And if I can find something that goes the otherway (field insertion offset to x,y) too that would be useful as well. Thanks, Daniel. [EMAIL PROTECTED] wrote: > > Hi Daniel, > > I think you could save yourself a lot of strife - it sounds as if you > might be trying to complicate things a bit. Consider the code I've > pasted here, which I've borrowed from Sarah Allen's fantastic > "Inspector" widget on mylaszlo.com: http://rafb.net/paste/results/ > WnOP0395.html > > If you run the code, you'll see that the default behaviour is as > follows: > - A single click will select all text. > - A double click will put the insertion point where ever you've clicked. > > That seems pretty intuitive to me! Why complicate it? > > You might also want to think about a click having multiple behaviours > - being used to select a field and also drag its positon, and again > making it editable. (Forgive me if I've misinterpreted.) This isn't > particularly intuitive from a users perspective. > > I can think of two possible solutions that might simplify the > behaviour : > > 1) Use an Edit button to enter edit mode > Above your text information (or somewhere highly visible), add an > "Edit" button > - When the Edit button is left unpressed, text fields behave as > draggable. > - When the Edit button is depressed, text fields appear visually > different (outlined in a mid grey, for example) and are fully > editable. The button should stay depressed as long as the user is in > edit mode. > - To exit Edit mode, users should repress the Edit button. > > 2) Use short and long clicking to differentiate between the two modes > - Short clicking (a quick depress and release of the mouse) would > enter edit mode > - Long clicking (clicking and holding for approx 1second ) would > activate drag mode (you could ghost the box to give the user some > feedback) > > To see an implementation of behaviour (1), check out Apple's Address > Book app. (I'd be happy to provide screenshots if required.) > > Apple also implement behaviour (2) in their file browser, the Finder > - short clicking on a file name makes it editable - long clicking > enters drag mode. > > Both methods are intuitive, though I suspect (1) is easier to program > for. > > Hope that gives you some ideas... > > Regards > > Nick > > > > On 10 Mar 2006, at 18:21, Daniel Pool wrote: > >> For the application we are working on we have rich text fields that can >> either be editable, or clickable/draggable. >> >> When a text field is non-editable the mouse can be used to drag the >> field by clicking and dragging the field. >> When a text field is editable the field cannot be dragged but can have >> the insertion point and selection is set by clicking and dragging in >> the >> field. >> >> The way to make an editable field non-editable is to click anywhere >> outside of the field. >> Clicking on an unselected field selects it. >> The way to make a field editable is to click on the field when it is >> already selected. >> >> The problem is that when a selected, but non-editable field is clicked >> on the insertion point should be set based on the position of the >> click. >> >> I can see two possible solutions but I don't know how to implement >> either of them. For selected but non-editable fields: >> 1...When the field gets a click set the editable property to true and >> then post the click event to the field again, or create an event to >> post >> to the field. >> 2...When the field gets the click from the x,y position of the click >> determine the offset into the text-string of the field and call >> setSelection based on the offset into the text-string. >> >> I see a way to possibly implement the 2nd solution, but it is a really >> ugly hack. >> >> Does anyone have a suggestion as to how this should be done? >> >> Thanks, >> Daniel Pool. >> _______________________________________________ >> Laszlo-user mailing list >> [email protected] >> http://www.openlaszlo.org/mailman/listinfo/laszlo-user > > _______________________________________________ Laszlo-user mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-user
