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

"Benny Pedersen" <b.pedersen@xxxxxx> wrote in message
news:7f5f9463-c0a8-4600-a2fe-1c56e117bd1f@xxxxxxSince 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.

"Pegasus (MVP)" <I.can@xxxxxx> wrote in message
news:OrIsmIBdJHA.1132@xxxxxxBesides closing the worksheet 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 spreadsheet 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 worksheet 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
--

On Jan 11, 6:29*pm, "Pegasus \(MVP\)" <I....@xxxxxx> wrote:Thanks Richard and Pegasys for your replys

Because I don't know much Excel syntax, the sledge hammer.(kill excel)
metode was the only solution I could figure out.
The problem came after this:

oExcelApp.activeWorkBook.saveAs sTargetFile
oExcelApp.activeWorkBook.close
oExcelApp.application.quit

After the first line of the above 3 lines, then Excel show a msgbox
with 3 options and one question: "C:\Target already exist. Should it
be overwritten?"
The 3 options is this: YES, NO, Cancel.
If the user press another button than YES, then Excel could freeze (is
open but not visible and not saved).
So instead of CTRL+ALT+Delete and kill, I just constructed a sledge
hammer instead...

Benny

On Jan 11, 7:02*pm, "Richard Mueller [MVP]" <rlmueller-
nos...@xxxxxx> wrote:Thanks

It should be saved after the array was written into the sheet, (of
cause).

Hmm, I would prefer the sheet was left open, so the user self could
save and close the Excel app instead of this:

oExcelApp.activeWorkBook.saveAs sTargetFile
oExcelApp.activeWorkBook.close
oExcelApp.application.quit

"Benny Pedersen" <b.pedersen@xxxxxx> wrote in message
news:2b0d0961-ed36-4f8b-8299-
Thanks Richard and Pegasys for your replys

Because I don't know much Excel syntax, the sledge hammer.(kill excel)
metode was the only solution I could figure out.
The problem came after this:

oExcelApp.activeWorkBook.saveAs sTargetFile
oExcelApp.activeWorkBook.close
oExcelApp.application.quit

After the first line of the above 3 lines, then Excel show a msgbox
with 3 options and one question: "C:\Target already exist. Should it
be overwritten?"
The 3 options is this: YES, NO, Cancel.
If the user press another button than YES, then Excel could freeze (is
open but not visible and not saved).
So instead of CTRL+ALT+Delete and kill, I just constructed a sledge
hammer instead...

Benny

============

Why not let VB Script handle this issue?

if oFSO.FileExists(sTargetFile) then
msgbox " . . . "
[Take appropriate action, e.g. delete the file]
etc.
end if

In this way you stay in control at all times!

On Jan 11, 7:02*pm, "Richard Mueller [MVP]" <rlmueller-
nos...@xxxxxx> wrote:Thanks

It should be saved after the array was written into the sheet, (of
cause).

I would prefer the sheet was saved without the annoying msgbox by
Excel with 3 options
oExcelApp.activeWorkBook.saveAs sTargetFile

But if I can't avoid it, it maybe better the sheet is left open and
visible, so the user self should save and close the Excel app
instead.

oExcelApp.activeWorkBook.saveAs sTargetFile
oExcelApp.activeWorkBook.close
oExcelApp.application.quit

Benny

On Jan 11, 11:13*pm, "Pegasus \(MVP\)" <I....@xxxxxx> wrote:Yes, that is a good idea. Since I already made a backup of the xls
file (see the subrutine named BAK), then I could just fso.delete it
and then save it

Benny

"Benny Pedersen" <b.pedersen@xxxxxx> wrote in message
news:b64bfccd-2a5f-46f5-bed3-6e091142707d@xxxxxx
On Jan 11, 11:13 pm, "Pegasus \(MVP\)" <I....@xxxxxx> wrote:Yes, that is a good idea. Since I already made a backup of the xls
file (see the subrutine named BAK), then I could just fso.delete it
and then save it

Benny

====================

Great! You're now fixing the car with a spanner (the tool intended for car
repairs) instead of the sledge hammer.

On Jan 11, 11:28*pm, "Pegasus \(MVP\)" <I....@xxxxxx> wrote:Yes I thought, but not solved anyway.

When I said "fso.deleteFile(sTargetFile)", Excel said Permision
denied.

So the xml file should not be created before Excel is open. Instead
just write the sheet, then save it. But that would not work neither.
The file should be opened for appending.

I tried to predict some of the problems. So when she later call my
phone about the hang problem, then I could just say use the sledge
hammer...
The poll results will be recived later and I don't know the number of
answers. So maybe there come several columns...

So the hang problem is still unsolved...

Benny

"Benny Pedersen" <b.pedersen@xxxxxx> wrote in message
news:2e1e4cb8-e18f-4429-a174-
Yes I thought, but not solved anyway.

When I said "fso.deleteFile(sTargetFile)", Excel said Permision
denied.

So the xml file should not be created before Excel is open. Instead
just write the sheet, then save it. But that would not work neither.
The file should be opened for appending.

I tried to predict some of the problems. So when she later call my
phone about the hang problem, then I could just say use the sledge
hammer...
The poll results will be recived later and I don't know the number of
answers. So maybe there come several columns...

So the hang problem is still unsolved...

Benny

======================

You need to do a little homework:
- Why is permission denied?
- Is it an NTFS permissions issue?
- Is the file kept open by Excel? If so, why don't you close it first?
- Is the file kept open by another user?
- If you pause the script at the critical spot, can you delete the file with
Explorer?