process X to close process Y with a OnAutoItExitRegister()

[JackDinn]

Is there a way to get one AI process to close another but still having the OnAutoItExitRegister() still execute ?

e.g.

Iv got 2 AI processes , process X and process Y (both compiled)

Process Y has OnAutoItExitRegister() set

i need process X to close process Y

I need process Y to execute the OnAutoItExitRegister() function before it actually closes.

ProcessClose() does not work

iv tried the console command taskkill /im processY.exe and taskkill /f /im processY.exe

Im not sure what else to try, any suggestions, thx.

[KaFu]

Implement a message handler for to process Y and make process X send a close message on which process Y closes itself.

[JackDinn]

hmm i thought there might be a way to send a close message , but do you think it will work whilst processY is "busy" with a _FTP_FilePut() half way though ?

[KaFu]

Afaik message handling interrupts the normal processing. But give me a minute to try just sending a WM_CLOSE to a sub-process...

[KaFu]

Yep, seems to work too ....

Process Y:

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

Local $msg

OnAutoItExitRegister("_Exit")

GUICreate("My GUI") ; will create a dialog box that when displayed is centered

GUIRegisterMsg($WM_CLOSE, "WM_CLOSE")

GUISetState(@SW_SHOW) ; will display an empty dialog box

; Run the GUI until the dialog is closed
While 1
    sleep(10)
WEnd
GUIDelete()

Func WM_CLOSE($hWnd, $msg, $wParam, $lParam)
    If $msg = $WM_CLOSE Then Exit
EndFunc   ;==>WM_CLOSE

Func _Exit()
    MsgBox(0, "", "Test")
EndFunc   ;==>_Exit

Process X:

#include <SendMessage.au3>
#include <WindowsConstants.au3>

Local $hwnd = WinGetHandle("My GUI")
_SendMessage($hwnd, $WM_CLOSE, 0, 0)

Edit:

Even seems to work without handling WM_CLOSE yourself , just try to send WM_CLOSE to the target process (window) should work. If that process has no window... add a dummy to receive the messages and do not show it....

Edit2:

