Re: Broken examples

[norseman]

Tim;
Finally got a chance to test your snippet. Thank you for it!

I took the liberty of flushing it out a bit.
================
#!/---
#
import os
import win32com.client

excel = win32com.client.Dispatch( 'Excel.Application' )
excel.Visible=1 # shows the spreadsheet (can be handy)
xlCSV = 6
# substitute for list generation
list = ["c:\\temp\\test.xls", "c:\\temp\\test1.xls"]

for nm in list:
csv = os.path.splitext( nm )[0] + '.csv'
print "Procesing file:", csv
if os.path.exists(csv): # window$ won't auto overwrite
os.unlink(csv)
wb = excel.Workbooks.Open( nm )
wb.SaveAs( csv, xlCSV )
print wb.Close() # requires manual verification
# eliminating unattended runs

#wb.Exit() & wb.Quit() # generate ERROR(s) - no such thing(s)
# leaving Excel open

excel.Visible=0 # actually closes Excel if no sheet open
# verified via task manager

print "Check to see if this worked."

# end of file
=================
The above does in fact work.
Using the above I have a few questions.
Documentation on xlCSV came from where?
" on .Workbooks.Open(file.xls) came from ???
" on .SaveAs( filename, xlCSV ) came from ???
" on .Close() came from ???
Tell me about the lack of the .Exit() and/or .Quit(), please.
I ran out of time today. Is it possible to send something like an
<enterkeystroke to a Window (<yes><no>) box if it accepts same from
actual keyboard? May not work anyway since .Close() hangs (in
interactive) awaiting it's answer.

Tim - thank you again! At least this works well enough that a clerk can
press <enteruntil the thing runs out of material. :) Just press and
hold the <enterkey until the buffer overflow beeps and go do some
filing and when the screen 'stops' do it again... Eliminates typos.
Thank you.

Steve
no******@hughes.net

[John Machin]

On Aug 12, 10:36 am, norseman <[e-mail]:

Tim;
Finally got a chance to test your snippet. Thank you for it!

I took the liberty of flushing it out a bit.
================
#!/---
#
import os
import win32com.client

excel = win32com.client.Dispatch( 'Excel.Application' )
excel.Visible=1 # shows the spreadsheet (can be handy)
xlCSV = 6
# substitute for list generation
list = ["c:\\temp\\test.xls", "c:\\temp\\test1.xls"]

for nm in list:
csv = os.path.splitext( nm )[0] + '.csv'
print "Procesing file:", csv
if os.path.exists(csv): # window$ won't auto overwrite
os.unlink(csv)
wb = excel.Workbooks.Open( nm )
wb.SaveAs( csv, xlCSV )
print wb.Close() # requires manual verification
# eliminating unattended runs

#wb.Exit() & wb.Quit() # generate ERROR(s) - no such thing(s)
# leaving Excel open

excel.Visible=0 # actually closes Excel if no sheet open
# verified via task manager

print "Check to see if this worked."

# end of file
=================
The above does in fact work.
Using the above I have a few questions.
Documentation on xlCSV came from where?
" on .Workbooks.Open(file.xls) came from ???
" on .SaveAs( filename, xlCSV ) came from ???
" on .Close() came from ???
Tell me about the lack of the .Exit() and/or .Quit(), please.
I ran out of time today. Is it possible to send something like an
<enterkeystroke to a Window (<yes><no>) box if it accepts same from
actual keyboard? May not work anyway since .Close() hangs (in
interactive) awaiting it's answer.

Tim - thank you again! At least this works well enough that a clerk can
press <enteruntil the thing runs out of material. :) Just press and
hold the <enterkey until the buffer overflow beeps and go do some
filing and when the screen 'stops' do it again... Eliminates typos.

