views:

374

answers:

2

I'm attempting to implement a feature where a user can select some text in a WebView and, after releasing the mouse button, a small window will pop up to allow the user to perform some operations on the selected text.

However, I'm running into some trouble with determining when the user's selection has been "confirmed", for lack of a better word, by releasing the mouse button. The WebEditingDelegate informal protocol defines a -webViewDidChangeSelection: method, but it's called every time the selection changes at all. So, for example, if the user drags across an entire line, -webViewDidChangeSelection: is called many times – once for each time the selected range changes. Obviously, this wont work, since I'd be popping up my window several times over the course of the drag.

Does anyone know of a way to accomplish what I need?

+2  A: 

You could use that same method, but just test for whether the mouse is down, if so, do nothing, if the mouse is not down, assume it was just released and then show your window.

littleknown
+1  A: 

I think your focus on the "mouse up" as an end event might be too narrow. For instance, what happens when the user clicks and then selects text with shift-arrow keys? Shouldn't your software have the same effect in this case?

What littleknown suggested sounds reasonable for the mouse part of the equation, but I'm concerned that when the selection is changing from the mouse, you may never get a final "selection changed" when the mouse is up.

So, I would probably approach this problem with a pure NSTimer delay. every time you get a "selection changed" from the web view, reset your NSTimer. When it reaches some short elapsed time, like 0.5 seconds say, put up and/or move your window.

You could fine tune this by inspecting, at timer expiration, criteria such as whether the mouse is still down. If the mouse is down, you might just postpone the timer a little while and see if the mouse has been lifted after another half-second or so.

danielpunkass
Yeah, certainly focusing solely on the mouse is a bit narrow. I don't expect it to cause a problem with modifying the selection by keyboard, since the WebView is not editable and, as such, there is no insertion point for the user to change with the keyboard (the kind of data the user is going to be looking at is not going to be from editable textareas or anything like that). I suppose, however, that focusing on the mouse might still cause issues with accessibility devices later on, though...
Matt Ball
Text does not have to be editable to be keyboard selectable. Just double-click a word to select it, and then shift arrow to see. Also, cmd-A to select all. These may not be common use cases but you'd do well for the polish of your product to cover them all the same.
danielpunkass
Wow, it never occurred to me that extending a WebView's selection could be done like that (learned something new, after using OS X since 10.0!). Not sure why not, since it's consistent with all other selectable text in OS X. The cmd-A case wasn't really an issue, since, due to the nature of the text in question, selecting all doesn't make sense. But you're right, I definitely need to handle selection extensions. Thanks!
Matt Ball