Coordinating 2 Running Scripts

[BruceCopperField]

I am running many scripts concurrently each controlling its own window. Everytime when a script decides that it needs to send out some command it will do this:

WinActivate($mywin)

WinWaitActive($mywin)

Send(...)

Sleep(2000) ; wait for the result to return

; do some checking here

The problem is after one script has issued WinActivate($mywin), it should not be preempted by Windows before its processing is completed. That is, the few lines above should be treated as one atomic unit. So, locking is required.

$tmpSocket= -1

While $tmpSocket = -1

$tmpSocket=TCPListen("127.0.0.1", 65432)

WEnd

WinActivate($mywin)

WinWaitActive($mywin)

Send(...)

Sleep(2000) ; wait for the result to return

TCPCloseSocket($tmpSocket)

I know at anytime Windows only allows one process listening to a port and so by obtaining a socket on a port. I achieve some sort of locking. But, is there a better and more natural way to achieve locking similar to my codes above.

[erezlevi]

I am running many scripts concurrently each controlling its own window. Everytime when a script decides that it needs to send out some command it will do this:

WinActivate($mywin)

WinWaitActive($mywin)

Send(...)

Sleep(2000) ; wait for the result to return

; do some checking here

The problem is after one script has issued WinActivate($mywin), it should not be preempted by Windows before its processing is completed. That is, the few lines above should be treated as one atomic unit. So, locking is required.

$tmpSocket= -1

While $tmpSocket = -1

$tmpSocket=TCPListen("127.0.0.1", 65432)

WEnd

WinActivate($mywin)

WinWaitActive($mywin)

Send(...)

Sleep(2000) ; wait for the result to return

TCPCloseSocket($tmpSocket)

I know at anytime Windows only allows one process listening to a port and so by obtaining a socket on a port. I achieve some sort of locking. But, is there a better and more natural way to achieve locking similar to my codes above.

if it is about the $mywin issue then all script should have the following line:

if not winactive ($mywin) then WinActivate($mywin)
else don't do enything.....

I hope I understood what you watned to achieve here.

[martin]

I am running many scripts concurrently each controlling its own window. Everytime when a script decides that it needs to send out some command it will do this:

WinActivate($mywin)

WinWaitActive($mywin)

Send(...)

Sleep(2000) ; wait for the result to return

; do some checking here

The problem is after one script has issued WinActivate($mywin), it should not be preempted by Windows before its processing is completed. That is, the few lines above should be treated as one atomic unit. So, locking is required.

$tmpSocket= -1

While $tmpSocket = -1

$tmpSocket=TCPListen("127.0.0.1", 65432)

WEnd

WinActivate($mywin)

WinWaitActive($mywin)

Send(...)

Sleep(2000) ; wait for the result to return

TCPCloseSocket($tmpSocket)

I know at anytime Windows only allows one process listening to a port and so by obtaining a socket on a port. I achieve some sort of locking. But, is there a better and more natural way to achieve locking similar to my codes above.

Sounds to me like your best solution would be to use ControlSend which can send to a non active window, or to use messages which are more versatile, more reliable and very much faster.

[BruceCopperField]

I cannot use ControlSend() since the target window don't have control (is it possible to ControlSend() to a target window?). So I have to activate the window first and use regular Send (and also mouseclick()). And in that case, when 2 copies of my script is running concurrently, it is possible that after my first copy has issued a WinActivate(), my second copy also issue its own WinActivate(). So, while my first copy thinks its window is active and starts sending it keystroke, it is actually my second copy's window been activated and receiving the keystroke.

[martin]

I cannot use ControlSend() since the target window don't have control (is it possible to ControlSend() to a target window?). So I have to activate the window first and use regular Send (and also mouseclick()). And in that case, when 2 copies of my script is running concurrently, it is possible that after my first copy has issued a WinActivate(), my second copy also issue its own WinActivate(). So, while my first copy thinks its window is active and starts sending it keystroke, it is actually my second copy's window been activated and receiving the keystroke.

FRom the help file

ControlSend works in a similar way to Send but it can send key strokes directly to a window/control, rather than just to the active window.

[BruceCopperField]

But what value should be used for ControlID, Au3Info doesn't show its ControlId. (It is a game window)

[FreeFry]

It does show control id, and control classname(both which are supported by the ControlSend command)

Wrong.

3d windows doesn't always (or never?) have a control, use "" for the class name/id parameter in such cases.

Edited February 17, 2008 by FreeFry

[SmOke_N]

It does show control id, and control classname(both which are supported by the ControlSend command)

I'm curious on how you "know" that "his" au3info is showing a control ID and a ClassNameNN... (psychic?)

[FreeFry]

Well doesn't all windows have to have a control in them? otherwise they would have no.. content? correct me if im wrong

Edit:

I was going to add that if there was no class name/id then he could just use "" for that parameter, but I wanted to wait for his response first.

Edit2:

Hmm, just tried it on a 3d window, and it has no control. :/ My fault sorry for the miss guiding info I guess. Still the "" for the class name/id parameter should work.

Edited February 17, 2008 by FreeFry

[SmOke_N]

Well doesn't all windows have to have a control in them? otherwise they would have no.. content? correct me if im wrong

Edit:

I was going to add that if there was no class name/id then he could just use "" for that parameter, but I wanted to wait for his response first.

GUICreate("")
GUISetState()
While GUIGetMsg() <> -3
Wend

You could answer your own question there .

[FreeFry]

GUICreate("")
GUISetState()
While GUIGetMsg() <> -3
Wend

You could answer your own question there .

Yeah, I'm aware of that, but is there ever a window? Kinda stupid example if you ask me.. I was assuming that the window would actually have something in it.

In any case, I was wrong about this, 3d windows doesn't seem to have a control.

[SmOke_N]

Yeah, I'm aware of that, but is there ever a window? Kinda stupid example if you ask me.. I was assuming that the window would actually have something in it.

In any case, I was wrong about this, 3d windows doesn't seem to have a control.

A stupid example? ... Do you even know what a control is?

Regardless, your logic is flawed and you are thinking a tad bit inside the box. However, you probably provided a viable solution by leaving the parameter blank all the same.

[FreeFry]

A stupid example? ... Do you even know what a control is?

Regardless, your logic is flawed and you are thinking a tad bit inside the box. However, you probably provided a viable solution by leaving the parameter blank all the same.

Yes, your example was stupid imo. I'm very aware that a window doesn't need to have a control.

My assumption that his game window would have a control, was falsely based on that it would have a control to contain the rendering area, but I was wrong about that.

I'm sorry if I offended your flawless logic I guess.

[SmOke_N]

Yes, your example was stupid imo. I'm very aware that a window doesn't need to have a control.

My assumption that his game window would have a control, was falsely based on that it would have a control to contain the rendering area, but I was wrong about that.

I'm sorry if I offended your flawless logic I guess.

No need to apologize, we can't all know what we are doing at all times

[FreeFry]

lmao.