Jump to content

Forking functions


Guest s_mack
 Share

Recommended Posts

I have a gui and it shows account status information that requires a check to a remote server. Basically, it shows a green light if it connects and a red light if it doesn't (and tries to determine why it couldn't connect). The process of determining the account status takes 2 - 3 seconds.

Here's my problem: I want the gui to continually monitor the status and update on the fly, so I put my _CheckStatus() function within the While/Wend loop of the GUI, right? Problem is, because _CheckStatus() takes a few seconds to finish - it makes for a very crummy GUI session. The GUI is also used interactively for other things so I can't have these constand 2-3 second pauses.

Is there a way to fork the function so that it goes off and does its thing but allows the GUI to continue without waiting for it to return? Then, when it does return it'll just update some variable which will tell the gui to show green or red.

Does that make sense?

Thanks

- Steven

Link to comment
Share on other sites

you can't do 2 think at time with autoit! i suggest you start 2 script!

and exchange information between it! with the Clipboard, environement variable, file or registry.

clipboard it the worst solution for comunicated between 2 script!

or maybe we can look at your function who take 2-3 seconde to complete and try make it faster!

GreenseedMCSE+I, CCNA, A+Canada, QuebecMake Love Around You.

Link to comment
Share on other sites

Awww fork! So I'm just forked? That forking sucks! (ok, I'm done lol)

Ok, so AutoIt can't multi-thread at all then, that's what you are saying?

Now that I know that I can attempt to look for a different solution. Like you say, I can write a seperate script that all it does is _CheckStatus over and over and whenever it finds a good connection, it writes "good" to a text file and when it finds a bad connection, it writes "bad". Then the main script just has to read the file constantly and show a green or red light based on what it finds.

Its not quite as elegant but I should be able to get it to work. Thanks.

- Steve

Link to comment
Share on other sites

Do you know the name of the account whose status you are checking well before you have to check it? That is, could you simply have a gui with all of your accounts on it as buttons. Green for "good" and red for "bad". That display could be running all the time and changing as accounts come and go.

If you have too many accounts or you do not know the account name until just before you have to check it, then the closest you can come to "real time" is the time it takes to check that one account. As Greenseed said, give us some insight into the way you check the account and maybe we can speed it up.

I use AutoIT's PING function to check if a computer is online. Then I use Sysinternals' PSLOGGEDON to get the username if someone is logged on. Both of these processes take a few seconds, but it's easier than hoofing over to the machine and eyeballing it...

...by the way, it's pronounced: "JIF"... Bob Berry --- inventor of the GIF format
Link to comment
Share on other sites

Well - its a very unique situation I think so I'm not sure if there's much value to explaining the process. I thank you for wanting to help, bu that side of things is where my expertise lies so I'm comfortable in saying it can not be improved upon because it is simply the only way to verify a connection with this server. It just happens to take a couple of seconds to confirm.

No, there's not going to be any way of speeding up the _CheckStatus function I'm afraid. Threading is really the only way to do this. Its ok :P I just assumed AutoIt would have some support for this but its ok that it doesn't... its just good to know so I can stop scouring the help files.

It doesn't really matter that it takes that long either. See, the gui is a configuration screen that allows the user to change certain settings but I also want it to be used as a troubleshooting screen so they can quickly check to see if they are able to negotiate with the server. The fact that it takes a few seconds to go from red to green, or vice versa, is fine - I just don't want it getting in their way if they are currently trying to change settings or run other processes from the config screen. There are a few functions that the user will initiate that will require a connection, and at that point we go back to an in-line processing of the _CheckStatus() command because we are now dependent on its result.

I just really wanted to do everything from one file because it is more elegant. Certainly not the end of the world.

- Steven

Link to comment
Share on other sites

of course... a MUCH simpler thing to do (and what I will likely choose) is to nix the whole idea of having the status updated in (semi)real-time. I can just have it check the status with a "please wait' upon startup and have a button labeled "recheck status" that they can hit if they think they have a problem. I personally would rather go this route over creating a second hovering process to worry about.

- Steven

Link to comment
Share on other sites

I just really wanted to do everything from one file because it is more elegant. Certainly not the end of the world.

- Steven

Its been awhile since I was last in the fourm but I just happened to be playing around with this exact same question today myself. I figured out a way to do this. There may very well be a better way.

I used a case statement at the very top of my script that checks for passed command line arguments.

If no arguments are found then call the same script but with an argument.

If when called, there is an argument then jump to that procedure.

This way everything is in one file but it calls multiple copies of itsself that can all run concurenlty.

