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
