LiveCode Forums.

I am trying to work out whether it is possible to begin a text selection in one field and continue it to a second field both programatically as well as visually.
The text fields are both locked and non scrollable (contents will always fit fully within) and thus allow text selection and hiliting.
They are side by side on a card and I want to begin a text selection operation by clicking in one field and then dragging to the other field before releasing the mouse.
I have attached a digram below to illustrate what I want to see and accomplish. The image shows the two fields and a dividing line which I thought I could use as a trigger point (it would be not visible in the final form).
I begin the text selection at point "A" and drag towards point "B" crossing the divider at point "X".
In the left hand image I have dragged to a point just before the diving line and the blue area shows the expected hilite of the text in field 1.
After crossing the dividing line the hilted text in field 1 changes in recognition that rather than continue to a place higher in the field, I am actually continuing to the next field and am thus selecting the text on the bottom of the first field.
The second image shows the desired hilited text (and thus the selected text) after I finish the drag at point "B" and release the mouse.
Those on a Mac can see this behaviour in iBooks when viewing two pages and making a similar selection.
To do this in LC requires faking the text selection in one of the fields once the selection is made as only a single field can display hilited text at any one time. (bummer)
I have spent a good few hours in trying to get my head around what I need to do and keep ending up at the impasse of detecting when the mouse is dragged across the diving line (point "X") to make the behind the scenes transition to fake the correct hilite in field 1 and begin the fake hilite in field 2.
Unless there is another approach it seems I need to be able to detect during the mousedown/drag moving over an object (the divider line) and running another handler to do the work while the drag is still in progress.

Can this be done?
Can another handler run during the drag of the mouse?
If not, can I force the end of the mousedown (at point "X" say) and begin a new one (simulating the text selection starting at the top of field 2) to complete the task?

So, any ideas on how I can proceed?
Is this something that may have to wait until LC8 (I noticed some discussion on really breaking up the mouse messaging which may offer some intercession)?

