Yes...this works well. I suppose I could also just ask my window
controller if my tableview is the first responder and act accordingly.
Thanks,
Mark
On Apr 20, 2005, at 3:56 PM, John Sullivan wrote:
On Apr 20, 2005, at 3:48 PM, Mark wrote:
Thanks John,
I was afraid it would be something like this. This is pretty close
tho the first approach I tried, but the problem I ran into is that it
doesn't distinguish between webview loads that are initiated through
clicking on links and those that are sent to the webview from another
object.
Specifically, I have a tableview containing objects that can be
selected causing the webView to load data. While the user is using
the table, I need to maintain its first responder status so they can
arrow up and down the rows (this is the default behavior of course),
but when the user navigates with the webView by clicking on links I
would like the webView to remain the first responder. Making the
documentView the first responder with didCommitLoadForFrame works
great if it is the only thing going on--like safari.
You could still use an approach like Safari's if you maintain some
state elsewhere in the app that your webview delegate can use to
determine whether the navigation was caused by other code in your app.
E.g., whenever your table view causes the webview to navigate to a
different page, it could set a flag somewhere that the delegate method
could test. It might be slightly more complicate to deal with the
asynchronous nature of page loading but the basic idea should work.
Most other appkit objects behave the way I would like the webkit to,
and I don't really understand why it releases the first responder
with every frame load or how to prevent it.
The view hierarchy in a webview can dynamically change when a new page
is visited -- when you go from one webpage to another the view that
was first responder might not even exist anymore. That's the basic
explanation for the current behavior.
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webkitsdk-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webkitsdk-dev/email@hidden