Hope that made sence.

Here is the very start of my startup script.

; call again with args to simulate multi thread ability.
Select
    Case $CmdLine[0] = 0; no args then call with args
        $start2pid = Run(@AutoItExe & ' "' & @ScriptFullPath & '" start2')
        $start3pid = Run(@AutoItExe & ' "' & @ScriptFullPath & '" start3')
        
    Case $CmdLine[1] = 'start2'
        start2()
        
    Case $CmdLine[1] = 'start3'
        start3()
EndSelect

It then continues with the meat of the code for the startup script. At the verry end are start2() and start3() produres that get called as seperate running instrances of code from the above lines.

Basicly I had start2 and start3 as seperate scripts because I needed them to run independently of the main startup script. Now they are all one file instead of 3 seperate files.

Edited by cal
Link to comment
Share on other sites

Hmm... that's clever. It isn't true multithreading so it does introduce the problem of one instance crashing and the other not knowing it... but it just might work!

Thanks!

- Steven

Link to comment
Share on other sites

Hmm... that's clever. It isn't true multithreading so it does introduce the problem of one instance crashing and the other not knowing it... but it just might work!

Thanks!

- Steven

Your welcome. Now if I could just remember what it was that I came to the forums yesterday to find before I got sidetracked by this.

In regards to crash detection.

Sometimes my main startup script can get stuck waiting for certain conditions to occur. The main loop sets a counter to 0. Other called procedures increment it to 1 when they start and reset it to 0 when they are done. Problem is that they take different amounts of times to run. Or get might even get stuck waiting.

To detect this I use adlib to increment that counter every 30 seconds if its not at 0. If 4 minutes pass without it being reset to 0 elsewhere in the script then I'm alerted that it got stuck waiting for some condition to be true.

If this condition is reached the script automatically restarts itself so its back to running the default loops.

(well.... it will in a few minutes now that I've thought about it. That will be easy to add since I've already got it set to kill other running copies with the same internal window name if I restart it manually with it already running. This makes it easy to make changes and then relaunch the script without having to kill the first copy.)

You could modify that slightly to give each instance of the script a different window name and then have each copy of the running script check with adlib to ensure that all others are active say once every couple of minutes. If not all running then any of them could alert you with a popup saying what instance of the script has crashed.

Ok. Now I'm sidetracked even more and I still can't remember the original reason I stopped by.

Oh well. I've got a script to modify. I'm sure the other reason for stopping by will come to me.

Link to comment
Share on other sites

I have a gui and it shows account status information that requires a check to a remote server. Basically, it shows a green light if it connects and a red light if it doesn't (and tries to determine why it couldn't connect). The process of determining the account status takes 2 - 3 seconds.

Here's my problem: I want the gui to continually monitor the status and update on the fly, so I put my _CheckStatus() function within the While/Wend loop of the GUI, right? Problem is, because _CheckStatus() takes a few seconds to finish - it makes for a very crummy GUI session. The GUI is also used interactively for other things so I can't have these constand 2-3 second pauses.

Is there a way to fork the function so that it goes off and does its thing but allows the GUI to continue without waiting for it to return? Then, when it does return it'll just update some variable which will tell the gui to show green or red.

Does that make sense?

Thanks

- Steven

in looking through this thread it seems like you're making things more difficult for yourself...there is no reason it should take 2-3 seconds to check what color an indicator is. check out PixelChecksum(). You can find out the checksum values for red or green before hand by just doing:

$checksum = PixelChecksum(0,0, 50,50)
msgbox(0,"Red",$checksum)

with the coordinates for the $checksum assignment set to values that will make the box being evaluated a very small box completely inside the red/green indicator. assuming that it's only going to be red or green, you can have certain things happen if it's red or green based on a condition check. the PixelChecksum() solution will probably be alot quicker than whatever you're doing now. And regardless of how confident you are that your solution to an issue is the "best", "only", or "right" way to do something, i assure you that someone here can improve on it for you. If you check the red/green status the way i suggest above, and have a boolean variable toggled within the script, you could have an adlib function act accordingly, interrupting the script only when absolutely necessary based on a status change.

Link to comment
Share on other sites

Umm... no, that wouldn't work. You missed the point. Cause and effect. I have to check for a valid authenticated connection with a server, and THEN display red or green based on what I find. The color of the light has absolutely nothing to do with it other than offers up a visual cue to the user.

