>...
>>Terry,
>>I quickly read the whole thread and you've come a long way as I see:) While automaing excel is fun you might not need it. To direct you to another long and winded path < g > I'd say also think of loading the HTM into a DocumentObjectModel and process it w/o putting Excel in between. Of course DOM processing might sound to be easier or harder than automating excel.
>
>Thanks, Cetin. I actually want the o/p to be a s/s, cos that's the format that some of our non-electronic ticket m/c (non-ETM) deliver their journeys/ticket sales data in. I've already written the i/f s/w to conv. from s/s -> VFP table (as stated in the thread), so this is approp.
>
>>PS: Put oExcel.Visible = .t. early in code. It's a myth it would slow down (don't be surprised to see it's faster:). Also it has other advantages like allowing you to step your code, if something goes wrong kill excel application by simply closing excel etc.
>>Cetin
>
>That's interesting. I just wanted visible to be at the end so the user doesn't see all the formatting changes flashing of the screen.
>
>Cheers
>
>Terry

Terry,
About visible... One of our reports is excel based and creates tons of charts,worksheets on the fly. It was fast (even on a slow machine max 10secs maybe being less than 5secs on the avg.). Since even 3-5 secs is a lifetime to us foxheads < g > I decided to make it visible and get user feedback. Users loved that. The process were still around 3-5 secs or maybe less but not noticably timewise. However they started to think it was instant being hypnothized by the automatic creation of sheets,charts,formatting. Probably they like to see it's actually doing something rather than believing to a boring hourglass or progress bar etc:)
Cetin