Searching \ for '[EE] Taking the fun out of computers-WindowsVistaC' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=taking+fun+out+computers
Search entire site for: 'Taking the fun out of computers-WindowsVistaC'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Taking the fun out of computers-WindowsVistaC'
2007\01\25@155040 by Wouter van Ooijen

face picon face
> But I have done a quite a bit of scripting in MS Windows
> using vbscript,
> sendkeys, sidekick, etc... With various degrees of success.

But vbscript is not 'the' scripting language of windows applications, it
just happens to be the inside engine of most Microsoft apps. It won't do
you much good to automate a task using let's say Firefox.

One problem I had is that I create invoices from an administration
program (I wrote that myself, in Python), and I want to print them in a
nice format. I used to have a letterhead in Word, print that on a stack
of paper, the invoice itself was in html, and I used IE to print that (I
could not get Firefox to print by default without any headers or
footers). I had to do that by hand: open the file, print print print (I
need 3 copies), open next file, etc. I switched to generating rtf, so I
can have the letterhead and invoice proper in one file, but I would
still have to open Word, print print print, open next file etc. I could
not find a Word command line option to cause it to open the file, print
it, and quit. I recently learned that this can easily be done by
specifying a macro to run. That macro still can't print 3 times (I dunno
why, it simply does not work), but I can start Word with the macro 3
times, no problem.

The point of this is that Word is a typical GUI program, and with its
macro/scription facility it is not too closed. But to do something basic
(print a file) in an automated way (what else are computers for!) I must
first get the idea that this can (only) be done by a startup macro, and
I have to learn the language for that macro. (OK, google helps a lot for
both) A decent CLI application would provide a documented way to do this
from the command line...

Note that this is a GUI issue, not a Microsoft issue. Firefox is even
worse that IE in this tiny aspect.

> And CLI scripting in Windows systems is very much alive and well, so
> wouldn't it be nice to have a GUI of the command line
> utilities? E.g. the
> standard Win32 command line stuff like SORT, DIR, etc...
> Should have GUI
> interfaces accessible from the command line as menu pull
> downs or popups.

I realy don't see any use for that

> I've always loved that quote about Unix being very friendly, but very
> selective about it's friends. Perl seems that way to me as well.

not a friend of mine. Python has eaten it alive.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\01\25@160811 by Alex Harford

face picon face
On 1/25/07, Wouter van Ooijen <spam_OUTwouterTakeThisOuTspamvoti.nl> wrote:
>
> > I've always loved that quote about Unix being very friendly, but very
> > selective about it's friends. Perl seems that way to me as well.
>
> not a friend of mine. Python has eaten it alive.

You beat me to it.  Working in Python is a dream compared to Perl, and
I'm amazed by the number of libraries available for Python.

Alex

2007\01\25@161317 by Tamas Rudnai

face picon face
I think the only problem with GUI is that most of the developers forget to
support keyboard. It seems they only use mouse as an input device. I think
it was not an accident that couple of years ago Peter Norton started to
develop his commander -- there are number of things that can be done much
faster using a menu style interface than just the CLI. However, for batch
processing CLI is better simply because GUI developers does not care about
batch processing and automatization. Also CLI is easier to document
(redirecting it's output to printer or file). Anyway, I use mostly CLI for
my work and a Norton Commander clone, and of course there are many
applications that could not be done very easily without GUI -- MPLAB for
example :-) I know I could use edlin and CLI compliers, but...

Tamas


On 1/25/07, Wouter van Ooijen <.....wouterKILLspamspam@spam@voti.nl> wrote:
{Quote hidden}

> -

2007\01\25@161420 by John La Rooy

flavicon
face
On 1/26/07, Wouter van Ooijen <wouterspamKILLspamvoti.nl> wrote:
>
>
> > I've always loved that quote about Unix being very friendly, but very
> > selective about it's friends. Perl seems that way to me as well.
>
> not a friend of mine. Python has eaten it alive.


Have a look at pyuno
udk.openoffice.org/python/python-bridge.html
You can drive the openoffice library directly from python, no need to have
Word popping up windows all over the place.

I didn't like cygwin so much, I installed vmware-player and run an xubuntu
appliance in there for my command line needs.

2007\01\25@163534 by James Newtons Massmind

face picon face
> But vbscript is not 'the' scripting language of windows
> applications, it just happens to be the inside engine of most
> Microsoft apps. It won't do you much good to automate a task
> using let's say Firefox.

Vbscript can be run from the command line and has a function that will send
keystrokes to other applications. So you can use it to automate Firefox or
any other application that can respond to keystrokes. I don't believe there
is a way to simulate mouse clicks, but I could be wrong.

{Quote hidden}

Yeah, I hear you. But this is also a result of the monolithic application
issue. This is the Windows way. On the other hand, if there were one little
app that just prints things, another that just overlays forms and graphics,
and they had a nice little scripting language to bind them together... That
is the Unix way, and I can appreciate the point of it, but the user
interface is hard to be friends with.

