Thanks for looking into this with me! The way you (Jim) appear to take what I did and turn it around in a fraction of the lines is amazing! Someday I want to be able to do that :-)
Jacqueline is correct. The fields make up a mixed up paragraph. I have it working where it lines up the mixed up fields nicely across and down the window. The user is to put the fields back in order. If one of the fields is a pixel lower on a line, or when the user has to start another line of fields below the first, there is a problem. I like your idea Jacqueline about the drop down fields but I'm afraid not being able to see all parts of the paragraph will make it too challenging at a beginning level. I thought I could make each row of fields on the window a separate group. This could be done when the stack creates the fields for each line. However, that would mean that I would only have mixed up content for each line going across, and I couldn't make the user drag fields between lines. I want more mixed up flexibility... Maybe I could have the fields snap to alignment some how when the user checks their answer and before the sort...but that still would not eliminate the issue with the subsequent lines of fields and their order over all... LiveCode doesn't do character recognition does it (OCR)? I could do a screen capture, covert the pict to text and then check its content ;-) ... Hmmm? What if the user drags the fields over a target...the target could "suck the text" out of the field and spit it out in another field. (This essentially would be eliminating the user to type out their words on a keyboard.) However, how would I handle the user wanting to change their order? Could the text chunks they drag into the target be "special chunks" that act as quasi buttons that when clicked on by the users recreates that specific chunk text and deletes itself from the answer field? The user could still drag their fields around on the screen to order them the way they want, and then just drag them into the target one at a time. What do you think? This seem doable? Thank you! John Patten SUSD On Jan 29, 2011, at 11:35 AM, J. Landman Gay wrote: > On 1/29/11 1:05 PM, Jim Ault wrote: > >> It depends on the authors desired logic. > > From the subject title, I'm assuming he wants "natural" reading order. Right > to left, top to bottom. One of the problems I ran into (and the OP mentioned) > is that if a field has a Y value slightly below another field, but not by > much, our eye will see it as "in line" with the field next to it, but a > sorting algorithm will see it as "below" the field next to it. > > I tried looping to find successive topleft fields repeatedly, and that almost > works, but you still get Y-offset problem. I'm thinking you'd need to define > a cutoff point where a field location is arbitrarily defined as "below" the > current line; probably the height of the field, I guess. > > To John: I think I'd cop out and avoid the whole issue by providing "drop > boxes" where fields will snap to known locations so that I know what order to > read them in. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > _______________________________________________ > 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 _______________________________________________ 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
