On Sun, Jan 18, 2015 at 12:23 PM, Peter M. Brigham <pmb...@gmail.com> wrote:
> Not sure if I know what you have in mind, but I wouldn't use a separate > stack over the field being edited. My output is basically shingled in rows, and I write the rows to the card from top to bottom (which keeps tab order correct, too). Also, I found that much to my surprise, formatting the schedule where this is most important only takes 30ms on my test case (formatting/calculating; not rendering). I thought that it was an order of magnitude higher . . . this makes slapping a redraw up a potential solution. > For each editable field userInputField I would use openfield to trigger > showing a scrolling input field at the same location, then on closefield > I'd set the text or htmltext of of the field userInputField to the > text/htmltext of the input field, then set the height of userInputField to > the formattedheight of userInputField, and add the difference in height to > each of the groups following. D'oh! <insert head-banging emoticon here> Now that you mention it, there's no reason to use a stack rather than a field. I've been using floating stacks so much for controls, and also for input search/reduction lists as the user types, that it didn't even occur to me . . . > You could set a custom prop of the scrolling input field to the name or ID > of userInputField so it would load the correct field. Not sure if all of > that is clear or will do what you want. That part would definitely work; I already have the code that returns to the correct place in place for other reasons (adding fields requires a redraw)). -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