And I assure you, nobody here can improve upon the _CheckStatus function (at least not in terms of reducing the delay from 2-3 seconds) simply because it is the way it is and the 2-3 second delay occurs outside of the realm of AutoIt so the world's most advanced AutoIt scripter can not do any better - it has nothing to do with AutoIt :P

Like many others on this forum, you chose to read a simple statement of fact as an insult and/or arrogance. It was neither... it just is what is is.

- Steven

Link to comment
Share on other sites

Umm... no, that wouldn't work. You missed the point. Cause and effect. I have to check for a valid authenticated connection with a server, and THEN display red or green based on what I find. The color of the light has absolutely nothing to do with it other than offers up a visual cue to the user.

And I assure you, nobody here can improve upon the _CheckStatus function (at least not in terms of reducing the delay from 2-3 seconds) simply because it is the way it is and the 2-3 second delay occurs outside of the realm of AutoIt so the world's most advanced AutoIt scripter can not do any better - it has nothing to do with AutoIt :P

Like many others on this forum, you chose to read a simple statement of fact as an insult and/or arrogance. It was neither... it just is what is is.

- Steven

I will definitely admit to misinterpretting what you were trying to do. as far as noone being able to improve on your function, you just keep thinking that. If something is happening in windows, it is theoretically NOT "outside of the realm of AutoIt, and there is never just one way to solve a problem. so for you to say that yours is the best or only way, is just stupid. Also, i was not taking anything as an insult, i was trying to help you understand that you could get more help by showing what you have already. You are obviously resistant to help, so i won't waste time reading your posts anymore. jackass

Link to comment
Share on other sites

I'm not at all resistant to help... and AGAIN, you focus on things you know nothing of and assume it is arrogance.

I have NOT DOUBT that others know more of certain things than I do, but I am as certain that there is nothing to be improved upon here, beyond massive undertakings reconfiguring thousands upon thousands of man hours reconfiguring the server platform and authentication medium, as I am certain the sun will rise and fall my friend.

You simply ASSUME that I don't know what I am talking about and that I am being arrogant in the matter. I am not. I simply didn't want to waste anyone's time on that end of the equation because that isn't the end I need help on! All I wanted, as clearly explained above, was guidance with threading and, failing that as an option, simulating it as best I can. Which is what Cal kindly did.

I suggest you take back your "stupid" and "jackass" comments, or at the very least attempt to avoid jumping to such conclusions in the future.

But hey, by all means! Go nuts... you tell me how this can possibly see an improvement of 2-3 seconds.

Func _CheckStatus
$result = RunWait ( 'DAB_Status -k ' & '"$TornVector"' & ' -u ' & $user & ' -v', $BASE, @SW_HIDE )
return $result
EndFunc

And I bet your only answer will be to investigate the executable DAB_Status, and that's simply not feasible. At *THAT* point, I would concede that possibly there are some advanced C coders that could conceivably improve the speed of that function but that is like setting out to remove the bottom brick of the Great Pyramid because its got a scuff mark on it. Its not going to happen. Even then, there's no way it could be taken from 2-3 seconds down to a few milliseconds, which would be required to make it usefull withing the confines of a tight loop.

But why should I have to bore everyone with this extremely unique case (have you ever heard of DAB_Status before?) just to justify my statement that I got that end of it covered?

- Steven

Link to comment
Share on other sites

maybe you should try objget()

look at this code! you can make it connect to remote active directory, domain or not!

then you can check all account in 1 time and autoit can continue to work!

the objget() run externaly of autoit process I THINK! then you have a kind of multi-threading

look in HKCR(regestry) there are all objget() valide class. the one your are looking for is the one who manage the connection, Active Directory, the class object is "winnt"

i found a sample code working with that! im trying to understand more on msdn site but maybe your are good with ADSI call!

the code is not the solution you are looking for but point you the direction! not wrote by me. don't know who did.

$colGroups = ObjGet("WinNT://" & @ComputerName)
Dim $Array[1]
$Array[0] = "group"
$colGroups.Filter = $Array

For $objGroup In $colGroups
    For $objUser In $objGroup.Members
        If $objUser.Name = @UserName Then
            MsgBox(0, "test", $objGroup.Name)
        EndIf
    Next
Next

bye bye hope this help!

Edited by Greenseed

GreenseedMCSE+I, CCNA, A+Canada, QuebecMake Love Around You.

Link to comment
Share on other sites

I know you said you didnt really want to have two scripts, but I figured I would offer one last semi-solution that I see.

Well now I am questioning whether or not it would really have to have two scripts. You can have two GUI's.

One way would be to definitely have two scripts. One showing the status if the user so chooses to have that window displayed.

