Sign in to follow this  
Followers 0
Pao

AutoIt progress bar (steps) from RunOnceEx or batch

12 posts in this topic

#1 ·  Posted (edited)

Hello I'd like to enable a progress bar for some silent installs or tweaks.

I don't want to time it, but instead to increase the steps from the code sections (from RunOnceEx or batch files)

I thought at Autoit script, but i have some problems:

1- I don't know how to pass parameters to an active script, so I only managed to run again the same script with new parameters. Last one kills all of them.. not a very good solution.

2- ProgressOn and ProgressSet maintain the process bar window opened only if I add a sleep(ms) line. That wouldn't be a problem if only the batch file that launches the script wouldn't wait too! Where do I do wrong?

Here is the Autoit script actbar.exe.

It's a test and I'm not expert, so pardon my programming errors

---------------------------------------------------------------------------------------------------------------------------------

If $CMDLINE[0] = 0 Then

Exit

Else

Dim $Max

Dim $Counter

$Max = $CMDLINE[1]

$Counter = $CMDLINE[2]

ProgressOn("Status","","")

ProgressSet(($Counter/$Max)*100,"","Completed " & ($Counter/$Max)*100 & "%")

; I'd like to avoid this

Sleep(2000)

If $Counter = $Max Then

Sleep(2000)

RunWait(@ComSpec & " /c " & 'taskkill /f /im actbar.exe ', "", @SW_HIDE)

Exit

EndIf

EndIf

----------------------------------------------------------------------------------------------------------------------------------

Example for the file that launches the script (could be in RunOnceEx too):

actbar.exe 10 1

(...some code..)

actbar.exe 10 3

(...some code..)

actbar.exe 10 6

(...some code..)

actbar.exe 10 10

Edited by Pao

Share this post


Link to post
Share on other sites



Umm...maybe I'm missing something here, but why not just convert your batch file to an AutoIt script? Command line arguments can only be sent at the initiation of the script. What you're trying to do will just end up opening an individual instance of the script over and over. You could try running one script at the beginning that would bring up your progress gui, and use another script to manipulate the progress bar. I'm not sure it would work though. Personally, I would just convert the batch file to AutoIt.

Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

Ugh.. I have batch and vbs files that modify registry, extract files, add various tweaks, ecc.. converting would be long and full of new errors.

Also I'd like to run the autoit script from RunOnceEx, so the problem would remain (for subcategories)

I knew that my method was poor (+_+)

Anyway I don't know the code, how can I manipulate the progress bar with another script?

Edited by Pao

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

Did this purely as an exercise, I don't recommend doing this in practice. I agree with @zorphnog above regarding using AutoIt to call all your tasks; calling Run(@comspec & " /c yourcommand.exe") within AutoIt is the same as a command line in a batch file..

Example batch file:

start batch-progress.exe
                 echo 10 > %temp%\percent.txt
                 pause
                 echo 20 > %temp%\percent.txt
                 pause
                 echo 30 > %temp%\percent.txt
                 pause
                 echo 40 > %temp%\percent.txt
                 pause
                 echo 50 > %temp%\percent.txt
                 pause
                 echo 60 > %temp%\percent.txt
                 pause
                 echo 70 > %temp%\percent.txt
                 pause
                 echo 80 > %temp%\percent.txt
                 pause
                 echo 90 > %temp%\percent.txt
                 pause
                 echo 100 > %temp%\percent.txt
                 pause

AutoIt progress script:

Dim $quit, $ourNumber, $ourError
           
                 ProgressOn("Gedankenexperiment", "Our story so far:", "", 5)
           
                 Do
                     $ourNumber = FileRead(@TempDir & "\percent.txt")
                     $ourError = @error
                     $ourNumber = Number(StringStripCR($ourNumber))
                     ProgressSet($ourNumber)
                     Sleep(10)
                     If ($ourNumber > 90) Or $ourError Then $quit = 1
                 Until $quit
                 
                 ProgressOff()

Did I say "Don't do this"..? Don't do this. Pure AutoIt3 is better.

P.S. RunOnceEx sounds like something different than what you're speaking of to someone who doesn't work with desktop imaging & deployment.

Edited by DaveF

Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

My understanding of what you want: A way for a command shell batch file to pass progress data to an AutoIt script that will present a GUI progress bar.

Have the batch file write to a file, whose path was given to the AutoIt script in the command line:

REM  <<< Test1.bat >>>

@ECHO OFF

REM Create progress bar
SET PROGRESS_FILE="C:\Temp\MyProgressFile.dat"
SET PROGRESS_TITLE="100 Pings"
SET PROGRESS_VAL=0
ECHO %PROGRESS_VAL% > %PROGRESS_FILE% 
START "Title (ignored)" "Test1.exe" %PROGRESS_FILE% %PROGRESS_TITLE%

REM Update progress bar
For /L %%i IN (1, 1, 100) DO (
    PING 127.0.0.1 -n 1 > NUL
    ECHO %%i > %PROGRESS_FILE%
    ECHO %%i
    )

REM Remove progress bar
ECHO -1 > %PROGRESS_FILE%

The AutoIt script gets the path from the command line and runs the progress bar based on file contents:

; Test1.au3, compiled as Test1.exe

If $CmdLine[0] = 2 Then
    ProgressOn($CmdLine[2], "Progress = ")
    While 1
        Sleep(500)
        $iProgress = Number(FileRead($CmdLine[1]))
        TrayTip("Debug", "$iProgress = " & $iProgress, 5)
        If $iProgress = -1 Then
            ProgressOff()
            Exit
        Else
            ProgressSet($iProgress, "", "Progress = " & $iProgress)
        EndIf
    WEnd
