By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,098 Members | 1,895 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,098 IT Pros & Developers. It's quick & easy.

Using the Web Browser Control to Browse for a File

P: n/a
I am using Microsoftís Web Browser Control embedded on an Access Form to
browse a specific site. I have a good reason for doing so; the pages on
this site run code which aborts their display unless their window is the
top window; they also treat all child windows as not-logged in windows. So
I have not accomplished what I want with HTAís or IFrames or Pop-Up
Windows. But the Access Form/MS Web Browser combination gives me a top
window with the site in a logged in state while allowing me to manipulate
it and its contents with code in the Access form module. Fabulous!

Part of my application requires browsing the local machine for a file. The
web browser has a nice gui for this; all one has to do is navigate to the
drive or folder wanted in code (.Navigate file://path) and then the gui
takes over. I thought I would use the web browser in the spirit of design
efficiency; since the user must use the web browser for the web site
browsing, why not use the same control for file browsing. But I cannot find
any way to identify the file checked. (Bear in mind that in Access I cannot
use the extended properties and methods of the web browser available in
..NET 2.0). Do you know a way?

If I donít come up with anything tomorrow Iíll put a file input on the web
browserís document body. I am 99 44/100ths% sure this will work fine. But I
feel I should not have to do it.

I suppose you may suggest other ways. Please, remember that whatever I use,
it must act as a top window, it must have a rich collection of properties
and methods, and it must be code-able as an object in the form/application.
Iím thoroughly familiar with API file browsing having written my own
manifestation of it many years ago; but Iíll use it only as a last resort.
I want to make the web browser tell me the name/path of the file I have
clicked!

--
Lyle Fairfield
Sep 19 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
It's relatively simple to determine which File/Folder has been selected.
What I don't see is an easy Event to tag onto.

Look at the Document property of the WebBrowser control. When the control is
in Explorer mode the Document property containes a valid FocusedItem prop
that will point to a File or Folder(via its GetFolder prop). There's even a
seperate Boolean prop to signal whether we are dealing with a Folder or not

While you can use the WBrowser_StatusTextChange event it's not the proper
way to go and its a bitch to work with(debug).
I have no experience in hooking WebBrowser control events but there's got to
be sample VB code out there somewhere.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"Lyle Fairfield" <ly***********@aim.comwrote in message
news:Xn*********************************@216.221.8 1.119...
>I am using Microsoft's Web Browser Control embedded on an Access Form to
browse a specific site. I have a good reason for doing so; the pages on
this site run code which aborts their display unless their window is the
top window; they also treat all child windows as not-logged in windows. So
I have not accomplished what I want with HTA's or IFrames or Pop-Up
Windows. But the Access Form/MS Web Browser combination gives me a top
window with the site in a logged in state while allowing me to manipulate
it and its contents with code in the Access form module. Fabulous!

Part of my application requires browsing the local machine for a file. The
web browser has a nice gui for this; all one has to do is navigate to the
drive or folder wanted in code (.Navigate file://path) and then the gui
takes over. I thought I would use the web browser in the spirit of design
efficiency; since the user must use the web browser for the web site
browsing, why not use the same control for file browsing. But I cannot
find
any way to identify the file checked. (Bear in mind that in Access I
cannot
use the extended properties and methods of the web browser available in
.NET 2.0). Do you know a way?

If I don't come up with anything tomorrow I'll put a file input on the web
browser's document body. I am 99 44/100ths% sure this will work fine. But
I
feel I should not have to do it.

I suppose you may suggest other ways. Please, remember that whatever I
use,
it must act as a top window, it must have a rich collection of properties
and methods, and it must be code-able as an object in the
form/application.
I'm thoroughly familiar with API file browsing having written my own
manifestation of it many years ago; but I'll use it only as a last resort.
I want to make the web browser tell me the name/path of the file I have
clicked!

--
Lyle Fairfield

Sep 19 '06 #2

P: n/a
Thanks Stephen

FocusedItem works well but, as you point out, there seems to be no easy
way to monitor the selection event. Worse, clicking on the file opens
it, which I don't want to do.
So, I think I'll retreat to the GetOpenFileName comdlg32 API function.

Stephen Lebans wrote:
It's relatively simple to determine which File/Folder has been selected.
What I don't see is an easy Event to tag onto.

Look at the Document property of the WebBrowser control. When the control is
in Explorer mode the Document property containes a valid FocusedItem prop
that will point to a File or Folder(via its GetFolder prop). There's even a
seperate Boolean prop to signal whether we are dealing with a Folder or not

While you can use the WBrowser_StatusTextChange event it's not the proper
way to go and its a bitch to work with(debug).
I have no experience in hooking WebBrowser control events but there's got to
be sample VB code out there somewhere.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"Lyle Fairfield" <ly***********@aim.comwrote in message
news:Xn*********************************@216.221.8 1.119...
I am using Microsoft's Web Browser Control embedded on an Access Form to
browse a specific site. I have a good reason for doing so; the pages on
this site run code which aborts their display unless their window is the
top window; they also treat all child windows as not-logged in windows. So
I have not accomplished what I want with HTA's or IFrames or Pop-Up
Windows. But the Access Form/MS Web Browser combination gives me a top
window with the site in a logged in state while allowing me to manipulate
it and its contents with code in the Access form module. Fabulous!

Part of my application requires browsing the local machine for a file. The
web browser has a nice gui for this; all one has to do is navigate to the
drive or folder wanted in code (.Navigate file://path) and then the gui
takes over. I thought I would use the web browser in the spirit of design
efficiency; since the user must use the web browser for the web site
browsing, why not use the same control for file browsing. But I cannot
find
any way to identify the file checked. (Bear in mind that in Access I
cannot
use the extended properties and methods of the web browser available in
.NET 2.0). Do you know a way?

If I don't come up with anything tomorrow I'll put a file input on the web
browser's document body. I am 99 44/100ths% sure this will work fine. But
I
feel I should not have to do it.

I suppose you may suggest other ways. Please, remember that whatever I
use,
it must act as a top window, it must have a rich collection of properties
and methods, and it must be code-able as an object in the
form/application.
I'm thoroughly familiar with API file browsing having written my own
manifestation of it many years ago; but I'll use it only as a last resort.
I want to make the web browser tell me the name/path of the file I have
clicked!

--
Lyle Fairfield
Sep 19 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.