Rajesh wrote:
My implementation details: --------------------------
I am planning to implement a method in the exiting "FindTextState" Class. I am planning to use a CharIterator to move iterate through a web page and find out a link.
I'm thinking of Layout having a separate thing for this, a KeyFocusState (or some such name). For an iterator, something like a focusable element iterator instead of a CharIterator. Where I could call nextFocusable() and get back 1) the Widget (the Embed widget for a form control, or the Textblock widget that contains a link), and 2) a linkNo that the iterator found in the word's style. Like if the user pressed the key for the next focusable thing (e.g., tab), the KeyFocusState stuff would do something like iterator->getFocusable() gives back Widget *w and int linkNo if (linkNo == -1) { /* form control */ w->focus(); the dw Widget would have a virtual function, and the Embed implementation would call resource->focus(), which would in turn call take_focus() on its fltk widget. } else { iterator->highlight(); } and when the user pressed the key to follow the link (e.g., enter), we'd be in something similar to a_UIcmd_scroll() calling a new function like layout->activateLink(), which would call something in FocusState (which has Widget and linkNo handy), which would then call layout->emitLinkPress(widget, linkNo, ...) All: Or is that putting too much intelligence into an iterator? (It's easy to wish for magic from the part that's fuzzier to us :) Something smaller and dumber for an iterator to do would be something like styleIterator. Get back style, spaceStyle, style, spaceStyle, (some style from descending into a non-Textblock child), spaceStyle..., but then there's also this need to get back the "BTW, I am an Embed!", which seems like an awkward pairing of things for an iterator to return. Or a sort of Word iterator, but Words are hidden...