1) Add three variables:
// counter to monitor number of requests to BeforeNavigate2 vs number
of requests to DownloadBegin.
int m_nPageCounter;
// counter to monitor number of DownloadBegin and DownloadEnd calls.
int m_nObjCounter;
// variable to tell us whether a refresh request has started.
BOOL m_bIsRefresh;
2) In BeforeNavigate2 add:
m_nPageCounter++;
3) In DocumentComplete add:
m_nPageCounter--;
if( (m_bIsRefresh) && (m_nPageCounter == 0) && (m_nObjCounter == 0) )
{
//Refresh end
m_bIsRefresh = FALSE;
}
4) In DownloadBegin add:
m_nObjCounter++;
//Refresh started
if(m_nPageCounter == 0)
{
m_bIsRefresh = TRUE;
}
5) In DownloadComplete add
m_nObjCounter--;
//Refresh Ended
if( (m_bIsRefresh) && (m_nPageCounter == 0) && (m_nObjCounter == 0) )
{
m_bIsRefresh = FALSE;
}
Hope this helps
MH
Jan Ostedt
www.learnware.se
do you think about that
I doubt it. A refresh shouldn't look any different to an APP than a
regular navigation.
It's possible there is some tell-tale header (perhaps cache related)
that appears in a refresh request but not in a regular request, that you
could try and build a heuristic around. I haven't tried anything like
that myself, you are on your own.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Pay attention to BINDF flags you get from
IInternetBindInfo::GetBindInfo. There are a few flags that look
promising - e.g. BINDF_RESYNCHRONIZE.
>Pay attention to BINDF flags you get from
>IInternetBindInfo::GetBindInfo. There are a few flags that look
>promising - e.g. BINDF_RESYNCHRONIZE.
OK, I will do that. Thank you very much!
Best Regards
Jan
Best Regards
Jan
I don't think it's possible from an APP. An APP can abort the request,
but it can't pretend the request has never happened, as far as I can
tell.
I've seen it mentioned a few times (but haven't personally verified)
that you can implement IOleCommandTarget on the same object that
implements IOleClientSite (not sure how it's done in MFC), and when the
user hits Refresh the browser would call Exec on you with the command of
OLECMDID_PREREFRESH. I'm not sure what one can do from here to abort the
operation: perhaps return an error code, perhaps call
IWebBrowser2::Stop. Probably worth playing with.
>I've seen it mentioned a few times (but haven't personally verified)
>that you can implement IOleCommandTarget on the same object that
>implements IOleClientSite (not sure how it's done in MFC), and when the
>user hits Refresh the browser would call Exec on you with the command of
>OLECMDID_PREREFRESH. I'm not sure what one can do from here to abort the
>operation: perhaps return an error code, perhaps call
>IWebBrowser2::Stop. Probably worth playing with.
In my first post in this thread I wrote:
"I have implemented IOleCommandTarget in order to catch OLECMDID_PREREFRESH. I succeeded
to catch the call, but it seems to take place very late in the reload process (in spite of its name)"
So I have already tried to implement IOleCommandTarget, but I will give it another go. May be
I did something wrong. It seems strange that the OLECMDID_PREREFRESH appears late in the
refresh process. Is there anybody else in the group that has experience in this area?
Best Regards
Jan
>So I have already tried to implement IOleCommandTarget, but I will give it another go. May be
>I did something wrong. It seems strange that the OLECMDID_PREREFRESH appears late in the
>refresh process. Is there anybody else in the group that has experience in this area?
Now I have implemented IOleCommandTarget again and my tests reveal that the OLECMDID_PREREFRESH
actually appears very late in the refresh process, in spite of its name. The browser calls my IOleCommandTarget::Exec
many times before the OLECMDID_PREREFRESH shows up. Several of the calls have undocumented command IDs.
My intention is to detect and cancel refreshes caused by javascript location.reload(false) and location.reload(true). So
I decided to see if it was at all possible to cancel the refresh at this stage. So at the first call to
IOleCommanTarget::Exec (and at subsequent calls) after a refresh I tried to cancel the operation. First I tried
different return values but that didn't help so I changed to IWebBrowser2::Stop, which made the refresh stop, but I
ended up with a blank page instead of the original one. Very similar to what happened when I tested my PassThruApp
approach. Unfortunately it seems like this approach doesn't work either. Is there anybody in the group that has ideas
about how a javascript.reload operation can be detected and canceled? Suggestions would be greatly appreciated.
Best Regards
Jan
Best Regards
Jan