Re: system32\tskill.exe And EXCEL by VBS file...

Tech-Archive recommends: Speed Up your PC by fixing your registry


"Pegasus (MVP)" <I.can@xxxxxxxxxx> wrote in message
news:OrIsmIBdJHA.1132@xxxxxxxxxxxxxxxxxxxxxxx

"Benny Pedersen" <b.pedersen@xxxxxxxxxx> wrote in message
news:7f5f9463-c0a8-4600-a2fe-1c56e117bd1f@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hi.

I got a job about writing some txt files into a Excel ***.

Some text1: value1
Some text2: value2
... and so on...

So today I wrote a vbs file, drag and drop the txt file...
The "C:\Target\" folder is created on first run.

The first row with the description (Some text1) is written
on first run. Any other run write the second col (value1)
into the next column.

The next run drag and drop, would write the other values
into the first free colomn, and so on...

A problem I found was that if one said something wrong to the
msgBoxes from Excel, or whatever, then it could freeze the ***...
To avoid that, I simply used the "tskill.exe" as shown.
In other words: Say No to the first question, and the freeze
problem is gone :)

My knowlede about Excel syntax is almost one line, something
like this: oExcel***.cells(1,1).value
so any sugestions would be good :)

Benny Pedersen,
www.fineraw.com
PS. Safe to run, just try:

Since you don't appear to have any specific questions, here are a couple
of general comments. To kill an application such as Excel with
taskkill.exe is equivalent to fixing a car with a sledge hammer. Not
recommended, not good practice. Much better to do things in an orderly
fashion: Close your spreadsheets, either by saving them or with the
"NoSave" option, then set your Excel object to "nothing".

My personal preference (which many people do not share) is to maintain a
strong structure in my programs, e.g. like so:

GetParms
OpenFiles
ConstructArray
PlugInValues
SaveFiles

'-----------------
'Task description
'-----------------
sub GetParms
[code]
end sub
'-----------------
'Task description
'-----------------
sub OpenFiles
[code]
end sub
'-----------------
'Task description
'-----------------
sub ConstructArray
[code]
end sub

The main part of the program is a high-level statement of each task. It
clearly shows the reader the major tasks to be performed. It contains no
code other than invoking various subroutines. Each subroutine performs a
specific, well-defined task such as your KillApp subroutine, preferably
containing no more lines than will fit onto a single screen. It also uses
local variables whenever possible.

You tend to mix the main routine and the subroutines freely, which is
functionally equivalent but which destroys the structure and does not
encourage modular programming. Your main routine goes over dozens of lines
with no visible structure, which often ends up in spaghetti code. When
inspecting a single line of code in such a program you usually have to
untangle the whole program before you can work where it stands in the
scheme of things and what it does. Look at some program that you wrote a
year ago to see what I mean!

Just my two bobs worth.


Besides closing the work*** you should quit the application, but I see
statements that do that in your code. I try to anticipate all possible
errors and trap them so I can close and quit. Otherwise the spread*** is
help open. For every statement that can raise an error (after testing the
script), I have "On Error Resume Next" before, then after the statement I
use "If (Err.Number <> 0) Then" to trap the error and handle it (including
closing the work*** and quitting the app), then I restore normal error
handling with "On Error GoTo 0". If an unanticipated error is raised, I use
Task Manager to kill the app. I always restore normal error handling so if
something unanticated happens I know it. There really is no better solution
in VBScript.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--


.

Quantcast