Else
    MsgBox(16, "Error", "Invalid command line parameters: " & $CmdLineRaw)
EndIf

May not be the slick way to do it, but it was fun to try out...

muttley

P.S. And it looks like DaveF beat me to it!

Edited by PsaltyDS

Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

You understood exactly what I wanted to do.

Interesting solutions! (even if not recommended by the authors).

Incredible that the only way to achieve it is with a temp file however (or an autoit for all).

I thought that maybe I could retrieve the process id and pass some global variable or something like that.. dunno lol. muttley

Thanks for the answers! :)

Edited by Pao

Share this post


Link to post
Share on other sites

You understood exactly what I wanted to do.

Interesting solutions! (even if not recommended by the authors).

Incredible that the only way to achieve it is with a temp file however (or an autoit for all).

I thought that maybe I could retrieve the process id and pass some global variable or something like that.. dunno lol. muttley

Thanks for the answers! :)

That's actually quite easy. I would do something like this=

Start by building a script with your GUI/ProgressOn which after start uses _CoProcReciver() to register a window message. Then let that script go into a loop where it does nothing.

Then build another script which you starts through your batch-file that uses _CoProcSend() to send the command line parameters back to the first script (that's updates it's progress) and then the second one closes itself.

You can get CoProc.au3 HERE

So you see there is no need for temp-files if you don't want them.

Share this post


Link to post
Share on other sites

That's actually quite easy. I would do something like this=

Start by building a script with your GUI/ProgressOn which after start uses _CoProcReciver() to register a window message. Then let that script go into a loop where it does nothing.

Then build another script which you starts through your batch-file that uses _CoProcSend() to send the command line parameters back to the first script (that's updates it's progress) and then the second one closes itself.

You can get CoProc.au3 HERE

So you see there is no need for temp-files if you don't want them.

Since the sending process is a command line shell running a batch file... exactly how were you going to send these CoProc messages...?

muttley


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

Incredible that the only way to achieve it is with a temp file however (or an autoit for all).

I thought that maybe I could retrieve the process id and pass some global variable or something like that.. dunno lol. muttley

Just depends how much effort you're willing to go to to avoid the effort of learning more AutoIt. <smile class="angelic" />

Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Share this post


Link to post
Share on other sites

Since the sending process is a command line shell running a batch file... exactly how were you going to send these CoProc messages...?

:)

Didn't you read all of it? One script for the GUI/Progress and one that gets run by the batch that sends a number back to the first

Just depends how much effort you're willing to go to to avoid the effort of learning more AutoIt. <smile class="angelic" />

It took no effort for me to learn those things.... Does that mean I am a genius? muttley :(

Share this post


Link to post
Share on other sites

#11 ·  Posted (edited)

Didn't you read all of it? One script for the GUI/Progress and one that gets run by the batch that sends a number back to the first

You're right. Thought I did, but 'guess not. I see what you mean now: The batch file passes data on the command line to the second script, which uses CoProc to pass it on to the first.

This might be much slower though, as there can be a significant start-up overhead each time the second script is called. File write from the Batch file, and FileRead() in a loop should be much more responsive.

muttley

P.S. If the start-up overhead is not an issue (because updates are not that frequent, for example) your idea could still be implemented with one AutoIt script that just called more than once and either created or updated the progress bar based on the command line switches passed.

:)

Edited by PsaltyDS

Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

#12 ·  Posted (edited)

Thanks also for your suggestion AdmiralAlkex.

Luckly, before trying to enter the scary _CoProcReciver() meanders, I received some other help.

I don't know if I can post links, so I'll write the solution here.

The script:

; Exit if 2 parameters were not used
If $CMDLINE[0] <> 2 Then
    Exit 1
Else
; assign parameters to friendly variable names
    Global $Max = $CMDLINE[1]
    Global $Counter = $CMDLINE[2]

; show progress window
    ProgressOn("Status", "", "")

; set data to progress window
    ProgressSet(($Counter / $Max) * 100, "", "Completed " & ($Counter / $Max) * 100 & "%")

; title to use for the interpreter window title
    Global Const $AUTOIT_TITLE = @ScriptName & '_Interpreter'

; close any previous progress windows
    If WinExists($AUTOIT_TITLE) Then
        Do          
; attempt to close the previous progress window
        WinClose($AUTOIT_TITLE)
        
; perform a sleep if window still exists
        If WinExists($AUTOIT_TITLE) Then
            Sleep(500)
        EndIf

; exit the loop if the window does not exist
        Until Not WinExists($AUTOIT_TITLE)
    EndIf

; set current window as the main interpreter window title
    AutoitWinSetTitle($AUTOIT_TITLE)

; if max is reached, then exit
    If $Counter = $Max Then
        Sleep(2000)
        Exit
    EndIf

EndIf

; keep the current process running
While 1
    Sleep(250)
WEnd

The batch that launches it (working example):

Start actbar.exe 10 1
pause
Start actbar.exe 10 3
pause
Start actbar.exe 10 6
pause
Start actbar.exe 10 10

Remains only one last problem as I'm not able to use "start" from RunOnceEx instead of a batch (the procedure for unattended installs)

Edited by Pao

Share this post


Link to post
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
Sign in to follow this  
Followers 0