Why do you want to save as CSV? Would you be happier with a simple
reliable method to extract information from Excel files without all
that bother? If so, consider the xlrd package (http://www.lexicon.net/
sjmachin/xlrd.htm). If you really do need CSV files, still consider
xlrd in combination with the Python csv module -- remove all that user
involvement, allow the user to use Excel for other purposes while the
job is running (instead of filing), programatically handle exception
conditions (like more than one worksheet in the workbook), run it on
Linus or a Mac if you want to, ...

[norseman]

John Machin wrote:

On Aug 12, 10:36 am, norseman <[e-mail]:

>Tim;
Finally got a chance to test your snippet. Thank you for it!

I took the liberty of flushing it out a bit.
================

....(snip)

>>

Why do you want to save as CSV? Would you be happier with a simple
reliable method to extract information from Excel files without all
that bother? If so, consider the xlrd package (http://www.lexicon.net/
sjmachin/xlrd.htm). If you really do need CSV files, still consider
xlrd in combination with the Python csv module -- remove all that user
involvement, allow the user to use Excel for other purposes while the
job is running (instead of filing), programatically handle exception
conditions (like more than one worksheet in the workbook), run it on
Linus or a Mac if you want to, ...

--
http://mail.python.org/mailman/listinfo/python-list

======================
Why do you want to save as CSV? There is a ton of text processing
programs that suit various people
and thus text lends itself to a
greater audience and massive amounts
of processing tools. Tools people
already know how to use.

Would you be happier with a
simple reliable method to
extract information from Excel
files without all that bother? In truth - perhaps on occasion. But
take a look at the following*. I can
process 1,000's of files while I am
asleep and I don't even need to know
the internal layout. Secretaries,
Clerks and even Student help can use
their favorite text program to search
and replace whatever. Massive amounts
of data can be reviewed and corrected
by non-special computer users. Not to
mention my use of things like sed for
the bulk work.

If so, consider the xlrd package
(http://www.lexicon.net/sjmachin/xlrd.htm).
I did download it. I'll give it a
"test drive" as soon as I can. Then
I can comment on it. There are times
when it could be handy.
If you really do need CSV
files, still consider xlrd in
combination with the Python csv
module -- remove all that
user involvement... Point here is I need human review.
What I don't need is typos.
The intent in the original Clerk
statement was to poke fun at Window$.
Microsoft "point'n'click" is very
non-production oriented.
"The following*"
====================
#!/---
#
import os
import win32com.client

excel = win32com.client.Dispatch( 'Excel.Application' )
excel.Visible=0 #=1 shows the spreadsheet (can be handy)
xlCSV = 6
# a substitute for the list generator
list = ["c:\\temp\\test.xls", "c:\\temp\\test1.xls"]

for nm in list:
csv = os.path.splitext( nm )[0] + '.csv'
print "Procesing file:", csv
if os.path.exists(csv):
os.unlink(csv)
wb = excel.Workbooks.Open( nm )
wb.SaveAs( csv, xlCSV )
wb.Close( False )

excel.Quit()

print "Check to see if this worked for you."

# end of file
====================

The case at hand is that The State of California has been keeping
weather records for awhile. The more reliable stations date from the
1920's. Others go back into the latter 1800's. Satellite reporting is
rather new. Before that one took a horse or a buckboard and went off to
check things. Daily data is missing (even now) for various reasons. The
human can do what computers cannot - think (we hope) :). Some forms of
omissions can be bulk checked. Some cannot. It is counter productive
to try to create 'the all encompassing program'. The 'do all' does, as
yet, not exist. If someone reading this got lost, try this; would you
consider taking your brand new Ferrari 4-wheeling in the Grand Canyon?
Or would you prefer that beat-up old jeep over there?
Sometimes just getting out and walking around accomplishes more. Maybe
not as fast, but usually better. The trick is knowing which to program
and which to give to the kid. It is also counter productive to force
people well trained on Tool A to only use Tool B. Better to find a
common zone and let each use their respective favorite.

"If you are not converting data, you are not producing anything useful."
-- Me
John - Thanks for the link. I will test the library.
Steve
no******@hughes.net