Webbrowser.navigate does not work.
Use:
Me.myWebBrowserControl.Object.Navigate myUrl
-Tom.
Microsoft Access MVP
> Use:
> Me.myWebBrowserControl.Object.Navigate myUrl
Is there some good reason why they changed the commands for the new
web browser control?
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Well, actually I think the reason here is that we never had a old one. This
is a new Access control and it not a activeX one. It is native to access and
can bound like a text box (or say the new picture control. So you find this
control in the tool box now, not the activeX list.
So much of the way this control works is Access based. You can even use
access expressions based on concatenation of several other fields in the
form (parameters). Since this new web browser control can be bound to a
column in the form underlying data source then a simple navigation to a
different record or even code that changes the value of that column means
the web control will update to reflect the URL.
To display web pictures, web part photos, temperature data. Stock data or
even to display some HTML with JavaScript inside of a form then this control
has more uses then any possible control added to the tool box then I can
think of in all of access history.
Not only can you build up expressions like you can for any control such as a
text box, but you can also "save" the scroll position that you are viewing
into the web page. This is one major nice addition.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOO...@msn.com
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9D92B42652A98f9...@74.209.136.92...
>> Tom van Stiphout <tom7744...@cox.net> wrote in
>> news:tstt06t56f7bkiq76...@4ax.com:
>>
>>> Use:
>>> Me.myWebBrowserControl.Object.Navigate myUrl
>>
>> Is there some good reason why they changed the commands for the
>> new web browser control?
>
> Well, actually I think the reason here is that we never had a old
> one. This is a new Access control and it not a activeX one. It is
> native to access and can bound like a text box (or say the new
> picture control. So you find this control in the tool box now, not
> the activeX list.
Fair enough, but the no-Access ActiveX web browser control is so
ubiquitous that when the Mozilla project created a Gecko-based
ActiveX web browser control, they replicated the exact interface of
the IE control so that you could use it entirely interchangeably
(and I can verify that it works even in Access, including having all
the same problems, such as resizing, etc.).
> So much of the way this control works is Access based. You can
> even use access expressions based on concatenation of several
> other fields in the form (parameters). Since this new web browser
> control can be bound to a column in the form underlying data
> source then a simple navigation to a different record or even code
> that changes the value of that column means the web control will
> update to reflect the URL.
Can it display HTML that has not been saved to the file system or
stored in a rich-text field?
> To display web pictures, web part photos, temperature data. Stock
> data or even to display some HTML with JavaScript inside of a form
> then this control has more uses then any possible control added to
> the tool box then I can think of in all of access history.
Seems like only an incremental increase of functionality over the
non-Access web browser ActiveX control, though, certainly with much
less hassle.
> Not only can you build up expressions like you can for any control
> such as a text box, but you can also "save" the scroll position
> that you are viewing into the web page. This is one major nice
> addition.
Do you know if it is completely divorced from your installed IE
version? That is, is it using the installed version of IE as the
rendering engine, or is it using its own private rendering engine?
I agree that having such a control adds to Access' current and future
capabilities in a huge way. Kudos to Microsoft for implementing it.
James A. Fortune
CDMAP...@FortuneJames.com
I looked at the MVVM software pattern implemented through Visual
Studio and was impressed by some things, but not by others. A typical
implementation used data triggers to give it a seemingly magical
update condition. That didn't impress me much. The initial schema,
software and data binding were definitely much more involved than a
typical Access setup. What impressed me was that the final result
could automatically handle something that in Access would require
dynamic generation of subforms to accomplish.