Posts: 10
Score: 0
Joined: 3/16/2005
From: USA
Status: offline
I made a smaller test version of that script to test adding lines to a message box. I think the "trick" is that the message box just times out after 1 second. As soon as it closes, the loop does its next iteration and the box is shown again almost immediately with data appended to the string. So the message box doesn't really append, it just redisplays quickly.
My test script was a little hard to stop because of this. I had to close the console window while the message box was waiting for input.
Yes, this is what I was referring to...the simulation of realtime echo to a single msgbox. Thanks for looking at it toddio...your script demonstrates this nicely (although, as you said, it's a tad hard to kill). :)
Personally, I think it is a waste of time and energy to find a solution with the sole purpose of giving 'something' to the impatient users while the script is working. I think it is better to educate theusers about something like this rather than spending time and spoil them in the long run. =)
After all, I use scripts to automate administrative tasks to make my life easier, not to complicate it. And if a fellow administrators are too stupid to simply wait for the scripts to finish, their ability to use the scripts should be revoked =)
Posts: 10
Score: 0
Joined: 3/16/2005
From: USA
Status: offline
token: I kind of agree, but having some sort of progress information is useful even for the developer of the script. I think there's a balance to be achieved. You have to take some time to provide useful information, but not go overboard in trying to make it too pretty or user-coddling.
If I see a script is taking 10 minutes to do 100 things, and there are 1000 things to do, I'll know to leave it running and go off and do something else, and check back in about an hour and a half (100 minutes = 1:40). It's also important to see that something's happening, so someone doesn't think the script is hung.
Most of my scripts run in a console window (because I'm an old command-line guy at heart) and will do something like this to show progress:
WScript.StdOut.Write(s & chr(13))
chr(13) moves the cursor back to the start of the line, so multiple calls will overwrite the same line - then print out a number in fixed amount of space and you will get a basic uncluttered progress display that's simple to use without wasting a lot of time and energy
I agree, I also use some, usually when there are a lot of things going on in the background, and I use them to tell me exactly at what *step* it is currently running at.
But my whole point for this was based on the requirement of original post which I can't really remmeber now because I think it kind of overlapped with the discussion of another topic in this thread. It's really simple for me though. If I'm the only one or perhaps among the only 2-3 people, I don't usually implement such things unless I MUST to track the progress. If however, more people are invovled, I'll probably looking for alternatives such as using HTML than console only solutions.
I didn't mean to dilute the original topic of this thread. I saw a nifty parlor trick in that Ostrosoft script, and was curious how it worked. I thought it could help another user's thread, but should've posted it there instead. :)
ahh..heh.. It's alright. We have lots confusion in this particular thread. Getting used to it =)
I guess you already know since it was discussed. Personally, I wouldn't do such things because, 1: it doesn't feel real (it runs minimized for me, so I didn't even see the window popup except very first one), and 2: it is proned to errors.
Well, I'v considered that in the past and came to the conclusion that it was not any easier to do what I wanted to do (might just for me anyway) since the PING is just one of the process out of approximately 20 for each host that needed to run againsted. The problem with any asynchronized events is that it is darn difficult to track which event belongs to which originator. Of course, if you would only need to check the ping status (like what giantlunarmoth *originally* wanted to do, if I remembered that correctly, this thread is really hurting my head :P), async would work (most of the time).
Posts: 10
Score: 0
Joined: 3/16/2005
From: USA
Status: offline
token: > this thread hurts my head
I'd say that a "thread" about "multi-threading" branching into multiple sub-threads sounds somehow appropriate. It's good conceptual practice. =)
So anyway, I came up with a contrived example of multi threading, which is basically a main script running several sub scripts. The main script then watches a text file to wait until all of the sub scripts have finished.
I then went and looked at that ThreadForker routine and it seems to be a similar kind of thing, but with the capability of killing sub processes that run for too long.
However, my example is smaller and simpler and demonstrates multiple scripts reading and writing the same text file, so I'm posting it for everyone's amusement.
I'm going camping this weekend, so if I don't reply its because I'm trading computers for woods and snow for a little while. Will be back Tuesday.
That is similar to a script that i wrote just recently ... i will have to go into work tommorow to snag it and post it up, but basicly I have 2000+ workstations that I need to poll for data (usualy through wmi queries) and waiting on a responce from one computer before asking another computer is painful and can take upwards of 6+ hrs to run. What I did, was take a .txt file full of computernames and have a script i dubbed the "batch.vbs" to read this textfile and start up the second script "*.vbs" (named according to what its searching for) with an arguement of the computername
this is allows me to poll upwards of 30 comptuers a second (limited only by a .sleep command) that keeps me from crashing the machine im running the script from
Edit: forgot to mention that this takes the 6+ hrs of runtime and crams it into 30 min + or - a few with less than 3% network utilization (meaning i can run it durring the day with out slowing the network to a grinding hault)
I dont know if this is exactly what you are looking for, but If it is ... i will post my source by noon tommorow
What exactly did you do with the scripts ? Just pulling data from WMI queries and store them in some place or are you doing something immediately upon receiving the returned queries for the individual computers ?
Darn it .. they decided to do some repair work on the DC over Sat, so I will have to post the scripts on Sun ... i knew i should have kept those scripts localy instead of on the file server oh well.
All Forums >> [Scripting] >> WSH & Client Side VBScript >> Re: MULTITHREADING 
Printable Version
Re: MULTITHREADING - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread