Common Dialog In WSH?
Ken Webster
already....
I'd like to display a file selection dialog from WSH like the system common
dialog. I can think of a couple really complicated ways to do it, like
create an object in VB that wraps the dialog control, but I know this is
probably a problem that's already been solved by just about everybody.
Suggestions?
Thanks in advance,
Ken Webster
Michel Gallant (MVP)
&H4000 (the constant BIF_browseincludefiles (&H4000) to allow
file browsing:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/Shell/reference/objects/shell/browseforfolder.asp
- Michel Gallant
MVP Security
http://home.istar.ca/~neutron
Ken Webster
Pro.
Thanks...
"Greg Shultz" <gsh...@optimator.win.net> wrote in message
news:#0LvVvDgCHA.2400@tkmsftngp11...
> Ken:
>
> If you're using Windows XP, the User Accounts tool - Nusrmgr.cpl - in the
> Control Panel exposes/provides access to a standard Open dialog box.
>
> To access it use this code snippit:
>
> Set WshShell = WScript.CreateObject("WScript.Shell")
> Set UA = CreateObject("UserAccounts.CommonDialog")
> x = UA.ShowOpen
> WScript.echo x ' Check if user click Cancel
> WScript.echo UA.FileName ' Display selected file
>
> Greg Shultz
> The Windows Wizard
> Gr...@TheWinWiz.com
>
> Check my Web site for links to a wide variety of computer how-to articles!
> www.TheWinWiz.com
>
>
>
>
>
>
> "Ken Webster" <kweb...@dialpoint.net> wrote in message
> news:KCUv9.30753$ku2.1...@twister.southeast.rr.com...
Joe Earnest
Ken may not be able to use this, but I sure can. Thanks.
Regards,
Joe Earnest
"Greg Shultz" <gsh...@optimator.win.net> wrote in message
news:#0LvVvDgCHA.2400@tkmsftngp11...
> Ken:
>
> If you're using Windows XP, the User Accounts tool - Nusrmgr.cpl - in the
> Control Panel exposes/provides access to a standard Open dialog box.
>
> To access it use this code snippit:
>
> Set WshShell = WScript.CreateObject("WScript.Shell")
> Set UA = CreateObject("UserAccounts.CommonDialog")
> x = UA.ShowOpen
> WScript.echo x ' Check if user click Cancel
> WScript.echo UA.FileName ' Display selected file
>
> Greg Shultz
> The Windows Wizard
> Gr...@TheWinWiz.com
>
> Check my Web site for links to a wide variety of computer how-to articles!
> www.TheWinWiz.com
>
>
>
>
>
>
> "Ken Webster" <kweb...@dialpoint.net> wrote in message
> news:KCUv9.30753$ku2.1...@twister.southeast.rr.com...
Ken Webster
documentation how it returned the reference for the file- it says it returns
a folder object.
"Michel Gallant (MVP)" <neu...@istar.ca> wrote in message
news:3DC01E82...@istar.ca...
Greg Shultz
If you're using Windows XP, the User Accounts tool - Nusrmgr.cpl - in the
Control Panel exposes/provides access to a standard Open dialog box.
To access it use this code snippit:
Set WshShell = WScript.CreateObject("WScript.Shell")
Set UA = CreateObject("UserAccounts.CommonDialog")
x = UA.ShowOpen
WScript.echo x ' Check if user click Cancel
WScript.echo UA.FileName ' Display selected file
Greg Shultz
The Windows Wizard
Gr...@TheWinWiz.com
Check my Web site for links to a wide variety of computer how-to articles!
www.TheWinWiz.com
"Ken Webster" <kweb...@dialpoint.net> wrote in message
news:KCUv9.30753$ku2.1...@twister.southeast.rr.com...
Michel Gallant (MVP)
-----------------------
Const BIF_returnonlyfsdirs = &H0001
Const BIF_browseincludefiles = &H4000
Set oShellApp = WScript.CreateObject("Shell.Application")
Set oItem = oShellApp.BrowseForFolder( _
&H0, "Select a file or folder", _
BIF_returnonlyfsdirs + BIF_browseincludefiles, &H0)
----------------------
There is an excellent discussion of this in:
"Microsoft Windows Script Host 2.0 Developer's Guide"
Gunter Born
2000 Microsoft Press.
Ch. 12 "Using the Browse For Folder Dialog Box"
- Mitch
Tom Lavedas
Michel Gallant, here is an approch that I use ...
' For example, ...
Wscript.echo ChooseFile("C:\")
' Adapted by Tom Lavedas from an example by Walter Zackery
' Requires WSH v2+ (aka 5.1+) to set StartIn location
Function ChooseFile(StartIn)
set IEApp = CreateObject("InternetExplorer.Application")
IEApp.fullscreen = true ' required for absolute positioning of ULC
IEApp.Navigate("about:blank")
IEApp.Left = 300 : IEApp.Top = 200 ' position Upper Left Corner
(ULC)
While IEApp.Busy
if Wscript.Version > 5 Then WSH.Sleep 100
Wend
set oDoc = IEApp.document
oDoc.Write("<input id=file type=file"_
& " style='position:absolute; left:0; top:0'>")
oDoc.all.file.focus
if Wscript.Version > 5 Then
CreateObject("Wscript.Shell").Sendkeys StartIn
WSH.Sleep 200
End if
oDoc.all.file.click ' opens dialog window
' The file dialog is modal, so no wait loop is required.
ChooseFile = oDoc.all.file.value
set oDoc = Nothing
set IEApp = Nothing
if ChooseFile = StartIn Then ChooseFile = "" 'that is, Cancelled
End Function ' ChooseFile
It makes use of IE's <INPUT TYPE=FILE> control and Sendkeys to
pre-load a search location. I have read that the '.fullscreen = true'
trick may be broken when IE 6 is the browser, but I have no way of
testing that.
Other than that, the dialog sure looks identical to the Common Dialog
control (without the licensing issue).
Tom Lavedas
===========
"Ken Webster" <kweb...@dialpoint.net> wrote in message news:<j_Uv9.30887$ku2.1...@twister.southeast.rr.com>...
Joe Earnest
Can you get BrowseForFolder to work properly
with file selections on WinXP? A few of us were
discussing this in a thread below. The routine works
fine for us on older OS's, but seems buggy in WinXP.
We get an error we can't circumvent in WinXP when
a file is selected.
Per the discussion below, I experimented with
BrowseForFolder and the User Accounts Common
Dialog on WinXP, both of which are disappointing.
I would greatly appreciate your comments.
With BrowseForFolder, I was able to identify the
bit values for a couple of the new configuration flags
that MSDN mentions as available for version 6.0, but
found that a number of the older ones didn't seem to
work anymore. Worse yet, I can't seem to find a way
to avoid the error generated when a file is selected.
This behavior does not seem to be intended, since
MSDN mentions new flags for retrieving urls and links.
But I can't find a way around it. Based on my
experimentation, these are the configuration parameters
that actually work with WinXP.
ShellApp.BrowseForFolder
Set oShellApp= CreateObject("Shell.Application")
Set oBrowse= oShellApp.BrowseForFolder _
(0, "message", configuration, ["]root folder["])
message: 2 short lines max
root folder: folder string or system folder code
configuration: integer bitwise code
0001 1 only return file system folders
(do not return virtual folders)
0002 2 do not include network folders
below domain level
0010 16 include edit box
0020 32 validate user specification
(use with 0010)
0100 256 display hint (not with 0010)
0200 512 no new folder button
4000 16384 also display files
(error, if selected)
return: oBrowse setting
OK, Enter: oBrowse set as Folder String/Object
Cancel, Esc, [x]: oBrowse set as Nothing Object
The User Accounts Common Dialog appears to be
pre-formatted and extremely limited. It accepts only a
couple of the voluminous VB Common Dialog settings.
Worse yet, it only responds to .ShowOpen and not to
.ShowSave or any of the other actions. Nor will it even
return the flag from the fixed open-as-read-only checkbox.
Based on my experimentation, these are the configuration
parameters that actually work.
UserComDlg.ShowOpen
Set oUserComDlg= _
CreateObject("UserAccounts.CommonDialog")
configuration:
oUserComDlg.FileName=
default file string
must include file name or mask
oUserComDlg.Filter=
string of file descriptions and masks
"Description (mask)|*.ext [;...]][|...]"
oUserComDlg.FilterIndex=
1-based default filter; defaults to 1
return: oComDlg.ShowOpen setting
OK, Enter: oComDlg.ShowOpen set to True
oComDlg.FileName contains selection
Cancel, Esc, [x]: oComDlg.ShowOpen set to False
Regards,
Joe Earnest
"Michel Gallant (MVP)" <neu...@istar.ca> wrote in message
news:3DC036CF...@istar.ca...
| Simple example (to browse files and folders on the desktop):
| -----------------------
| Const BIF_returnonlyfsdirs = &H0001
| Const BIF_browseincludefiles = &H4000
|
| Set oShellApp = WScript.CreateObject("Shell.Application")
| Set oItem = oShellApp.BrowseForFolder( _
| &H0, "Select a file or folder", _
| BIF_returnonlyfsdirs + BIF_browseincludefiles, &H0)
| ----------------------
|
| There is an excellent discussion of this in:
| "Microsoft Windows Script Host 2.0 Developer's Guide"
| Gunter Born
| 2000 Microsoft Press.
| Ch. 12 "Using the Browse For Folder Dialog Box"
|
| - Mitch
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.391 / Virus Database: 222 - Release Date: 09-19-02
Michel Gallant (MVP)
Haven't read other thread, but there were some bugs with
that browserforfolder discussed by G. Born some time ago
in German groups (I think).
- Mitch
Joe Earnest wrote:
> Mitch,
>
> Can you get BrowseForFolder to work properly
> with file selections on WinXP? A few of us were
> discussing this in a thread below. The routine works
> fine for us on older OS's, but seems buggy in WinXP.
> We get an error we can't circumvent in WinXP when
> a file is selected.
>
- snip
Alex K. Angelopoulos (MVP)
window that uses a dialog and has a GetRef pointing back to a function in the
main WSH/HTA script.
In news:3DC3E6DE...@istar.ca,
Michel Gallant (MVP) typed:
--
Please respond in the newsgroup so everyone may benefit.
http://dev.remotenetworktechnology.com
----------
Subscribe to Microsoft's Security Bulletins:
http://www.microsoft.com/technet/security/bulletin/notify.asp
Joe Earnest
Thanks. At least I know it's not me.
Regards,
Joe Earnest
"Alex K. Angelopoulos (MVP)" <a...@mvps.org> wrote in message
news:OEgY6QpgCHA.4128@tkmsftngp08...
| Yeah, it doesn't work for XP. I'm stuck with using a secondary popped-up
IE
| window that uses a dialog and has a GetRef pointing back to a function in
the
| main WSH/HTA script.
---
Alex K. Angelopoulos (MVP)
replacement, but what I REALLY want to do is get a universal common dialog
tool...Maybe a common dialog "wrapped" in an ActiveX EXE.
In news:#fg4KrqgCHA.2448@tkmsftngp10,
Joe Earnest typed:
--
Joe Earnest
(After reviewing my digessive ramblings
below, I fear you may regret your
question -- like politely asking someone
on the street how they're doing, only to
hear in detail about experiences of the last
several months.)
I'm coming around to your point of view.
I've never hesitated to use or distribute
AutoItX, but I've steered clear of other
ActiveX's and add-ons in the past. It
would awfully nice, however, to have
the Common Dialog and some other
general routines in a single add-on.
Would you need MS approval to
distribute the Common Dialog in that
form? I sense that MS is not eager to
enhance VBScript these days.
I've been working in different directions.
BrowseForFolders still works for folders,
but seems to be stripped of most of its
versatility. In WinXP, you automatically
get the expanded dialog box, but only the
following bitflags seem to actually do
anything.
0001 only return file system folders
0010 include edit box
0020 validate user edit box specification
0100 display hint (not with 0010)
0200 no new folder button
4000 also display files (error if selected)
Greg Schultz posted a reference to the
User Accounts Common Dialog last week,
and it looked as if it might have promise. After
playing around with it yesterday and today, it
seems to be hard-formatted and extremely
limited. It accepts only a couple of the most
basic VB Common Dialog settings. And it
only responds to .ShowOpen and not to
.ShowSave or any of the other VB actions.
Nor will it even send or return the VB flags.
But even in this crippled condition, it's as
good as BrowseForFolder was for single file
selections -- in fact, a little better. The
following demonstrates *all* of the options
that I was able to get to work.
----sample-script----
Set oComDlg= _
CreateObject("UserAccounts.CommonDialog")
oComDlg.FileName= "C:\Windows\explorer.exe"
oComDlg.Filter= "All Files (*.*)|*.*|" _
& "Executable Files (*.exe)|*.exe|" _
& "Text Files (*.txt *ini *vbs *eml *nws)|" _
& "*.txt;*.ini;*.vbs;*eml;*nws"
oComDlg.FilterIndex= 2
Select Case oComDlg.ShowOpen
Case True: MsgBox "Selection:" & vbTab _
& oComDlg.FileName,, "Test Script"
Case False: MsgBox "Cancelled.",, _
"Test Script"
End Select
----end-script----
I've written a generic popup function
from which to variously call and configure
the MsgBox, InputBox, Shell.Popup,
BrowseForFolder and now the User
Common Dialog, as needed.
I've also written a stepped set of generic
vbs functions for IEApp dialog windows,
which allow setting fairly customized and
stylized dialog windows without writing
html. I've just started actually using it. It
allows for very brief main level code, but
the supporting function code is massive
(and may never be fully error checked).
It sets up a simply coded dialog window
with optional (1) title and top text, (2) a
generated table for controls, (3) bottom
text, and (4) very bottom exit pushbuttons.
Control type and location are given by cell
reference, and it uses ^character coding for
basic html format codes, access keys, etc.
There are two in-line functions. The first
writes everything except the body, so that
that function can be used alone for html
document or inner text windows, as well
as complex dialogs and run situations. The
second dialog writes the body code
described above, sends it to the other and
runs the dialog window.
Unfortunately, the IEApps are always
highly personalized and tempermental, and
will never replace a rock solid, universally
understood utility dialog that is fully defined
in the interpretive program. That's why I'm
coming around to add-on-is-needed point
of view.
Regards,
Joe Earnest
"Alex K. Angelopoulos (MVP)" <a...@mvps.org> wrote in message
news:eM7VmtqgCHA.2392@tkmsftngp08...
| What are you doing as workarounds?
---
Alex K. Angelopoulos (MVP)
In news:uiJaevrgCHA.2448@tkmsftngp10,
Joe Earnest typed:
> Hi Alex,
>
> (After reviewing my digessive ramblings
> below, I fear you may regret your
> question -- like politely asking someone
> on the street how they're doing, only to
> hear in detail about experiences of the last
> several months.)
>
> I'm coming around to your point of view.
> I've never hesitated to use or distribute
> AutoItX, but I've steered clear of other
> ActiveX's and add-ons in the past. It
> would awfully nice, however, to have
> the Common Dialog and some other
> general routines in a single add-on.
More below...
> Would you need MS approval to
> distribute the Common Dialog in that
> form?
You need to have a license for the common dialogs to use them. By buying a VB
compiler, you acquire the right to redistribute it with an application I
believe, so writing a wrapper for it in VB fits the bill.
> I sense that MS is not eager to
> enhance VBScript these days.
As a company, that's not the direction Microsoft is going. The actual WSH
developers may have general opinions about that, but it is pretty definite that
the next thing we could expect as far as Microsoft-based development is a .NET
framework based scripting language. Whatever is going to replace VBA and IE
scripting is it.
Based on the floor for the .NET runtimes and the apparent target platform for
the next Office version, I would guess that "WSH.NET" is also going to not run
on anything less than Windows 2000. There will be some concomitant issues as
well - memory and speed floor will probably be high due to the underlying
framework requirements.
I think we can count on the developers to fight pretty hard for compatibility -
they know that WSH works, is flexible, and is _still_ growing in terms of use -
but they will have limits in what they can do.
In counterpoint to that, WSH as-is will probably be supported for at least
another 2 server release levels, so anything that works in WSH now - or any
"added" components - will be still usable for the next few years.
> I've been working in different directions.
>
> BrowseForFolders still works for folders,
> but seems to be stripped of most of its
> versatility.
> Greg Schultz posted a reference to the
> User Accounts Common Dialog last week,
> and it looked as if it might have promise.
>
> ----sample-script----
> ----end-script----
That's STILL pretty good!
> I've written a generic popup function
> from which to variously call and configure
> the MsgBox, InputBox, Shell.Popup,
> BrowseForFolder and now the User
> Common Dialog, as needed.
Post them... people would like to see them.. <g>
> I've also written a stepped set of generic
> vbs functions for IEApp dialog windows...
>
> Unfortunately, the IEApps are always
> highly personalized and tempermental, and
> will never replace a rock solid, universally
> understood utility dialog that is fully defined
> in the interpretive program. That's why I'm
> coming around to add-on-is-needed point
> of view.
I'd like to see generalized generic script-extension functions. For one thing,
it will reduce the required memory footprint dramatically compared to IE
manipulation. For another, there are literally thousands of pre-written classes
out there capable of doing much of this if compiled in VB or C++. This also
leaves the door open for simple additions which are hard to do from script or
always require "special" tools. An Uptime property, for example, can do in 4
lines of code what takes about 20 lines and a winmgmt moniker otherwise.
Here's a suggested target spec:
+ PLATFORM:
Should support all current WSH-able platforms for non-domain tasks (dialogs,
etc.) - this means Win95 and up. Security stuff should be NT4 and higher.
+ REQUIREMENTS:
Minimal. Since they are free and can be installed on everything, dependency on
the standard VB5/6 runtimes and WSH 5.6 should be OK. Any special extensions
should stay away from tools such as IE which may get broken regularly.
A questionable issue is that of attempting to use things from Shell32.dll, since
certain systems do not have the IE4 version installed (and some of those, such
as NT4 Terminal Server, CANNOT have it installed).
+ HOSTING:
It should be hostable by wscript and cscript, and be usable from any tool that
supports COM automation, BUT should not be marked safe for use from IE. This
eliminates the largest possible source of headaches we could have.
+ CAPABILITIES:
It should address the key issues that scripters have (particularly admins). The
following come to mind:
- universal open/save/browse dialogs
- access to some functionality not available for downlevel clients natively or
which take excessive hoop-jumping to do. For example, a generalized "shutdown"
function.
- possible improvements to things such as the Dictionary object - say a sorted
dictionary class.
Things it should NOT cover: I wouldn't even touch what is done by AutoItX -
after all, it handles the standard UI stuff really well.
+ AVAILABILITY:
It would be nice to make it an "open" tool for admins. That could make it a
usable, deployable standard. It should probably be wrapped for deployment
within an MSI to make it easily AD-deployable.
+ CONVENTIONS:
Standard naming would probably be a good idea. The core classname would be
something like WshX (for WSH eXtensions). The subclasses would then be things
like this:
WshX.CDlg (common dialogs)
WshX.Registry (registry walking/manipulation)
Wshx.System (uptime, reboot, etc)
> Regards,
> Joe Earnest
>
> "Alex K. Angelopoulos (MVP)" <a...@mvps.org> wrote in message
> news:eM7VmtqgCHA.2392@tkmsftngp08...
>> What are you doing as workarounds?
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.391 / Virus Database: 222 - Release Date: 09-19-02
--
Joe Earnest
| > Greg Schultz posted a reference to the
| > User Accounts Common Dialog last week,
| > and it looked as if it might have promise.
|
| That's STILL pretty good!
Well, it is for vbs, but compared to what the
Common Dialog can really do, it bites. And
still no hope of a "Save As".
| Post them... people would like to see them.. <g>
Not so sure. Voluminous personalized routines
with learning curves don't get a lot of attention.
And when I signed on this morning, I got about
20 emails from the newsgroup that all my old
attachments were being stripped. Kinda
insulting: They refer to them as a "virus" named
"unauthorized attachment". If the MS newsgroup
is going to strip all the vbs attachments passed
back and forth, it's really going to limit exchange.
| I'd like to see generalized generic script-extension functions.
Agreed, if they're standardized and widely accepted,
so they can be distributed with scripts without a lot
of explanation. I fear that that's the trick. Designing
them just takes a good mind and experience like yours.
But getting general acceptance without at least a tacit
stamp of approval from MS (like powertoys) ...
No a bad idea though. Maybe you can call them
powertoys for scripting.
| Here's a suggested target spec:
You've obviously given this a lot of thought. If I'm
a first level sanity check, then I wholeheartedly agree
and suggest you run the idea at a higher level.
| + PLATFORM:
| Should support all current WSH-able platforms for non-domain tasks
(dialogs,
| etc.) - this means Win95 and up. Security stuff should be NT4 and higher.
I wouldn't worry much about Win95. MS is doing
a pretty good job of coercing it into nonexistence.
I agree with the rest. *But* you might consider a
more limited goal with just Win2k and WinXP. The
known built-ins would make design *much* easier
and probably much cleaner in terms of parameters
and arguments. *But* that will lose a lot of local
network admins for businesses that will never
upgrade Win98/WinNT. On the DOS side, Win98
is probably the only system that you really need to
focus on. I personally like WinMe, but it never
caught on with businesses, and MS abandoned it
pretty quick. I wouldn't automatically sacrifice
simplicity (i.e., inherent error-free operation) for
comprehensiveness.
| + REQUIREMENTS:
| Minimal. Since they are free and can be installed on everything,
dependency on
| the standard VB5/6 runtimes and WSH 5.6 should be OK. Any special
extensions
| should stay away from tools such as IE which may get broken regularly.
| A questionable issue is that of attempting to use things from Shell32.dll,
since
| certain systems do not have the IE4 version installed (and some of those,
such
| as NT4 Terminal Server, CANNOT have it installed).
Agreed, if you stay with the broad approach.
In that case, I think the add-on should use its own
internal code as much as possible.
| + HOSTING:
|
| It should be hostable by wscript and cscript, and be usable from any tool
that
| supports COM automation, BUT should not be marked safe for use from IE.
This
| eliminates the largest possible source of headaches we could have.
Agreed, given your scope.
| + CAPABILITIES:
| It should address the key issues that scripters have (particularly
admins).
Yes. The admins will make it or break it.
But, I'd personally like to see something that
helps the intelligent, knowledgable user. A lot
of small business owners still administer their
own computers. It's bucking the trend, but I
still believe that a knowledgable user should
have personal control over his or her own
computer, and be able to make it do what he or
she reasonably wants it to do. A great number
of users successfully learned and used
QuickBASIC in the DOS days. There has not
been that level of acceptance of vbs in the
general user group, in part because times have
changed, but in large part because object
orientation is a much more difficult, time
consuming and obscure concept for many
people. Keeping a subset of the basic
add-ons (such as the Common Dialog, local
registry and file stuff, etc.) fully internal with
cookbook parameters would help the average
user immensely, and probably generate some
volume in acceptance. (Please forgive the
polemic.)
| - universal open/save/browse dialogs
| - a generalized "shutdown" function
I think everyone would agree. Also,
masked password input gets a lot of play,
and you might think of simplified process
issues.
| Things it should NOT cover: I wouldn't even touch what is done by
AutoItX -
| after all, it handles the standard UI stuff really well.
AutoItX already has the universal shutdown,
but some duplication would be ok. Not
everyone would need both. I agree that there
is no need to duplicate windowing operations.
I'm not aware of another add-on (other than
RegObj, which had tacit MS approval) with
that level of acceptance.
| + AVAILABILITY:
| It would be nice to make it an "open" tool for admins. That could make it
a
| usable, deployable standard. It should probably be wrapped for deployment
| within an MSI to make it easily AD-deployable.
This is more your area than mine.
| + CONVENTIONS:
| Standard naming would probably be a good idea. The core classname would
be
| something like WshX (for WSH eXtensions). The subclasses would then be
things
| like this:
| WshX.CDlg (common dialogs)
| WshX.Registry (registry walking/manipulation)
| Wshx.System (uptime, reboot, etc)
Your baby -- your names. ;-) Actually, I
think they're good, intuitively obvious names.
I might personally use ComDlg instead of
CDlg for wider recognition.
Regards,
Joe Earnest
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.410 / Virus Database: 231 - Release Date: 10-31-02
Joe Earnest
Since my last reply wasn't long enough,
and since the 15th cup of coffee has now
percolated through the little remaining gray
matter, I thought of a couple of additional
items that there is a need for:
1) a simple modeless notice box;
2) a combo box where text and basic
controls (input, checkbox, radio button,
definable pushbuttons) can be mixed and
returned, preferrably with color and
formatting.
In fact, an add-on that just provided the
Common Dialog and the above would
likely see wide usage among general users,
even without the other additions.
Unfortunately, I am not a VB programmer
(don't even own a copy) -- cut my teeth on
MASM, home-built assembly programming
and various BASIC in DOS days (fortunately
including QuickBASIC as training for vbs),
and have just done various script, html
and macros since 32-bit windows.
Combo boxes are always a problem to
lay out in a simple enough format. I
struggled with it in my own dialog
and came up with the following. (This
is just the documentation to my IEApp
dialog function and the character code
function called, with an example of use.)
If you want the code, let me know.
(I compile in a macroed word processor.
Dumping into text and adapting for wrap
makes the documentation less readable,
of course.)
----
Example (title text, subtext, row of checkboxes,
row of radio buttons with two pushbuttons)
usTitTxt= "^+2^bSystem Setup^b^f^30%" _
& "^iInstall Standard System Components^i^90%"
usBtmTxt= "^90%"
usDlgSpec= "t|System Setup<>c|a<>s|600|340"
usCtrlSpec= _
"c/0" & Left("/x", Abs(unId=0) *2) _
& "| ^bWrite Computer ~Name^b<>" _
& "c/10/x| ^bGeneral ~Registry Modifications^b<>" _
& "c/20/x| ^b~Program ID Modifications^b<>" _
& "c/30/x| ^bSystem ~File Modifications^b<>" _
& "c/40/x| ^bCreate ~Desktop.ini Files^b<>" _
& "c/50/x| ^bReorganize the Programs ~Menu^b<>" _
& "c/60/x| ^bReorganize Desktop and Favorites ~Links^b<>" _
& "t/01| <>" _
& "t/02/a=c| Select Computer<>" _
& "r/22| ^b~1. Basic Group^b<>" _
& "r/32| ^b~2. Reception Group^b<>" _
& "r/42| ^b~3. Executive Group^b<>" _
& "r/52| ^b~4. Admin Office^b<>" _
& "p/f=2/1=Red,White/2=Black,White|^b~Setup System^b|^b E~xit ^b"
If NOT qIEDlg(usDlgSpec, usTitTxt, usCtrlSpec, usBtmTxt, True, uxSlns) _
Then _
xPopup usTermCfg & "InternetExplorer.Application Error", _
"An error was encountered displaying|" _
& "and/or executing the main dialog window.||" _
& "The script will now terminate.|"
---
Function qIEDlg (ByVal vsDlgSpec, ByVal vsTitleText, _
ByVal vsCtrlSpec, ByVal vsBtmText, ByVal vqRunDlg, _
ByRef rxSlns)
' compiles, displays and optionally runs
' InternetExplorer.Application centered dialog
' returns boolean operation flag
' True dialog displayed and optionally run
' False vxCtrlSlns redimension error, if dialog run in procedure
' oIEApp access or navigation error
' accesses/creates oIEApp, oAIX or oShell (if AIX not accessible)
' calls qErr, qIEWin, qObject, xCInt, xClear, xCSng, xCStr,
' xReplTextCodes, xSplit
' simple centered layout table dialog style
' title/upper text + control/text layout table +
' bottom text + exit pushbuttons
' all controls other than pushbuttons in table
' (99 rows x 9 columns maximum), one control per cell
' if oAIX accessible, aborts if already exists,
' activates window when created and retitles it
' vsDlgSpec compound dialog specification string
' multiple elements <> delimiter ( "...1...<>...2...<>...3..." )
' standard element id [ / option [ / ... ] ] [ | data [ | ... ] ]
' T [ itle ] title bar and taskbar title for dialog
' | xxx title string
' use ^\ for pipe ( | ) character, if necessary
' null/nc default "Dialog"
' S [ ize ] dialog size
' | n | n numeric width | numeric height
' .01-.99 percentage of available screen width or height
' 1+ specified width or height (preferred)
' null/nc default .50 | .50
' F [ ont ] dialog font
' | x | n font name string | numeric size (6-24 pts)
' null/nc default Arial | 10
' C [ olor ] dialog background color
' | x background color id, name or specification string
' A aquamarine (#6FEFD4)
' B LightBlue (HTML defined color)
' C LightCyan (HTML defined color)
' L lavender (#CCCCEE)
' P Windows popup (#D4D0C8)
' R red (#FFB6C1)
' V light lavender (#E6E6FA)
' W WhiteSmoke (HTML defined color)
' Y LightYellow (HTML defined color)
' name HTML defined color name
' #hhhhhh HTML formatted hex color specification
' null/nc default default white
' null/nc default default settings
' vsTitleText encoded dialog title
' and upper text dialog message string
' appears at top of dialog, above controls;
' uses HTML body (all) ^ text codes
' null/nc default no title or upper text; bad codes ignored
' vsCtrlSpec compound control
' and layout table text specification string
' multiple elements <> delimiter ( "...1...<>...2...<>...3..." )
' standard element id [ / option [ / ... ] ] [ | data [ | ... ] ]
' common table all table controls and text (not pushbuttons)
' /n [ - n ] numeric (initial) table cell specifier (00-999)
' + (final) table cell span specifier (01-999)
' forward spanning only
' specifier row (0-99) *10 + column (0-9)
' null default no spanning
' null/nc default initial cell 00
' element ignored, if conflict
' no spanning, if conflict
' /A= x horizontal alignment in cell (per column width)
' L left-aligned
' R right-aligned
' C center-aligned
' null/nc default L (left-aligned)
' /V= x vertical alignment in cell (per row height)
' T top-aligned
' B bottom-aligned
' M middle-aligned
' null/nc default M (middle-aligned)
' | xxx first data listed
' table text encoded text string
' ^ character and HTML general ^ text codes
' null/nc default element ignored
' controls encoded external prompt string (~ access code)
' ^ character and HTML general ^ text codes
' null/nc default no prompt
' P [ ushbutton ] exit pushbuttons
' /F= n pushbutton number for initial focus (1+)
' null/nc default no initial pushbutton focus
' /S= n numeric inter-pushbutton spacing (1+)
' null/nc default 4
' /C= x [ , x ] color specification string for all pushbuttons
' "background color , text color"
' S special configuration
' 1st Red , White
' middle dialog background color , black
' last Black , White
' X dialog background color , default black
' name HTML defined color name
' #hhhhhh HTML formatted hex color specification
' null/nc default default gray , default black
' /n= x [ , x ] individual button number color specification string
' "background color , text color"
' overrides /C for specific button
' B DarkBlue , White
' K Black , White
' P Windows popup (#D4D0C8) , default black
' R Red , White
' X dialog background color , default black
' name HTML defined color name
' #hhhhhh HTML formatted hex color specification
' null/nc default default gray , default black
' | xxx [ | ... ] from first data listed
' encoded in-button prompt strings (~ access code)
' ^ character and HTML general ^ text codes
' null/nc default pushbutton ignored
' null/nc default single "E~xit" pushbutton
' T [ ext ] table in-cell text
' standard table text options and data only
' C [ heckbox ] checkbox control (right prompt)
' with standard table control options and data
' /X control initially checked
' null/nc default control initially unchecked
' R [ adioButton ] radio button control (right prompt)
' with standard table control options and data
' /G= n control group number (1-9)
' null/nc default standard group 0
' /X control initially checked
' null/nc default control initially unchecked
' I [ nput ] input box control (left/top prompt)
' /I= x input type
' T standard displayed text input
' P password (masked) input
' F file browser (browse button or direct input)
' null/nc default T (standard displayed text)
' /S= n numeric size (length) of box (1+ characters)
' null/nc default 20
' /M= n maximum number of characters (1+)
' ignored, if file browser input
' null/nc default unlimited input
' /C= x background color id, name or specification string
' A light aquamarine (#97FFE4)
' B light blue (#D2E5FF)
' C LightCyan (HTML defined color)
' L light lavender (#E6E6FA)
' R light red (#FFD6E1)
' W WhiteSmoke (HTML defined color)
' X dialog background color
' Y LightYellow (HTML defined color)
' name HTML defined color name
' #hhhhhh HTML formatted hex color specification
' null/nc default default white
' | ... | xxx default input string (2nd data listed)
' use ^\ for pipe ( | ) character, if necessary
' for file input, default displayed only if:
' access key set + dialog run in
' procedure + oAIX accessible
' null/nc default null (0-length) string
' O [ ptionBox ] drop/list option box control (left/top prompt)
' /S= n size (number of drop/list box display lines) (1+)
' null/nc default 1
' /O= n default option number displayed (selected) (1+)
' null/nc default 1
' /F fixed font for columnar option data (Courier New)
' null/nc default use standard font
' /C= x background color id, name or specification string
' A light aquamarine (#97FFE4)
' B light blue (#D2E5FF)
' C LightCyan (HTML defined color)
' L light lavender (#E6E6FA)
' R light red (#FFD6E1)
' W WhiteSmoke (HTML defined color)
' X dialog background color
' Y LightYellow (HTML defined color)
' name HTML defined color name
' #hhhhhh HTML formatted hex color specification
' null/nc default default white
' | ... | xxx [ | ... ] encoded in-box option strings
' use ^ character codes
' from second data listed
' null/nc default option selection ignored
' null/nc default single "[option]" option
' null/nc default single "E~xit" exit pushbutton; no other controls
' vsBtmText encoded dialog lower text dialog message string
' appears at bottom of dialog,
' below controls but above exit pushbuttons
' HTML body (all) text ^ codes
' null/nc default no lower text; bad codes ignored
' vqRunDlg boolean run dialog in procedure flag
' True procedure runs dialog after display
' False procedure only compiles and displays dialog
' null/nc default False (not run in procedure)
' rxSlns(3, 0+) mixed data array of returned control selections
' ignored, if dialog not run in procedure
' redimensioned for return, if dialog run in procedure
' (0 exit pushbutton and input box specifications
' 0) numeric number of exit pushbutton selection
' 0 exit by [Alt]+[F4] or [x]
' 1+ exit by pushbutton specified
' 1+) string string input for corresponding input box number
' (1 checkbox selections
' 0) numeric bitwise code 2^(n-1) for all selections
' 1+) boolean selection for corresponding checkbox number
' (2 radio button selections
' 0) numeric bitwise code 2^(n-1) for all selections
' 1+) boolean selection for corresponding radio button number
' (3 drop/list option box selections
' 1+) numeric option number selection for corresponding control
' polling controls when dialog run outside of procedure
' trap on error [Alt]+[F4] and [x]
' exit pushbuttons CInt(oIEApp.Document.All.exitbtn.Value)
' checkboxes CBool(oIEApp.Document.All.chk*.Checked)
' radio buttons CBool(oIEApp.Document.All.rad*.Checked)
' input boxes CStr(oIEApp.Document.All.inp*.Value)
' option boxes CInt(oIEApp.Document.All.opt*.Value)
----
Function xReplTextCodes (ByVal vsReplSpec, ByVal vsCodedText)
' specialized Replace function for standard ^ codes
' returns string with codes replaced by special
' or formatting characters, or HTML codes
' returns undimensioned variant string array,
' if HTML prompt option selected
' calls qErr, xCStr, xSplit
' vsReplSpec standard compound code replacement specification string
' single element id [ / option [ / ... ] ] [ | data [ | ... ] ]
' T converts ^ character codes to Chr text
' /S converts pipe characters ( | ) to 4 spaces + vbCr's
' null/nc default no pipe character ( | ) conversion
' /R converts pipe characters ( | ) to vbCr's
' null/nc default no pipe character ( | ) conversion
' /L converts pipe characters ( | ) to vbCrLf's
' null/nc default no pipe character ( | ) conversion
' /T converts empty brackets ( <> ) to vbTabs
' null/nc default no empty brackets ( <> ) conversion
' /N return null, if coded string trims null
' null/nc default returns string of spaces only, as is
' H converts ^ character codes to HTML code
' /T also converts general HTML ^ text codes
' null/nc default no HTML ^ text code conversions
' bad ^ text codes ignored
' /B also converts general and body (all) HTML ^ text codes
' null/nc default no HTML ^ text code conversions
' bad ^ text codes ignored
' /P also converts general HTML ^ text codes and
' prompt ~ access key codes, if valid
' returns string array
' (0) manipulated text string
' (1) " accesskey="" + uppercased key access
' character (if valid) + "
' null/nc default no HTML ^ text code conversions
' bad ^ text and ~ access key codes ignored
' /S also converts all spaces to HTML hard spaces ( " " )
' null/nc default no space conversion
' /L converts pipe characters ( | ) to vbCrLf's
' null/nc default no pipe character ( | ) conversion
' /N return null, if coded string trims null
' null/nc default returns string of spaces only, as is
' null/nc default T (^ character code Chr text conversion)
' vsCodedText encoded text with codes to be replaced
' codes replaced
' ^ codes all codes case-insensitive; progressive group inclusion
' HTML toggle (on/off) ^ text codes reset at end, if necessary
' null/nc default invalid codes uninterpreted
' ^ character codes
' ^P paragraph character
' ^S section character
' ^! bullet character
' ^-- em-dash character
' ^... ellipse character
' ^`` open-quote character
' ^'' close-quote character (2 single quotes)
' ^* footnote character
' ^(T) trademark character
' ^(C) copyright character
' ^(R) registered character
' ^+- plus-or-minus character
' ^X times character
' ^/ divided-by character
' ^1/2 one-half character
' ^1/4 one-quarter character
' ^3/4 three-quarters character
' ^\ pipe ( | ) character
' ^< empty brackets ( <> ) characters
' ^^, ^& carat ( ^ ) character
' HTML general ^ text codes
' ^B toggles bold on/off
' ^I toggles italic on/off
' ^U toggles underline on/off
' ^L line break
' ^n% line break with horizontal graphic line (% of window width)
' 5-100 5% - 100% of window width (in 5% increments only)
' ^-n set smaller HTML font (font on)
' 1-5 relative font size
' ^+n set larger HTML font (font on)
' 1-5 relative font size
' ^F reset standard font size (font off)
' HTML body ^ text codes
' ^J line break + toggles justification (left/centered)
' (initial centering presumed; centering reset at end, if necessary)
' ~ access key codes interpreted for prompts
' following alpha-numeric character interpreted as access key
' first tilde ( ~ ) only interpreted
' if valid, tilde removed and character coded for underline
' pipe characters ( | ) optionally interpreted as CRs or CRLFs
' empty brackets ( <> ) optionally interpreted as tabs
Alex K. Angelopoulos (MVP)
Joe Earnest typed:
> Hi Alex,
>
> Since my last reply wasn't long enough,
> and since the 15th cup of coffee has now
> percolated through the little remaining gray
> matter, I thought of a couple of additional
> items that there is a need for:
Wow - that's an answer, all right.<g>
As a start, here's the WshX alpha demo:
http://dev.remotenetworktechnology.com/files/WshX.zip
At present, it contains one class - ComDlg, per your suggestion - and only calls
the file open and file save dialogs. It's boilerplated from code that directly
calls the APIs in comdlg32, no license required, and it does work on XP. I will
probably include a handful of other classes later. There are several file
functions which FSO does not provide directly, but I think the best of all that
is handled by Monte Hansen in his kvb FileSystemObject
(http://www.killervb.com).
**NOTES**
The DLL needs to be registered by running
regsvr32 WshX.dll
It is project compatible, so best practice for "upgrades" at this point is to
unregister it before installing a "new" version, like
regsvr32 /u WshX.dll
Joe Earnest
Tried it, and of course they worked fine. It should
help a lot. What are your plans with it? Are you
going to duplicate the VB properties so the options
and syntax are the same? (That would probably
make VB users happiest, and gives you a built-in
secondary instructional source -- MSDN and all
the VB literature.)
Regards,
Joe Earnest
"Alex K. Angelopoulos (MVP)" <a...@mvps.org> wrote in message
news:ePAG7q3gCHA.1688@tkmsftngp09...