Passing argument to a running AutoIT EXE - (Moved)

[Nine]

@OhBobSaget  Are you using my latest code ?  I have made a few changes to ensure that all entries are correctly inserted in the DB.  So now it works perfectly using a new entry in the explorer context menu too.  Try also to make your DB as WAL if you still have problem.

ps.  Forgot to tell you that you need to make full path on DB, dll and MergeProc.exe

Edited March 30, 2021 by Nine

[argumentum]

26 minutes ago, OhBobSaget said:

isnt that UDF for mail stuff ?

If you but just tried the code, you'd see that is the simplest of solutions. Mailsolots is like pipes but it queues the "send" so is the database and the listener all in one.
Unless your antivirus won't let mailslots run. Other than that, its what I would use.
If you select and enter more than 15 files from explorer, explorer will know that you are just plain crazy and do nothing.
Thanks for the reply.

[OhBobSaget]

@argumentum

 

Oh that is nice then if i don't need SQLLite and all the DB handling.

I will try the last @nine solution and yours and see what i prefer

Will report soon

 

Again, thanks for your good ideas

[JockoDundee]

15 hours ago, OhBobSaget said:

I will try the last @nine solution and yours and see what i prefer

In that case try this as well:

Local $sPDFDir=@TempDir & "\PDFMerge\", $sArgs, $sFname, $hSearch

DirCreate($sPDFDir)
FileWrite($sPDFDir & @AutoItPID, $CmdLine[1])

If FileMove($sPDFDir & @AutoItPID, $sPDFDir & "master") Then
   Sleep(500)
   $hSearch=FileFindFirstFile($sPDFDir & "*.*")
   Do
      $sArgs&=FileRead($sPDFDir & FileFindNextFile($hSearch)) & " "
   Until @Error
   Run("YourProgram.exe " & $sArgs)
EndIf

Sleep(1000)
DirRemove($sPdfDir, 1)

It’s just the one program, no UDFs, based on the method I described in my first post.  I would have provided code then, but as I said, there doesn’t seem to be an especially elegant method.  However, now that argumentum has thrown down the gauntlet, with his “simplest of all solutions”, I can’t resist

And with all due respect to both @argumentum and @Nine, both whom I do respect, unless your using the their UDFs already, there is little reason to incorporate those libraries just for a convenience script.  
No doubt they will work, but if you want to change something in a year, you may not want to be reacquainting yourself with SQL or mailslots just to do it.
For instance, if you are having problems with my code, you can just comment out the last DirRemove statement, and then look in the sPDFDir directory to see what is happening, it’s all just text files in a directory that disappears after use.

I’ve tested with 10 or so files, just compile the code (without the /console option) to an .exe, and let me know if it runs in your environment ok.

Edited March 31, 2021 by JockoDundee

[OhBobSaget]

@JockoDundee Wow ! Impressive,

It works well without UDF'S of SQL external tools.

Do you know if the sleeps are absolutely required ? i might want to remove them to have better performance

Also had to add quotes to the files paths appended to the $sArgs because there might have spaces in paths/filename.

 

Just on little thing is that it seems that since i added quotes around the paths, i noticed that it seem that one file with no path/filename is registering in the args settings so my main app don't like it.

I will take a look if i can modify so it does not send " " 

For now, my main app receive  "path1\file1.pdf" "path2\file2.pdf" "path3\file3.pdf" "path4\file4.pdf" " "

[JockoDundee]

6 hours ago, OhBobSaget said:

Just on little thing is that it seems that since i added quotes around the paths, i noticed that it seem that one file with no path/filename is registering in the args settings so my main app don't like it.

Try this:

Local $sPDFDir=@TempDir & "\PDFMerge\", $sArgs, $sFname, $hSearch

DirCreate($sPDFDir)
FileWrite($sPDFDir & @AutoItPID, '"' & $CmdLine[1] & '"')

If FileMove($sPDFDir & @AutoItPID, $sPDFDir & "master") Then
   Sleep(500)
   $hSearch=FileFindFirstFile($sPDFDir & "*.*")
   Do
      $sArgs&=FileRead($sPDFDir & FileFindNextFile($hSearch)) & " "
   Until @Error
   Run("YourProgram.exe " & $sArgs)
EndIf

Sleep(1000)
DirRemove($sPdfDir, 1)

 

6 hours ago, OhBobSaget said:

Do you know if the sleeps are absolutely required ? i might want to remove them to have better performance

Some sleep is absolutely required, but its dependent on how fast the machine can launch all the programs which write the file.  

On my machine, I can easily handle 10 in 100ms down from 500ms, probably a good deal more.  But I have a fast machine thats not doing anything else.  If its always running on a well known machine with an expected load, you could probably optimize it quite a bit, just by trial and error.

Regarding the Sleeps, there are two, but they are there for different reasons,  the first one, Sleep(500), is only called by the "master" instance (which should be the one that writes its file first).  This is the sleep that I am talking about above, and that will affect performance as far as launching your target program is concerned.

The second one, Sleep(1000) along with the DirRemove statement, is run by all instances.  However, technically, only the DirRemove statement need be run by the master, without any sleep, like this:

Local $sPDFDir=@TempDir & "\PDFMerge\", $sArgs, $sFname, $hSearch

DirCreate($sPDFDir)
FileWrite($sPDFDir & @AutoItPID, '"' & $CmdLine[1] & '"')

If FileMove($sPDFDir & @AutoItPID, $sPDFDir & "master") Then
   Sleep(500)
   $hSearch=FileFindFirstFile($sPDFDir & "*.*")
   Do
      $sArgs&=FileRead($sPDFDir & FileFindNextFile($hSearch)) & " "
   Until @Error
   DirRemove($sPdfDir, 1)
   Run("YourProgram.exe " & $sArgs)
EndIf

The reason though that I put the final sleep and dirremove for all instances is as a failsafe against the master program crashing somehow before it gets a chance to delete the directory, with the "master" file in it.  If that were to happen, it wouldn't work until the "master" file was removed from the directory, because it would prevent any other instance from becoming the master.

But making all the instances delete the directory, regardless of whether they are master, insures that even if there is a failure, the program will get back on track the next time.

But they need to wait long enough to insure the master has time to read the directory before deleting it.  So it should always be longer than the first sleep.

How much longer is up to you based on similar considerations as to the first sleep, but I wouldn't be surprised if you can get away with Sleep(100) and Sleep(200).  But you need to test it.