Batch file (CMD) output into HTA
Daz
I am wondering if it is possible to have output from a batch file back
into a HTA file.
What i want to do is use the nice features of HTA to put a nice clean
GUI on my batch files. So that instead of having the ugly command
text etc, i can have the output back into the HTA and then put some
clean type faces etc around it.
Is it possible? If so can someone provide and example of HTA code to
do it?
Any advice or help would be appreciated.
Cheers,
Daz
mayayana
> What i want to do is use the nice features of HTA to put a nice clean
> GUI on my batch files. So that instead of having the ugly command
> text etc, i can have the output back into the HTA and then put some
> clean type faces etc around it.
>
That was really the whole point of script in the
first place -- to go beyond the simple DOS command
line in order to provide more options and GUI
possibilities. So if you want an HTA then why not use
the tool that goes with it? If you want to use DOS/batch
...aren't there groups for that? I just did a search of
MS newsgroups and only came up with this:
microsoft.public.win2000.cmdprompt.admin
I'm not sure what to search for other than "cmd".
There are no groups with "batch" in the name, and
not much in the way of groups with "dos" in the name.
In any case, this is a VBScript group.
Matthias Tacke
>> What i want to do is use the nice features of HTA to put a nice clean
>> GUI on my batch files. So that instead of having the ugly command
>> text etc, i can have the output back into the HTA and then put some
>> clean type faces etc around it.
>>
>
> That was really the whole point of script in the
> first place -- to go beyond the simple DOS command
> line in order to provide more options and GUI
> possibilities. So if you want an HTA then why not use
> the tool that goes with it? If you want to use DOS/batch
> ...aren't there groups for that? I just did a search of
> MS newsgroups and only came up with this:
>
> microsoft.public.win2000.cmdprompt.admin
>
> I'm not sure what to search for other than "cmd".
> There are no groups with "batch" in the name, and
> not much in the way of groups with "dos" in the name.
>
What about the group: alt.msdos.batch.nt
> In any case, this is a VBScript group.
>
His question addressed HTA, should be the proper group though.
It's a bit unclear what OP wants to nice up.
A good learning source might be scriptomaticv2. You have several
output options to choose from :
cmdline, text, html, xls
HTH
Matthias
mayayana
>
I'm surprised that MS doesn't seem to have more
relevant groups. DOS/batch isn't relevant here, yet
there seem to be a lot of people who are interested
in it. I would have thought that an admin group
might be best, but even with "admin" the selection
of Microsoft groups is sparse and specialized. I don't
see anything like:
microsoft.public.windows.admin[.scripting]
And the DOS groups seem to be only DOS. I guess
it would help if MS had come up with a name for the
expanded NT command line functionality, like DOS2,
NTDOS, or something like that.
Tom Lavedas
Here is an attempt I wrote some time back ...
<HTML>
<HEAD>
<TITLE> MSDOS Demo</TITLE>
<HTA:APPLICATION ID="oMSDOS" APPLICATIONNAME="MSDOSApp"
BORDER="thick" BORDERSTYLE="normal" CAPTION="yes"
ICON="C:\WinNT\system32\cmd.exe"
SINGLEINSTANCE="no" VERSION="1.0"
WINDOWSTATE="normal"/>
<SCRIPT Language=VBScript>
opener = "Me"
sub initialize
CurrentFolder.value = CreateObject("Wscript.Shell").CurrentDirectory
Cmd.focus
end sub
Function CmdPrompt(sCmd)
Dim alines, sCmdLine, stemp, ofs, oWS, nRes
'On Error Resume Next
sCmdLine = """%comspec%"" /c " & sCmd & " 1>> "
set ofs = CreateObject("Scripting.FileSystemObject")
stemp = ofs.GetTempName
set oWS = CreateObject("Wscript.Shell")
stemp = oWS.Environment("PROCESS")("TEMP") & "\" & stemp
nRes = oWS.Run(sCmdLine & Chr(34) & sTemp & Chr(34) _
, Abs(cSng(bConsoleSw)), True)
alines = "ERRORLEVEL: " & nRes & vbCRLF
if ofs.FileExists(sTemp) Then
with ofs.OpenTextFile(stemp)
if Not .AtEndofStream Then
alines = aLines & .ReadAll
End if
End With
ofs.DeleteFile stemp
alines = Split(aLines, vbNewline)
Else
aLines = Array(nRes, "")
End if
ReDim Preserve alines(Ubound(alines) - 1)
if Err.Number <> 0 Then _
aLines = Array("Error Number:" & CStr(Err.Number),
Err.Description)
CmdPrompt = alines
End Function
sub checkEnter
With window.event
if .keycode = 13 then
runMS_DOS
Else
.cancelbubble = false
.returnvalue = true
End if
End With
End sub
Sub ChDir
Set oSHL = CreateObject("Shell.Application")
On Error Resume Next
Set oFolder = oSHL.BrowseForFolder(&H0,"Select Working
Folder",&H11,&H11)
If Err.Number = 0 Then
CurrentFolder.value = oFolder.Self.Path
Cmd.focus
End if
End Sub
sub Copy
document.ParentWindow.ClipboardData.SetData "text",
Results.innerText
end sub
Sub runMS_DOS
'On Error Resume Next
CreateObject("Wscript.Shell").CurrentDirectory =
CurrentFolder.value
if Err.Number <> 0 Then
aLines = Array("Error Number:" & Hex(Err.Number),
Err.Description)
Else
Results.innerhtml = "</b> Working ...</b>"
aLines = CmdPrompt(Cmd.Value)
End if
Results.innerhtml = "<xmp>" & Join(aLines, vbCRLF) & "</xmp>"
End Sub
</SCRIPT>
</HEAD>
<BODY onload=initialize style="font:11pt Lucinda Console">
</B>Working Folder: </B>
<input type=text id=CurrentFolder size=70>
<input type=button value=Browse onclick=ChDir>
<br>
</B>MS DOS Command: </B>
<input type=text onkeydown=checkEnter size=60 id=Cmd>
<input type=button id=Go value=" GO " onclick=runMS_DOS>
<hr>
<div id=Results> </div>
<hr><center>
<input type=button value=" Top "
onclick="scrollto 0,0:Cmd.focus:Cmd.Select">  
<input type=button value=" Copy " onclick="copy">  
<input type=button value=" Close " onclick="close">
</center>
</BODY>
</HTML>
I saw a posting for the use of an MS combo box suitable for scripting
a while back, but can't google the reference today. It would make a
nice addition as the Command input line by letting you pick a previous
command line by inspection. But, as I said, I can't find it again.
Tom Lavedas
-------------------
Todd Vargo
> On Jan 11, 1:11 am, Daz wrote:
>> Hi All,
>>
>> I am wondering if it is possible to have output from a batch file
>> back into a HTA file.
>>
>> What i want to do is use the nice features of HTA to put a nice clean
>> GUI on my batch files. So that instead of having the ugly command
>> text etc, i can have the output back into the HTA and then put some
>> clean type faces etc around it.
>>
>> Is it possible? If so can someone provide and example of HTA code to
>> do it?
>>
>> Any advice or help would be appreciated.
>>
>> Cheers,
>> Daz
>
> Here is an attempt I wrote some time back ...
>
> <HTML>
> </HTML>
>
> I saw a posting for the use of an MS combo box suitable for scripting
> a while back, but can't google the reference today. It would make a
> nice addition as the Command input line by letting you pick a previous
> command line by inspection. But, as I said, I can't find it again.
Tom, I tried but could not come up with one of these.
Your HTA example is cool but there seems to a few problems with it (read HTA
limitations). The first I noticed was the command line does not seem to work
with internal commands of more than a single parameter. It returns an
errorlevel of 0 but does nothing. Then I tried it with a batch file and it
does permit parameters but if less than the number of parameters expected
are provided, it seems to append a "1" to what is actually expanded.
For example, say the batch has "ECHO parameters=%1 %2 %3" but only two
parameters were provided on the command line (say 'foo bar'), the output is
"parameters=foo bar 1". Where does the 1 come from?
Another thing I noticed (actually, I expected it) is the output is not
displayed in real time. Output is actually displayed after completion of the
command. The output does not seem customizable in the sense of formatting
the output to something pretty.
Don't get me wrong, it was an educational exercise on HTA capability but I
think OP will be happier to just create a shortcut to his existing batch(s)
and set display properties to font and colors desired.
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
Tom Lavedas
Thanks for the input.
Yes, I realize this is not particularly useful as it stands. It was
meant as a basic shell to illustrate the concepts, not a finished
(read: useful) product.
Concerning the failure to accept more than one parameter and the issue
with the extra 1: That is probably because I wrote and tested this in
Win 2kPro and never tested it in a Win9x variant. As I recall, you
are a Win 98 user, which does not support numbered pipes. Take the 1
off of this line and it should work for you, too ...
sCmdLine = """%comspec%"" /c " & sCmd & " 1>> "
I did it to try to make the solution more robust in NT variant OSs,
but it clearly introduces a problem in non-NT OSs.
As far as the other comments: I must plead guilty. It does just
report the output of the command once it has finished. This could be
fixed with some slight of hand and the replacement of RUN with the
EXEC method. However, that's a lot more complicated a problem than I
wanted to tackle. It seems to me that someone (mr. unreliable?)
posted an MS-DOS console replacement Windows Script Component once.
Concerning the lack of fancy fonts: Again, I'm guilty. I used the
expedient of enclosing the results in <xmp></xmp> tags to keep the
original formatting intact. Upon consideration a couple of quick
Replaces could fix that problem. For example here is a quick fix for
a few of the possible issues ...
Sub runMS_DOS
'On Error Resume Next
CreateObject("Wscript.Shell").CurrentDirectory =
CurrentFolder.value
if Err.Number <> 0 Then
aLines = Array("Error Number:" & Hex(Err.Number),
Err.Description)
Else
Results.innerhtml = "</b> Working ...</b>"
aLines = CmdPrompt(Cmd.Value)
End if
sRes = Replace(Replace(Join(aLines, "?"), "<", "<"), ">",
">")
sRes = Replace(Replace(sRes, vbTab, " "), " ", " ")
Results.innerhtml = Replace(sRes, "?", "<BR>")
End Sub
Then the HTML BODY could be altered thus ...
<BODY onload=initialize>
</B>Working Folder: </B>
<input type=text id=CurrentFolder size=70>
<input type=button value=Browse onclick=ChDir>
<br>
</B>MS DOS Command: </B>
<input type=text onkeydown=checkEnter size=60 id=Cmd>
<input type=button id=Go value=" GO " onclick=runMS_DOS>
<hr>
<div id=Results style='font:11pt Lucida Console'> </div>
<hr><center>
<input type=button value=" Top " onclick="scrollto
0,0:Cmd.focus:Cmd.Select">  
<input type=button value=" Close " onclick="close">
</center>
</BODY>
I changed the font, though monospaced fonts will still look better
than proportional ones in most cases, I think.
Note the removal of the Frame and Frameset tags. I'm not quite
certain what I was thinking when I put those in.
I did a quick test with a DIR /o and DIR /o /a-d and they seemed to
work as expected.
Tom Lavedas
***********
http://there.is.no.more/tglbatch/
Todd Vargo
> Todd Vargo wrote:
...
Your mods work here too (in W98). Your debugging skills were right on the
money. Very impressive work as always, Tom.
Tom Lavedas
> TomLavedaswrote:
>
> > I saw a posting for the use of an MS combo box suitable for scripting
> > a while back, but can't google the reference today. It would make a
> > nice addition as the Command input line by letting you pick a previous
> > command line by inspection. But, as I said, I can't find it again.
>
> Tom, I tried but could not come up with one of these.
>
I finally found the Combobox I was sure I had seen recently. I found
a Script Center article, though it was not what I saw originally:
http://www.microsoft.com/technet/scriptcenter/topics/activex/combobox.mspx.
It is probably the source of whatever I saw posted. Don't try to find
it in the index. It doesn't seem to be there (at least I can't find
it). It took a search for CLASSID to turn it up.
Anyway, it works like a champ - if you have MS OFFICE installed. The
implication is that all of the form objects can be used, but you would
need to know the ClassID. I haven't looked for a list of those, but
would have some interest in the Tab control for a project I've been
working on, if anyone stumbles on it.
If anyone reads this and wants a copy of the latest version of the
MSDOSDemo.hta with the combobox in operation, let me know at "tlavedas
at hotmail dot com" (since I don't have a web site at this time).
p byers
Being a 'ScriptSquirrel' - I remembered that I had got some Script (JavaScript)
that creates a "proper" (ish) ComboBox in Web Pages.
I guess that as it works in HTML pages, it can be used in HTA !!
I cannot remember whence it came but if anyone is interested, I will ZIP the
folder concerned and put it on one of my WebSites.
But maybe I have not understood your post !!
Best regards
Take care
Pete (Northolt UK)
Tom Lavedas
> Tom
> Being a 'ScriptSquirrel' - I remembered that I had got some Script (JavaScript)
> that creates a "proper" (ish) ComboBox in Web Pages.
> I guess that as it works in HTML pages, it can be used in HTA !!
>
> I cannot remember whence it came but if anyone is interested, I will ZIP the
> folder concerned and put it on one of my WebSites.
>
> But maybe I have not understood your post !!
>
> Best regards
> Take care
> Pete (Northolt UK)
>
> Tom Lavedas wrote:
> > On Jan 11, 5:29 pm, "Todd Vargo" <tlva...@sbcglobal.netz> wrote:
> > > TomLavedaswrote:
> > {snip}
>
> > > > I saw a posting for the use of an MS combo box suitable for scripting
> > > > a while back, but can't google the reference today. It would make a
> > > > nice addition as the Command input line by letting you pick a previous
> > > > command line by inspection. But, as I said, I can't find it again.
>
> > > Tom, I tried but could not come up with one of these.
>
> > {snip}
>
> > I finally found the Combobox I was sure I had seen recently. I found
> > a Script Center article, though it was not what I saw originally:
> > It is probably the source of whatever I saw posted. Don't try to find
> > it in the index. It doesn't seem to be there (at least I can't find
> > it). It took a search for CLASSID to turn it up.
>
> > Anyway, it works like a champ - if you have MS OFFICE installed. The
> > implication is that all of the form objects can be used, but you would
> > need to know the ClassID. I haven't looked for a list of those, but
> > would have some interest in the Tab control for a project I've been
> > working on, if anyone stumbles on it.
>
> > If anyone reads this and wants a copy of the latest version of the
> > MSDOSDemo.hta with the combobox in operation, let me know at "tlavedas
> > at hotmail dot com" (since I don't have a web site at this time).
>
> > Tom Lavedas
> > ***********
> >http://there.is.no.more/tglbatch/
Yes, that would be nearly the same thing. However, I suspect it's a
lot of code. I like reusing available system or application objects
whenever possible.
Tom Lavedas
=========
Al Dunbar
"mayayana" <mayaX...@rcXXn.com> wrote in message
news:%23iA4DeB...@TK2MSFTNGP06.phx.gbl...
>> What about the group: alt.msdos.batch.nt
>>
>
> I'm surprised that MS doesn't seem to have more
> relevant groups. DOS/batch isn't relevant here, yet
> there seem to be a lot of people who are interested
> in it. I would have thought that an admin group
> might be best, but even with "admin" the selection
> of Microsoft groups is sparse and specialized. I don't
> see anything like:
> microsoft.public.windows.admin[.scripting]
Two groups here that are occasionally helpful in the area of batch are:
microsoft.public.windows.server.scripting
microsoft.public.win2000.cmdprompt.admin
The first is non-scripting-language specific, and generic to the o/s called
windows server, which covers a few varieties. The second would appear to be
specific to that now obsolete/unsupported o/s called w2k, but it tends to be
somewhat open to more recent versions.
> And the DOS groups seem to be only DOS. I guess
> it would help if MS had come up with a name for the
> expanded NT command line functionality, like DOS2,
> NTDOS, or something like that.
The trouble with the term DOS is that that was the name of an o/s that many
of us are no longer using. Yes, I know some still use w9x, some third party
DOS lookalikes, and even real DOS. But since is it no longer supported, I am
not surprised that MS has not created public groups dedicated to it.
This has been discussed before, and IIRC, the consensus was that a
proliferation of batch support groups, one for each possible O/S, would be
confusing.
/Al
mayayana
many
> of us are no longer using. Yes, I know some still use w9x, some third
party
> DOS lookalikes, and even real DOS. But since is it no longer supported, I
am
> not surprised that MS has not created public groups dedicated to it.
>
> This has been discussed before, and IIRC, the consensus was that a
> proliferation of batch support groups, one for each possible O/S, would be
> confusing.
>
for different OSs. I was just thinking that there should
be a group for console operations, and XP+ console
enhancements could go under that umbrella. DOS...
..command-line ...console? See, I don't know what to
call it. :)
There seem to be an increasing number of network
admin. types who like to use command line operations.
That has no connection with VBScript, so I'm
guessing the questions end up here because people
are also using VBS and just don't know where else
to go for questions about console operations. But there
are also an increasing number of posts from people
who don't seem to even know that there's a difference
between VBS and DOS/Batch -- like the post from
"Luuk" that you responded to the other day.
I realize that on XP it's not technically DOS, but if
I open a console window on Win9x it's DOS. And the
XP console methods were designed to emulate, and
to be generally backward compatible with, DOS. They're
Win32 applets, but in practice they're basically the same
thing. You're using DOS commands, in a console window,
and you just happen to have additional command line
applets/commands that don't exist on Win9x. That's why I
call it NTDOS or DOS/Batch. There doesn't seem to be any
closer name for it. Whatever it is, it's entirely different
from VBS.
I don't want to split hairs. The odd DOS/Batch answer
here or there isn't a problem. But this is a VBS group. And
personally I have little knowledge of or interest in anything
dating from pre-mouse days. I'm just not a good enough
typist for that. :) So it would be nice if the VBS group
could be mainly dealing with VBS.
Al Dunbar
"mayayana" <mayaX...@rcXXn.com> wrote in message
>> The trouble with the term DOS is that that was the name of an o/s that
> many
>> of us are no longer using. Yes, I know some still use w9x, some third
> party
>> DOS lookalikes, and even real DOS. But since is it no longer supported, I
> am
>> not surprised that MS has not created public groups dedicated to it.
>>
>> This has been discussed before, and IIRC, the consensus was that a
>> proliferation of batch support groups, one for each possible O/S, would
>> be
>> confusing.
>>
> I don't see any reason that it needs to be different
> for different OSs.
One could argue that "real dos" and the NT (and up) command prompt have
significant enough capabilities that lumping them all together will cause
problems. In fact, I have seen some of the problems when someone asks a
question without specifying which o/s version.
> I was just thinking that there should
> be a group for console operations, and XP+ console
> enhancements could go under that umbrella. DOS...
> ..command-line ...console? See, I don't know what to
> call it. :)
The trouble is that it would be difficult to come up with a name that truly
indicated its scope of coverage.
> There seem to be an increasing number of network
> admin. types who like to use command line operations.
Granted. But they are all working in the NT world, so the groups I suggested
earlier should suffice:
ms.pub.win2000.cmdprompt.admin
ms.pub.windows.server.scripting
The "win2000" is admitedly a red herring, but creating a new one with
"windows" instead would split the posts between the two.
the .serfver.scripting is rightfully language neutral (imho), as most server
users (admins) are looking for a soluting to a problem and do not want to
crosspost to batch, vbscript, wsh, powershell, and possibly other groups.
> That has no connection with VBScript, so I'm
> guessing the questions end up here because people
> are also using VBS and just don't know where else
> to go for questions about console operations.
Exactly right.
But supposing there were a more appropriate newsgroup; how would they know
what its name is, and whether it would be something "console", "batch",
"command prompt", or "DOS". Many would still ask here and be directed
elsewhere. In that case why not just direct them as I suggested?
> But there
> are also an increasing number of posts from people
> who don't seem to even know that there's a difference
> between VBS and DOS/Batch -- like the post from
> "Luuk" that you responded to the other day.
The only solution I can see would be to rename all the newsgroups so that
the vast majority of people would pick the right one. So this one would be:
microsoft.public.scripting.vbscript.this.is.not.for.DOS.batch.or.command.prompt.questions
> I realize that on XP it's not technically DOS, but if
> I open a console window on Win9x it's DOS. And the
> XP console methods were designed to emulate, and
> to be generally backward compatible with, DOS.
I disagree. More like generally backward similar. There are some things that
work differently enough that the syntactical similarity is mainly useful to
get one started. In fact, someone pointed out in one of the batch ng's that
CMD.EXE on XP will process some commands differently based on whether they
were in a .bat or a .cmd file.
> They're
> Win32 applets, but in practice they're basically the same
> thing. You're using DOS commands, in a console window,
> and you just happen to have additional command line
> applets/commands that don't exist on Win9x. That's why I
> call it NTDOS or DOS/Batch. There doesn't seem to be any
> closer name for it. Whatever it is, it's entirely different
> from VBS.
Exactly so. And still nobody knows its name... ;-)
> I don't want to split hairs. The odd DOS/Batch answer
> here or there isn't a problem.
I agree. But even more off-topic is raising the old "it is DOS/it isn't DOS"
argument here ;-)
> But this is a VBS group. And
> personally I have little knowledge of or interest in anything
> dating from pre-mouse days. I'm just not a good enough
> typist for that. :) So it would be nice if the VBS group
> could be mainly dealing with VBS.
Yes. That is not just for your convenience, though, but for the convenience
of those looking for answers to batch questions.
Personally, I think most posts that appear here incorrectly should result in
a suggestion they go to the two ng's I mentioned. There are times, however,
when it does not hurt for a simple question to be answered when one has a
simple answer.
/Al
Todd Vargo
> Personally, I think most posts that appear here incorrectly should result
in
> a suggestion they go to the two ng's I mentioned. There are times,
however,
> when it does not hurt for a simple question to be answered when one has a
> simple answer.
As a simple rule of thumb, if one knows a simple answer, then provide it
with a pointer to a more appropriate group for further discussion. If one
does not know a simple answer, then state such with the pointer. In no case
should anyone ever be told to go away. It would be better just ignore a post
and allow others to handle it with diplomacy.
Tom Lavedas
Well said. I agree.
mayayana
> with a pointer to a more appropriate group for further discussion. If one
> does not know a simple answer, then state such with the pointer. In no
case
> should anyone ever be told to go away. It would be better just ignore a
post
> and allow others to handle it with diplomacy.
>
Yes, that's ideal, but it's not happening, even by
the people suggesting it. That's why I brought the
issue up. I don't think I've ever seen a post like:
"You can do XYZ, but you really should post this in the
such-and-such DOS/Batch/console group."
From this thread it appears that there isn't really
a good DOS/Batch/console group to send people to.
A few years ago, people were mainly using VBS for quickie
software and simple automations, which is pretty much how
I use it. It was a "power users" tool. But more recently VBS
has been discovered by network admins. (And a power user
on Windows these days is someone who's managed to
get Vista to allow them to run a program or delete a file. :)
Among the posts here now, there are maybe 30% DOS/Batch
posts and maybe 90% that are related specifically to network
admin issues: AD, permissions, remote PC communication, etc.
None of that has any relevance to me personally, and much of
it is only minimally related to VBS, at best. But it does seem to
be what the majority of people want/need when they're coming
to this group. So I think that maybe it's time for people like me
to just adapt and move on.
Al Dunbar
"mayayana" <mayaX...@rcXXn.com> wrote in message
>> As a simple rule of thumb, if one knows a simple answer, then provide it
>> with a pointer to a more appropriate group for further discussion. If one
>> does not know a simple answer, then state such with the pointer. In no
> case
>> should anyone ever be told to go away. It would be better just ignore a
> post
>> and allow others to handle it with diplomacy.
>>
>
> Yes, that's ideal, but it's not happening, even by
> the people suggesting it.
My bad if I have occasionally neglected to redirect the posts in question.
At least there seems to be a bit more tolerance for people who ask batch
questions here because they don't know where else to go.
> That's why I brought the
> issue up. I don't think I've ever seen a post like:
>
> "You can do XYZ, but you really should post this in the
> such-and-such DOS/Batch/console group."
I'm sure I have done so in the past as have others. More recently, well I'm
not into keeping statistics on this kind of thing.
> From this thread it appears that there isn't really
> a good DOS/Batch/console group to send people to.
Having suggested what are the newsgroups of choice in this thread at least
twice, I will not repeat them again.
> A few years ago, people were mainly using VBS for quickie
> software and simple automations, which is pretty much how
> I use it. It was a "power users" tool. But more recently VBS
> has been discovered by network admins.
I let that one go when you first mentioned it, but I've been reading and
posting here off and on for 7 or 8 years, and my motiviation was more in the
administrative area.
> (And a power user
> on Windows these days is someone who's managed to
> get Vista to allow them to run a program or delete a file. :)
>
> Among the posts here now, there are maybe 30% DOS/Batch
> posts and maybe 90% that are related specifically to network
> admin issues: AD, permissions, remote PC communication, etc.
... if you say so. I don't keep statistics like that.
> None of that has any relevance to me personally, and much of
> it is only minimally related to VBS, at best. But it does seem to
> be what the majority of people want/need when they're coming
> to this group. So I think that maybe it's time for people like me
> to just adapt and move on.
If, as you have suggested, the focus is now more on areas of application
that you don't find interesting, it would be a shame if you left.
/Al
Todd Vargo
> "mayayana" <mayaX...@rcXXn.com> wrote:
> > None of that has any relevance to me personally, and much of
> > it is only minimally related to VBS, at best. But it does seem to
> > be what the majority of people want/need when they're coming
> > to this group. So I think that maybe it's time for people like me
> > to just adapt and move on.
>
> If, as you have suggested, the focus is now more on areas of application
> that you don't find interesting, it would be a shame if you left.
Agreed.
Todd Vargo
> > As a simple rule of thumb, if one knows a simple answer, then provide it
> > with a pointer to a more appropriate group for further discussion. If
one
> > does not know a simple answer, then state such with the pointer. In no
> case
> > should anyone ever be told to go away. It would be better just ignore a
> post
> > and allow others to handle it with diplomacy.
> >
>
> Yes, that's ideal, but it's not happening, even by
> the people suggesting it. That's why I brought the
> issue up. I don't think I've ever seen a post like:
Redirection to another group is an option, not a requirement. The main point
of course was "in no case should anyone ever be told to go away."
>
> "You can do XYZ, but you really should post this in the
> such-and-such DOS/Batch/console group."
>
> From this thread it appears that there isn't really
> a good DOS/Batch/console group to send people to.
Not so. alt.msdos.batch.nt was mentioned by Matthias, and it's predecessor,
alt.msdos.batch, receives sufficent XP related traffic (although it is not
intended for XP batch discussions) to prove otherwise. One simply need look
'outside the box' to locate these 'batch' groups.
> A few years ago, people were mainly using VBS for quickie
> software and simple automations, which is pretty much how
> I use it. It was a "power users" tool. But more recently VBS
> has been discovered by network admins. (And a power user
> on Windows these days is someone who's managed to
> get Vista to allow them to run a program or delete a file. :)
>
> Among the posts here now, there are maybe 30% DOS/Batch
> posts and maybe 90% that are related specifically to network
> admin issues: AD, permissions, remote PC communication, etc.
> None of that has any relevance to me personally, and much of
> it is only minimally related to VBS, at best. But it does seem to
> be what the majority of people want/need when they're coming
> to this group. So I think that maybe it's time for people like me
> to just adapt and move on.
I don't know where these percentages are coming from (over past day, week,
month, year) or if they are even accurate, but when I come across a subject
which I am not interested in, I usually just move to the next post. If a
subject appears interesting but after the first few lines of content I
discover its not, I typically follow the same practice of moving to the next
post.
Paul Randall
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
news:%23S8zYMq...@TK2MSFTNGP05.phx.gbl...
> Not so. alt.msdos.batch.nt was mentioned by Matthias, and it's
> predecessor,
> alt.msdos.batch, receives sufficent XP related traffic (although it is not
> intended for XP batch discussions) to prove otherwise. One simply need
> look
> 'outside the box' to locate these 'batch' groups.
My problem with looking outside the box is that my ISPs don't provide
newsgroup support, and I have not found a 'me friendly' inexpensive
alternative to get to places like alt.msdos.batch.nt. I see lots of
references indicating that free/cheap newsgroup support exists but nothing
covering links to them and reviews of them. So for now,
microsoft.public.whatever is the only thing I use for posting and
groups.google.com is what I use to find info from other newsgroups.
-Paul Randall
Todd Vargo
> Todd Vargo wrote:
> > Not so. alt.msdos.batch.nt was mentioned by Matthias, and it's
> > predecessor,
> > alt.msdos.batch, receives sufficent XP related traffic (although it is
not
> > intended for XP batch discussions) to prove otherwise. One simply need
> > look
> > 'outside the box' to locate these 'batch' groups.
>
> My problem with looking outside the box is that my ISPs don't provide
> newsgroup support, and I have not found a 'me friendly' inexpensive
> alternative to get to places like alt.msdos.batch.nt. I see lots of
> references indicating that free/cheap newsgroup support exists but nothing
> covering links to them and reviews of them. So for now,
> microsoft.public.whatever is the only thing I use for posting and
> groups.google.com is what I use to find info from other newsgroups.
Groups.Google.com not only allows you to read posts from the alt.* groups
but you can also post to them as well. As far as finding free servers goes,
your complaint indicates that you (and the others with same argument) have
not done your homework. :(