GUICtrlSetData - blocking function or not?

[JohnOne]

When used on a Progress control it seems not to be a blocking function, but rather get's blocked itself by the next blocking function.

I set the progress data, and start InetRead, the control does not update until InetRead is complete, or a timer is employed.

Code explanation...

$hGui = GUICreate("Progress not updating properly", 400, 90)
$Button = GUICtrlCreateButton("Start", 10, 10, 40)
$hProgress = GUICtrlCreateProgress(10, 50, 380)

GUISetState()

While 3
    Switch GUIGetMsg()
        Case -3
            Exit
        Case $Button
            _Func()
    EndSwitch
WEnd

Func _Func()
    Beep(800, 100)
    Local $Timer = TimerInit()
    GUICtrlSetData($hProgress, 50)
    ;I'd expect the progress bar to step directly to middle (50)
    ;But it does not, unless it has sufficient time to doo so with below uncommented timer loop.

    ;Do
    ;Until TimerDiff($Timer) > 800

    InetRead("https://msdn.microsoft.com/en-us/library/windows/desktop/bb760816(v=vs.85).aspx")
    Beep(600, 100)
    For $i = 51 To 100
        GUICtrlSetData($hProgress, $i)
    Next
EndFunc

So is it a blocking function or not, does it just send a message to the control, and it's handled internally, what's going on?

I really would not expect it to work in that fashion.

Edited February 1, 2015 by JohnOne

[Gianni]

I think the block is caused by InetRead
try with InetGet instead and you'll see that it doesn't block

$hGui = GUICreate("Progress not updating properly", 400, 90)
$Button = GUICtrlCreateButton("Start", 10, 10, 40)
$hProgress = GUICtrlCreateProgress(10, 50, 380)

GUISetState()

While 3
    Switch GUIGetMsg()
        Case -3
            Exit
        Case $Button
            _Func()
    EndSwitch
WEnd

Func _Func()
    Beep(800, 100)
    Local $Timer = TimerInit()
    GUICtrlSetData($hProgress, 50)
    ;I'd expect the progress bar to step directly to middle (50)
    ;But it does not, unless it has sufficient time to doo so with below uncommented timer loop.

    ;Do
    ;Until TimerDiff($Timer) > 800

    ; InetRead("https://msdn.microsoft.com/en-us/library/windows/desktop/bb760816(v=vs.85).aspx")
    InetGet("https://msdn.microsoft.com/en-us/library/windows/desktop/bb760816(v=vs.85).aspx","",0,1)
    Beep(600, 100)
    For $i = 51 To 100
        GUICtrlSetData($hProgress, $i)
    Next
EndFunc

edit:

sorry, better reading your post I see that I misunderstood the point...

Edited February 1, 2015 by Chimp

[JohnOne]

I understand that, but if GuiCtrlSetData was blocking I would not need to fart about with files and what not.

[Gianni]

I understand that, but if GuiCtrlSetData was blocking I would not need to fart about with files and what not.

 

... fart?

[mikell]

Hmm the code seems to work as expected...

Press start > beep > updates the progressbar to middle immediately > pauses during the blocking InetRead > 2nd beep > updates the pr. to 100

The behaviour is exactly the same whether the timer loop is commented or not

Edit

Running 3.3.12.0 on XP SP3

Edited February 1, 2015 by mikell

[Gianni]

on my side it blocks after the beep (progress bar remains to 0) and proceed only after InetRead has completed

Edit

Running 3.3.12.0 on win7 x64

Edited February 1, 2015 by Chimp

[JohnOne]

I suppose the real question here is, is this a bug or expected behaviour from a progress control?

[kylomas]

Same as mikell...

edit:  Whoops, sorry...Win7 Home x64 at current maintenance levels running AutoIT 3.3.12.0...

Edited February 2, 2015 by kylomas

[JohnOne]

What OS, k?

Forgot to mention I'm on

3.3.12.0 on win7 32

[LarsJ]

Are you sure that it's not just your PC, there is a little slow on screen updates? If InetRead starts before the screen is updated, then it could explain the problem.

[JohnOne]

I'm pretty sure. On my dev machine I never really have problems with anything really, it responds quickly.

I have tried it on my crap laptop (same) and friends win 8 machine (same).

If I add a sleep instead of timer it works like there was a timer, but rolls up like it goes through 1 to 50 instead of immediately 50.

[LarsJ]

OK. Can you verify this issue with other commands than InetRead? If it's a general bug in the Progress control, it should be possible to see this blocking problem for other similar commands (commands that runs for some time, and probably also uses some resources). Or is the problem related to InetRead?

[JohnOne]

Good point, I'll look into it tomorrow, but I fear I will have to find another function which works in the same fashion as InetRead.

(Not on dev machine at the moment.)