BTW I could just grab a click in field 1 and respond to a subsequent shift-click in field 2 to select the text between the two clicks.
The problem with doing this is that there is no visual feedback during the selection process (indeed, given the fields are locked there isn't even an indication of the first click.)


James

Hi.

So much fun.

On a new card make two fields, side by side as you laid it out. Put some text into fld 1, the leftmost field. Set listBehavior, autohilite and lockText of fld 1 to "true". In the card script: This seems to do what you asked. Or at least it seems so to me. I maade it so that successive drags as you described will build successively into fld 2.

Now there is no clean-up, hardly and start/stop stuff and likely there will be a bit of management about terminating this living process, depending on how you want to extract and load the data from fld 1. But this ought to give you a head start.

Craig Newman

Perhaps I wasn't clear.
Two things.
1. This is an exercise in being able to select text by beginning in one field and ending the selection in the second field.
I want the text to remain as is in both fields.
Your script is also about putting lines from field 1 to field 2.

2. The fields are normal text fields, not lists.
That is, the lines are wrapped.
Making them list fields reduces the text down to a couple of lines (visible)
Although my pictorial example showed whole text blocks being selected the start and end of the text selection could be anywhere within the body of the text.

But thanks for thinking about it.

My mention of how iBooks behaves was more than happenstance.
My app is concerned with being able to annotate and search epubs.
One view the user will have is a two page view where field 1 of my example corresponds to the left hand page and field 2 the right. Thus the text at the bottom of field 1 continues at the top of field 2. Hence the requirement to drag across the two fields to select any text of interest that begins in field 1 and continues on to field 2.

The fallback position is to do two selections. First select the text in field 1 to the bottom. Cntrl-click and choose what you want down with it (hilite, save, append note etc) and then after that the user selects the remaining text from the top of field 2 and cntrl-clicks to choses something like "Append to previous selection"
Doable but simply not as elegant.

Hmm.

So what you want to do is simply to select the text above and below the lines at the start and end of the drag, where the y values of that process in each field marks the top and bottom of the text in those respective fields?

It is late where I am, but that sounds simpler than the thing I just sent. If that is what you intended, write back, and I will try to help tomorrow. Or likely one of our European buddies will make an offering before I get to it.

Craig

Well I guess in the context of my example (going from the left field to the right) I am selecting the text below the start point of the drag to above the end point in the right hand field.
Thanks Craig, appreciate the input.

Just so.

If you look at my handler, you already have clues to how to start. But the basis of that handler are the bounding lines of the selected text. You will not have any selected text in the righthand field. But you might still derive similar information. Perhaps the "mouseLine" is your friend here.

Craig

The mouseline function might be of interest if I was concerned only with text lines but I am not.
Given a line in this context is actually a paragraph and a paragraph may consist of many sentences a user may want to begin (or end) their selection within a line, say sentence three, in which case I do not want sentence one or two included.
The relevant function in this case would be the mousecharchunk if it worked as one would expect from other apps.
If the text field is editable, clicking in the white space between two paragraphs (assuming no intervening cr's) places the insertion point at the end of the paragraph.
if the field is locked, as in my case, clicking in this white space the mousecharchunk returns empty, not the charchunk of the last char of the paragraph.
Actually it is even worse than that as clicking in any white space between the rightmost character and the right margin returns empty.
Thus unless the user clicks within the actual text body (within a word or between words) I do not know the char position immediately to the left or right of the click.
I will often begin a drag from this empty space because it is a larger target and I know the selection will begin with the first character AFTER my drag (if dragging down.) I do not think I am alone in this.
I have actually submitted an enhancement/bug report on this http://quality.runrev.com/show_bug.cgi?id=15632

So yes, if my enhancement/bug request gets addressed I can find the start and end of the selection but I still can't see how I visually feedback this selection process to the user.
i.e. as they click and begin to drag in say the left field the text is highlited (up or down depending on the path of the mouse) until it is dragged over the crossover point at which point the text below the initial click is hilited and text in the right field begins to hilite from the top as soon as the cursor enters the field.

OK. try this, though I did it with list fields. But maybe you will get some insight.

Make two list fields, side by side the way you like them. Make a third field of two lines somewhere else. In the card script: Now this is verbose, and has too many fields, but I was testing values as I built it. Is it closer?

Craig

This will be tricky because, as you say, you can't have more than one selection at a time. You'll need to use the text's backColor instead. If you set the backColor of the text to the same color as the hiliteColor then it shouldn't be too noticeable. Text backColor has a slightly smaller rectangle than the selection does but it's minor.

But there are some issues. You won't get any mouseMove messages during a selection so you can't track it that way. You can get a selectionChanged message, but it is only sent after the mouse goes up. So you'll probably need the user to make two separate selections, one in each field. Then you can put this handler into each field:
When you want to clear the hiliting: Not what you really want but I don't offhand see any way to track when the user tries to make a continuous selection across two fields. If you try to capture mouseEnter in the second field, it won't be sent until the mouse goes up. But maybe that's useful; you could at least find out where in the text the mouse was and do the coloration in the second field after the fact.

Someone with more time may be able to tinker a little more with these ideas.

@Craig, as i keep mentioning I am not using list fields. They behave quite differently to a locked text field (which behaves differently to an unlocked text field.) But thanks for trying to help.
@jacque, yes you hit the nail on the head re the complete lack of mouse messages once a user begins a selection of text.
This is why I mentioned that I might have to wait until LC8 and developments on field components for widgets and finer control over mouse messages.
(it seems the current field object is quite a complicated beast given its multitude of roles.)
None of the ways I have come up with can work in a smooth way simply because they are all effectively locked out once the user begins selecting text.

I will stick to requiring two selections by the user until the mousecharchunk gets changed or LC8 provides a solution (whichever is sooner.)

looking at the different messages etc available for locked text fields I noticed the selectedchunk and wondered what it returned if a user just clicked in a field without moving the mouse.
Well it turns out it does return a valid chunk expression when a user clicks in the white space at the end of lines.

So I now have two ways of selecting the text across two fields.

One, user makes a selection, cntrl-clicks to acts on it (hilite etc) then makes selection in second field cntrl-clicks and has option to append or prepend to first.

Two, user clicks in one field and then shift clicks in second hiliting all the text between the two clicks. Of course I will need to fudge the initial hilite as Jacqui pointed out, but it should work. I will also need to fake an indicator (i-beam perhaps) to denote the point of the first click.

Still not smooth as in iBooks or Kindle, but usable.