Thanks for the suggestion, Andrei - I'll give that a try! I'm adding listeners to it because our project requires that users clicking on a certain section of text creates a popup for editing that section's properties. We are delimiting these nominal sections like this:
<span ... various metadata>CLICK ON ME</span> Clicking anywhere on the span or within it brings up the popup. The popup has to know all the metadata, and the value of all the children of the <span>. We don't gate what can be placed within the span - it can be any amount of arbitrary HTML. This means that where they click could be N layers deep within a not-necessarily-well-formed HTML structure, so bubbling back up the DOM tree to the span we're looking for could be tough, if all we had was a screen position on the RichTextEditor. It might be less hairy than I think it is, but I think it would be pretty hairy to do right. - Tim On Thursday, October 11, 2012 4:33:27 PM UTC-7, Andrei wrote: > > Use Scheduler's shceduleDeferred() method. It specifically waits for the > browser to complete rendering (or whatever else it was doing), and then > dispatches a new instruction - like to parse the rendered DOM. > > Why do you need to add listeners within the RichTextArea? A better > approach may be to add a single click handler to the RichTextArea widget > itself, and check the source of click within this handler. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/FEFIM8-fddAJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