> > the standard Win32 command line stuff like SORT, DIR, etc...
> > Should have GUI
> > interfaces accessible from the command line as menu pull downs or
> > popups.
>
> I realy don't see any use for that

Learning how to use them without having to read the documentation and type
in correct command line parameters.


---
James.


2007\01\25@172028 by Martin McCormick

flavicon
face
       Computer users who are also blind have an interesting
take on this whole discussion.  Someone on this list touched on
the monolithic nature of GUI applications and Windows
applications in particular.  There in lies a real problem.  There
are several commercial programs that generally make Microsoft
Windows mostly talk or output Braille to special displays.  One
of the most expensive and good adaptive programs is called JAWS
which stands for Job Access With Speech.  It is very
sophisticated and works beautifully for some applications, fair,
for others and absolutely bombs on Windows applications that
weren't written to work with JAWS.  To me, that is unacceptable,
the fact that each application is its own little battle ground as
to whether or not it will work.  If I am going to spend the
$1,000 plus to add JAWS to Windows, I darn well want to know it's
going to work.

       With unix, however, the modular nature of things and the
fact that there is a sacred concept of standard input and output
means that access to non-GUI applications is almost guaranteed
without any software developer having to do much of anything.

       This, of course, is an over simplification.  Some CLI
applications are awkward to use with speech because they address
the screen nonsequencially so you hear everything, but it doesn't
make much sense.

       The neat thing is that you can work around things like
that if it is really important by writing filters to try to
distill the important nuggets out of all the ASCII graphics and
or boiler plate that may make you listen to a whole screen of
repetitive information when all you wanted was one thing such as,
"Is the interface up?"

       In the late nineties, I was getting pretty frustrated
since by then, DOS was fading in to obsolescence and unix was
only available for the most part on Suns and other rather
expensive platforms.

       I finally tried Linux in 2001 or so and haven't looked
back since.  My only use for DOS any more is to convert any old
P.C. with two serial ports in to a talking terminal, so to speak,
which connects to another serial port on a Linux box.  The
Linux box is what does all the fun stuff these days.

       There are groups working on speech and Braille access for
gnome, but any GUI presents some of the same problems Windows
does and only certain applications are presently usable this way
in gnome.

       Under Linux, I can program PIC's, burn CD's and listen to
streaming audio with mplayer as well as write programs in C and
play with expect and shell scripts to my heart's content.

       The frustration level is down significantly from what it
was about ten years ago.  My only real gripe with Windows
was echoed by another person on this list in that it has made
malfunctions almost normal.  There is kind of an attitude amongst
many that, "Oh!  that's just the way Windows is."

       In my paid job, I manage domain name servers, dhcp
servers and do tons of unix-based automation.  Our group does
lots of things in huge quantities and I am eternally grateful to
the unix brains out there who have made this job much more
productive than it might have been.

       I think it was Isaac Newton who made the remark about
standing on the shoulders of giants and that sums up my feelings
about unix.  It isn't perfect by any means, but it is constantly
evolving.

Martin McCormick WB5AGZ  Stillwater, OK
Systems Engineer
OSU Information Technology Department Network Operations Group

2007\01\26@021005 by Wouter van Ooijen

face picon face
> Yeah, I hear you. But this is also a result of the monolithic
> application issue.

I don't thinks so. I don't object to monolitic programs as long as I can
automate their actions.

> Learning how to use them without having to read the
> documentation and type in correct command line parameters.

I don't think users of that level will have much use for
sort/unique/cont type of programs, they will prefer build-in
well-integrated features of the their database, spreadsheet, etc.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\01\26@021005 by Wouter van Ooijen

face picon face
> I think the only problem with GUI is that most of the
> developers forget to support keyboard.

I don't miss keyboard support much - I miss supported for automation
(command line being the most common/easy/accessible form of automation).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\01\26@082423 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> But I have done a quite a bit of scripting in MS Windows
>> using vbscript,
>> sendkeys, sidekick, etc... With various degrees of success.
>
> But vbscript is not 'the' scripting language of windows applications, it
> just happens to be the inside engine of most Microsoft apps. It won't do
> you much good to automate a task using let's say Firefox.

As others have said, VBScript is not the scripting language inside Office
apps, that's VBA -- a sibling. VBScript and JScript are, in the context of
WSH (Windows Script Host) the native scripting languages of Windows. (But
by no means the only ones, as you know... :)

If you want to automate Microsoft apps, you should look into COM; whether
used with VBScript or JScript, through WSH or stand-alone, or used with
other scripting languages like Python. That's the automation interface
Microsoft (and a number of other Windows apps) provide. It has a few
drawbacks compared to command line automation, but for larger applications
it is much more powerful. And doesn't require strange tricks like sending
keystrokes (which can go wrong if the focus changes midway...)

COM more or less provides an access to the application's built-in macro
facilities, from your preferred scripting language, from outside the
application.

Gerhard

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...