Hmmm, it seems the WM_CLOSE was handled by the GUIGetMsg(), so if your currently processing it seems you better at the WM_CLOSE handling yourself via GUIRegisterMsg like in the example above... but sending a WinClose("My GUI") seems to be enough then, not extra _SendMessage() call needed (as it's exactly what WinClose() does).

Edited February 10, 2012 by KaFu

[JackDinn]

great stuff , just trying to get my head around what your doing here but shall get back to you if i have any problems.

Many thx

[JackDinn]

well i see what you up to here but it didnt work in my case, the message gets sent but processY never gets to Func WM_CLOSE. and the GUI (which i left showing atm) freezes with the "not responding" in the title bar.

processY continues to upload with the _FTP_FilePut() until i manually kill it

EDIT:- I am using the GUIRegisterMsg($WM_CLOSE, "WM_CLOSE") method

Also tried an adlib at 3 secs just to see what happens and even that does not "break" into the ftpfileput

Edited February 10, 2012 by JackDinn

[KaFu]

Well... the reason seems to be that _FTP_FilePut() takes your data and uploads it in a single uninterruptible dllcall... try to use something like _FTP_ProgressUpload().

Add the WM_CLOSE message handler as described above. If a WM_CLOSE is received set a global variable $bEXIT to true. In the _UpdateProgress() skip the parts on the progress display and test if $bEXIT is true. If so, interrupt upload and issue an Exit call.

Edit:

To catch the interrupt faster you might want to copy the _FTP_ProgressUpload() UDF function to a custom _FTP_ProgressUpload_Ex() function and reduce the Local Const $ChunkSize = 256 * 1024 to something more like Local Const $ChunkSize = 8 * 1024 (depending on your expected upload speed )....

Edited February 10, 2012 by KaFu

[JackDinn]

i cant use uploadprogress , iv tried before , it just splits the file into 100 parts and the uses ftpwritefile to write in chunks , problem is it for an upload speed test and some people have very slow upload speeds and some have very fast ones so if i choose a large file to cover the very fast people then the very slow people take ages to upload a single chunk and again we are back with the same problem of trying to stop it while its in the middle of a chunk.

Its hard to explain but iv been trying to get my upload testing working 100% , i need to upload for a user set period of time and then end the upload, it also needs to be able to be stopped mid-stream by the user.

The best iv got so far (and iv got many people using it atm) is to run the ftp upload from a child process of the main program, then using performance counters to measure the throughput, and finally processclose() from the main program to kill the child thats doing the upload.

It work well and i would just leave it at that but theres been some comment that on occasion when the child is killed the connection is being left open to the server, so i was trying to figure a way to get the child to close the connection properly before exiting.

I had though i might be able to get the handle of the $Open = _FTP_Open('MyFTP Contr') from the child and pass it to the main program and there _FTP_Close($Open) close it but that didn't work either :-/

Been trying to figure this one for a long time now and just cant figure it.

[KaFu]

What's the drawback for the people on fast lines if you copy the function and reduce the chunk size drastically like I've suggest above?

[JackDinn]

iv tried all that (prob spent a month on that one) , trying to change the chunk size to fit in with the users connection speed , it just didnt work, even if you knew the speed of there connection before the test started the speed of the throughput can be highly variable , so i tried to adjust the chunk size "on the fly" but it was getting some really odd results , and also for some reason it would not measure above 2Mb/s using chunks of data of any size that were still small enough to be stopped without a massive "hang time". In the end i decided it just had to be a constant flow of data.

As i say it works fine except for this problem of the ftp connection being "left over" sometimes , iv sorted a php script to close any left open connections on our "default" servers but people who are using it to test to there own servers might have a problem of loads of non-active connections after a day or so of tests.

It was just a though that i might be able to get the child to close the connection before it completely exits so was sure worth asking on just that point.

Cheers.

[KaFu]

Hmmm, I still don't see the drawback on fast lines if you choose a small chunksize to fit for all like e.g. Local Const $ChunkSize = 4 * 1024....

[JackDinn]

the smaller the chunk size the slower it could upload at , so making the chunks very small was making the maximum upload possible very slow (maybe something to do with processing each chunk, im not sure) and as you increase the chunk size the max upload speed goes up sure but by the time you get to about 2-3Mb/s possible throughput the chunks are to big and take to long to be able to stop without a "hang time" while it finishes its current chunk, there just was no happy medium !

Then theres the fact the throughputs go up and down and if it looked at the last chunks speed and adjusted the next chunk size for thatspeed (best fit which there is not anyhow) if then the speed dropped for half a sec or whatever the chunk would be much to big and would again cause a hang.

I do still use my best attempts at your described method (the user can set the test to either use the performance counters & the child for upload or the old method (the one your describing here)) but it still has a max upload measurement of 2Mb/s , i could have altered it to work for fast connections but it wouldn't have worked on slow ones and since most people have less then 1Mb/s up i left it at that.

The child process and performance counters method is pretty much spot on from 20Kb/s to XGb/s just leaves these connections behind on occasion.

Im sure others could do this much better than me , iv prob missed or messed something up but i also thought what your suggesting would work to but after weeks of messing with it i just could not get it to be accurate for everyone.

[KaFu]

Looking at the original _FTP_ProgressUpload() function I see a Sleep(10) call ... I guess that call is making the function slow when using small chunk sizes... maybe give this stripped version a try, $b_Global_Exit needs to be a global variable and has to be set to true in the GUIRegisterMsg($WM_CLOSE, "WM_CLOSE") function to abort upload and exit.

expandcollapse popup

Func _FTP_Upload_Ex($l_FTPSession, $s_LocalFile, $s_RemoteFile)
    If $__ghWinInet_FTP = -1 Then Return SetError(-2, 0, 0)
    Local $fhandle = FileOpen($s_LocalFile, 16)
    If @error Then Return SetError(-1, _WinAPI_GetLastError(), 0)
    Local $ai_ftpopenfile = DllCall($__ghWinInet_FTP, 'handle', 'FtpOpenFileW', 'handle', $l_FTPSession, 'wstr', $s_RemoteFile, 'dword', $GENERIC_WRITE, 'dword', $FTP_TRANSFER_TYPE_BINARY, 'dword_ptr', 0)
    If @error Or $ai_ftpopenfile[0] = 0 Then Return SetError(-3, _WinAPI_GetLastError(), 0)
    Local $glen = FileGetSize($s_LocalFile) ; only save up to 2GB, better use _winapi_filegetsizeex
    Local Const $ChunkSize = 4 * 1024
    Local $last = Mod($glen, $ChunkSize)
    Local $parts = Ceiling($glen / $ChunkSize)
    Local $buffer = DllStructCreate("byte[" & $ChunkSize & "]")
    Local $ai_InternetCloseHandle, $ai_ftpwrite, $out, $ret, $lasterror
    Local $x = $ChunkSize
    Local $done = 0
    For $i = 1 To $parts
        If $i = $parts And $last > 0 Then
            $x = $last
        EndIf
        DllStructSetData($buffer, 1, FileRead($fhandle, $x))
        $ai_ftpwrite = DllCall($__ghWinInet_FTP, 'bool', 'InternetWriteFile', 'handle', $ai_ftpopenfile[0], 'struct*', $buffer, 'dword', $x, 'dword*', $out)
        If @error Or $ai_ftpwrite[0] = 0 Then
            $lasterror = _WinAPI_GetLastError()
            $ai_InternetCloseHandle = DllCall($__ghWinInet_FTP, 'bool', 'InternetCloseHandle', 'handle', $ai_ftpopenfile[0])
            ; No need to test @error.
            FileClose($fhandle)
            Return SetError(-4, $lasterror, 0)
        EndIf
        $done += $x
        If $b_Global_Exit Then
            $lasterror = @error
            $ai_InternetCloseHandle = DllCall($__ghWinInet_FTP, 'bool', 'InternetCloseHandle', 'handle', $ai_ftpopenfile[0])
            ; No need to test @error.
            DllCall($__ghWinInet_FTP, 'bool', 'FtpDeleteFileW', 'handle', $l_FTPSession, 'wstr', $s_RemoteFile)
            ; No need to test @error.
            FileClose($fhandle)
            Exit
            ;Return SetError(-6, $lasterror, $ret)
        EndIf
    Next
    FileClose($fhandle)
    $ai_InternetCloseHandle = DllCall($__ghWinInet_FTP, 'bool', 'InternetCloseHandle', 'handle', $ai_ftpopenfile[0])
    ; No need to test @error.
    If @error Or $ai_InternetCloseHandle[0] = 0 Then Return SetError(-5, _WinAPI_GetLastError(), 0)
    Return 1
EndFunc   ;==>_FTP_Upload_Ex

Edited February 11, 2012 by KaFu

[JackDinn]

Func _ftp_filewrite_junk_bytes($connection, $FileOpen, $dwNumberOfBytesTowrite)
$lpdwNumberOfBytesWritten = 0
Dim $nBytes
$tBuffer = DllStructCreate("byte[" & $dwNumberOfBytesTowrite & "]")
For $e = 1 To $dwNumberOfBytesTowrite
  DllStructSetData($tBuffer, 1, 255, $e)
Next
If $connection Then
  If $FileOpen Then
   $OutPtr = DllStructGetPtr($tBuffer)
   $RT = DllCall($__ghWinInet_FTP, 'int', 'InternetWriteFile', 'handle', $FileOpen, 'ptr', $OutPtr, 'dword', $dwNumberOfBytesTowrite, 'dword*', 0)
   If @error Then
    Return -1
   Else
    $lpdwNumberOfBytesWritten = $RT[4]
   EndIf
  EndIf
EndIf
Return $lpdwNumberOfBytesWritten
EndFunc   ;==>_ftp_filewrite_junk_bytes

na i already took the sleep out and hashed up that func to just pump up "junk" Bytes of X size from the upload function , iv been there done that , you can see how iv allowed for variable size chunks to be sent on each loop.

Although you might be able to see something in my func that iv got wrong

[JackDinn]

i suppose it could well be the processing that im doing between each loop to that func but i cant remove any of it as it shows the graph of the throughput as it happens and handles the cancel button and some other stuff.