The other way is to still include everything in the first script and look at the advanced GUIGetMsg() part.

Gaah I feel I cannot explain this better, and the script I would use as an example is on a laptop harddrive that I cannot access right now. I will try and access it tomorrow if you are interested in this solution.

JS

AutoIt Links

File-String Hash Plugin Updated! 04-02-2008 Plugins have been discontinued. I just found out.

ComputerGetInfo UDF's Updated! 11-23-2006

External Links

Vortex Revolutions Engineer / Inventor (Web, Desktop, and Mobile Applications, Hardware Gizmos, Consulting, and more)

Link to comment
Share on other sites

Would AdlibEnable help you?

J

this thread kind of jumped to another topic that the OP had, and a solution was offered there, standard multi-threading simulation was the final suggestion, have one script call compiled second script so the two can run simultaneously. An adlib function would still leave the main body of the script paused during the execution of the ad-lib.

Link to comment
Share on other sites

This may not be an efficient way of doing things, but out of pure curiousity and fascination with AutoIt's TCP functions, it would be possible to use the idea of the script calling itself with a parameter, combined with the TCP functions to pass data and track the secondary processes.

For instance, on the initial run (with no parameters), the script sets up a TCP server and runs itself with a parameter. The second instance, seeing the parameter, would connect to the first instance as a TCP client, then use AdLib to periodically send a keep-alive to the main process while it's waiting for an answer from the authentication checking function. The main process would know if the secondary process has hung when it has missed several heartbeats, and forcibly kills that process and tries again if necessary. In addition, the secondary process could just loop forever, checking authentication and updating a variable whose value would be sent with the heartbeat to the server without affecting the GUI of the first instance. During the loop in the second instance, if it loses connectivity with the server it quits quietly.

Let me know if that's too confusing. I might slap together some code later.

*EDIT* Are you sure you want to have multiple people looping to check authentication? Depending on your server's resources and the number of processes doing the checking, you could adversely affect the performance of your server. You might want to slow it down to checking every 30 seconds or more.

Edited by c0deWorm

My UDFs: ExitCodes

Link to comment
Share on other sites

This may not be an efficient way of doing things, but out of pure curiousity and fascination with AutoIt's TCP functions, it would be possible to use the idea of the script calling itself with a parameter, combined with the TCP functions to pass data and track the secondary processes.

For instance, on the initial run (with no parameters), the script sets up a TCP server and runs itself with a parameter. The second instance, seeing the parameter, would connect to the first instance as a TCP client, then use AdLib to periodically send a keep-alive to the main process while it's waiting for an answer from the authentication checking function. The main process would know if the secondary process has hung when it has missed several heartbeats, and forcibly kills that process and tries again if necessary. In addition, the secondary process could just loop forever, checking authentication and updating a variable whose value would be sent with the heartbeat to the server without affecting the GUI of the first instance. During the loop in the second instance, if it loses connectivity with the server it quits quietly.

Let me know if that's too confusing. I might slap together some code later.

*EDIT* Are you sure you want to have multiple people looping to check authentication? Depending on your server's resources and the number of processes doing the checking, you could adversely affect the performance of your server. You might want to slow it down to checking every 30 seconds or more.

Actually what is going on, is he has a run() that calls an external program to check reason for disconnect if the connection to the server is lost, but the other program takes a few seconds to respond, so at ever iteration when the server is disconnected, he's burning a few seconds. It's not really an authentication script from my understanding, just shows the status. My last suggestion to him, which i think he was going to try to implement, was to remove the function that calls the other program, and make it it's own compiled script. so he could call his own .exe with a run() and continue operation of the main script, while the second script finds out why the server is down, and updates the GUI when it's done...
Link to comment
Share on other sites

Actually what is going on, is he has a run() that calls an external program to check reason for disconnect if the connection to the server is lost, but the other program takes a few seconds to respond, so at ever iteration when the server is disconnected, he's burning a few seconds. It's not really an authentication script from my understanding, just shows the status. My last suggestion to him, which i think he was going to try to implement, was to remove the function that calls the other program, and make it it's own compiled script. so he could call his own .exe with a run() and continue operation of the main script, while the second script finds out why the server is down, and updates the GUI when it's done...

By "authentication script" I meant the part of his AutoIt program that is doing the check... Meaning the function in his code that calls the program that checks the reason for the disconnect. My idea was addressing the communication between the two processes... i.e. using TCP rather than using files. Edited by c0deWorm

My UDFs: ExitCodes

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...