Login  | |
|
 |
RE: Dynamic Activity Window - 1/4/2007 1:14:38 AM
|
|
 |
|
| |
DiGiTAL.SkReAM
Posts: 1171
Score: 7
Joined: 9/6/2005
From: Florida, USA
Status: offline
|
Thanks, Tony.
To answer your questions, I Dim'med those variables via ExecuteGlobal as a hack, since I needed them to be there, but I didn't want to have them declared until after the StartBar sub was run.
And the registry access is there because it is so much faster than dumping text to a file. When I was using text files to hold the status text, in earlier incarnations of the class, I found that after a long run time, the chances of my reading and writing to the file at the same time increased, and eventually, it would crash. by using the registry, the processing is much faster (try timing registry i/o vs. file i/o sometime), and I don't have that worry. I have found that if a script is processing in a linear fashion, using a text file as a temp memory storage area is sometimes ok, but when you have two or more processes accessing that same file... things can get a bit dicey.
_____________________________
"Would you like to touch my monkey?" - Dieter (Mike Meyers)
"It is better to die like a tiger, than to live like a pussy."
-Master Wong, from Balls of Fury
|
|
| |
|
|
|
|
RE: Dynamic Activity Window - 5/21/2007 5:47:23 AM
|
|
|
|
| |
DiGiTAL.SkReAM
Posts: 1171
Score: 7
Joined: 9/6/2005
From: Florida, USA
Status: offline
|
This code was never meant to be run from inside another HTA.
First off, you are including the example code at the beginning, which includes WScript.Sleep commands that are invalid in an HTA.
Secondly, the section where it tries to bring itself to the forefront performs an appactivate on mshta.exe. Well, if you already have an HTA open, mshta.exe is already being used. When the Progressbar ends, it kills the mshta.exe process - which would kill your original HTA as well.
It is kinda like saying "This snowsuit doesn't keep me dry when I am snorkeling! Snow is just frozen water, so it should work! How do I fix it?"
The only answer is: don't use it while snorkeling!
_____________________________
"Would you like to touch my monkey?" - Dieter (Mike Meyers)
"It is better to die like a tiger, than to live like a pussy."
-Master Wong, from Balls of Fury
|
|
| |
|
|
|
|
RE: Dynamic Activity Window - 5/22/2007 1:04:12 AM
|
|
|
|
| |
DiGiTAL.SkReAM
Posts: 1171
Score: 7
Joined: 9/6/2005
From: Florida, USA
Status: offline
|
The same wayt hat you would call any other external vbs file.
Perform a search in the fora for
filesystemobject
arguments
wscript.shell
and then read some of the docs.
You are looking for a way to run an external vbscript from another, while passing arguments to it. I can provide the class, but it is up to you to learn how to use it in conjunction with your own code.
_____________________________
"Would you like to touch my monkey?" - Dieter (Mike Meyers)
"It is better to die like a tiger, than to live like a pussy."
-Master Wong, from Balls of Fury
|
|
| |
|
|
|
|
RE: Dynamic Activity Window - 1/31/2008 3:42:47 AM
|
|
|
|
| |
KroBaar
Posts: 2
Score: 0
Joined: 1/31/2008
Status: offline
|
I know this thread is old, but I just came across this progressbar the other day and I like the way it works, for the most part. I have a few comments regarding it though.
1). Throughout the code, every pointer to an object created is never set to Nothing when you are finished, this poses a memory leak, does it not? As well as using the If CreateObject(...), how is that object released? Shouldn't it be set to some variable x, then set to Nothing when finished?
2). You mentioned to a user that this code wasn't intended to run inside an HTA, which I agree, however, the code can be executed from within an HTA by used of wscript.shell and the run method. In terms of it killing the mshta.exe process, I acutally couldn't find where you do that, and have noticed that if I have multiple HTA applications running, only progressbar closes. However, your call to oShell.AppActivate causes every HTA application to be activated. To Activate only the progressbar, I modified the code a little. I modified your For loop from:
oBarCat.Add oBarCat.Count, "Set cItems = oWMIService.ExecQuery(" & Chr(34) & "SELECT Name, ExecutablePath FROM Win32_Process where Name = 'mshta.exe'" & Chr(34) & ")"
oBarCat.Add oBarCat.Count, " For Each oItem in cItems"
oBarCat.Add oBarCat.Count, " oShell.AppActivate oItem.Handle"
oBarCat.Add oBarCat.Count, " Next"
to:
oBarCat.Add oBarCat.Count, " Set cItems = oWMIService.ExecQuery(" & Chr(34) & "SELECT Name, ExecutablePath, CommandLine FROM Win32_Process where Name = 'mshta.exe'" & Chr(34) & ")"
oBarCat.Add oBarCat.Count, " For Each oItem in cItems"
oBarCat.Add oBarCat.Count, " If oItem.CommandLine = document.Location.pathname Then"
oBarCat.Add oBarCat.Count, " oShell.AppActivate oItem.Handle"
oBarCat.Add oBarCat.Count, " End If"
oBarCat.Add oBarCat.Count, " Next"
This will only activate the HTA that matches the filename running the code, hence progressbar. For that to work, I had to change the select statement and add the column CommandLine to the list you were selecting.
Other mods made:
You hard coded a path on the C: drive which doesn't happen to exist for the workstations at the Corporation I work for:
sProgressBarHTAFileKiller = "c:\temp\htakiller.vbs"
so I made use of an object you were using thoughout for the environment variables and changed the line to:
sProgressBarHTAFileKiller = oEnv("TEMP") & "\htakiller.vbs"
As well, as mentioned before with setting object pointers to Nothing, couldn't this be handled in the class terminate procedure (which would have to be added of course, ProgressBar_Terminate() )? Other than that, it seems to do what I was looking for. : )
|
| | |
Printable Version
