[Bob Riemersma]

"Karl E. Peterson" wrote in message @TK2MSFTNGP04.phx.gbl...
> Bob Riemersma wrote:
>> For simple cases you can use the FSO to get references to the StdIO
>> streams
>> as TextStream objects. Look at the FSO method GetStandardStream():
>>
>> http://msdn2.microsoft.com/en-us/library/y6hbz9es(VS.85).aspx
>
> Wasn't aware that was even available. Prolly not a good idea in all but,
> as you suggest, the simplest cases. But interesting to know about!
>

I understand the limitations of using the FSO in lieu of VB's native I/O.
I'm not sure they hold for low-volume I/O between a parent and child process
that can get by with simple blocking calls. Too bad I've haven't found a
way to use VB I/O against the standard streams.

However in cases where one needs to do a lot more I/O (or even async I/O)
with these streams it is easy enough to craft a Class or UserControl that
makes the necessary API calls.

Your article on VB and Console operations is quite complete, and one of my
own favorites. I've found that in many cases it is overkill for simple
parent/child communications though, and I think this is the sweet spot for
VB when it comes to Console programs. They're great as "worker" processes
for background grunt work.

>> Add-ins of the type Karl mentions work fine too though.
>
> My favorite is now available free -- http://www.vbadvance.com
> --
> .NET: It's About Trust!
> http://vfred.mvps.org

Good news on vbadvance. I might look at it again.

Archived from group: microsoft>public>vb>general>discussion

[Karl E. Peterson]

Hi Bob --

>>> For simple cases you can use the FSO to get references to the StdIO
>>> streams
>>> as TextStream objects. Look at the FSO method GetStandardStream():
>>>
>>> http://msdn2.microsoft.com/en-us/library/y6hbz9es(VS.85).aspx
>>
>> Wasn't aware that was even available. Prolly not a good idea in all but,
>> as you suggest, the simplest cases. But interesting to know about!
>
> I understand the limitations of using the FSO in lieu of VB's native I/O.
> I'm not sure they hold for low-volume I/O between a parent and child process
> that can get by with simple blocking calls. Too bad I've haven't found a
> way to use VB I/O against the standard streams.

What, in this case, do you mean by the "the standard streams"?

> However in cases where one needs to do a lot more I/O (or even async I/O)
> with these streams it is easy enough to craft a Class or UserControl that
> makes the necessary API calls.
>
> Your article on VB and Console operations is quite complete, and one of my
> own favorites. I've found that in many cases it is overkill for simple
> parent/child communications though, and I think this is the sweet spot for
> VB when it comes to Console programs. They're great as "worker" processes
> for background grunt work.

I'm having a hard time disagreeing with any of that. Yeah, my Console module is
*heavy* as heck, but it'll do "anything" a console app would ever need to do.
Afaik, anyway. But you're right about how fabulously utilitarian FSO is for this!
I had absolutely no idea. I've been playing around with that sample on
http://www.tek-tips.com/faqs.cfm?fid=5647 and wondering how I missed this for so
long. Wouldn't do, of course, for any sort of mass-distributed tool. That
scripting runtime is just to fragile (especially given the liklihood of it being
disabled by security nazis in IT!). But for in-house stuff, it sure seems to be the
Q&D way to knock one out! Gotta be *the* best use I've seen for FSO ever.

>>> Add-ins of the type Karl mentions work fine too though.
>>
>> My favorite is now available free -- http://www.vbadvance.com
>
> Good news on vbadvance. I might look at it again.

It's addictive.
--
..NET: It's About Trust!
http://vfred.mvps.org

[Kevin Provance]

| Did you author it?

It looks as though he did: http://www.angelfire.com/mi4/bvo/vb/vbconio.htm

- Kev