Could someone confirm this?

colafrysen · July 7, 2009

I am creating GUI with an progressbar embeded in the statusbar.

The problem is that when i minimize the GUI and then restore it again the progressbar appears in the

lower left corner of the applications window.

I thought that this was a problem with the embeded progressbar and not with my code.

So I checked the example from the helpfile: (_GUICtrlStatusBar_EmbedControl)

#include <GuiConstantsEx.au3>
#include <GuiStatusBar.au3>
#include <ProgressConstants.au3>
#include <SendMessage.au3>

Opt('MustDeclareVars', 1)

$Debug_SB = False ; Check ClassName being passed to functions, set to True and use a handle to another control to see it work

_Main()

Func _Main()

Local $hGUI, $hProgress, $hInput, $input, $progress, $hStatus
Local $aParts[4] = [80, 160, 300, -1]
; Create GUI
$hGUI = GUICreate("StatusBar Embed Control", 400, 300)

;===============================================================================
; defaults to 1 part, no text
$hStatus = _GUICtrlStatusBar_Create ($hGUI)
_GUICtrlStatusBar_SetMinHeight ($hStatus, 20)

;===============================================================================
GUISetState()

; Initialize parts
_GUICtrlStatusBar_SetParts ($hStatus, $aParts)
_GUICtrlStatusBar_SetText ($hStatus, "Part 1")
_GUICtrlStatusBar_SetText ($hStatus, "Part 2", 1)

; Embed a progress bar
If @OSTYPE = "WIN32_WINDOWS" Then
$progress = GUICtrlCreateProgress(0, 0, -1, -1, $PBS_SMOOTH)
$hProgress = GUICtrlGetHandle($progress)
_GUICtrlStatusBar_EmbedControl ($hStatus, 2, $hProgress)
Else
$progress = GUICtrlCreateProgress(0, 0, -1, -1, $PBS_MARQUEE) ; marquee works on Win XP and above
$hProgress = GUICtrlGetHandle($progress)
_GUICtrlStatusBar_EmbedControl ($hStatus, 2, $hProgress)
_SendMessage($hProgress, $PBM_SETMARQUEE, True, 200) ; marquee works on Win XP and above
EndIf
$input = GUICtrlCreateInput("This is Embeded", 0, 0)
$hInput = GUICtrlGetHandle($input)
_GUICtrlStatusBar_EmbedControl ($hStatus, 3, $hInput, 3)

; Loop until user exits
Do
Until GUIGetMsg() = $GUI_EVENT_CLOSE
GUIDelete()
EndFunc   ;==>_Main

Note: 1. The example has not been changed between Beta and Release

2. I have been testing the code with both Beta and Release

So When i run this code it works fine, until i minimize and restore the window (the restore leads Au

toIt.exe to a crash)

so now i'm just wondering if this error ocurrs on other computers, before i'll create an issue in the issue tracker.

Thanks

Bowmore · July 7, 2009

It's the expected behavior.

It's up to your code to control and restore the position of the embedded control when the GUI is restored. e.g Just re-embedded

See bug reports #308,#627, 735

PsaltyDS · July 7, 2009

It crashes AutoIt on restore for me too, both Prod and Beta. That shouldn't happen regardless of the other GUI behaviors.

Bowmore · July 7, 2009

@colafrysen

Sorry I missed the bit about it crashing the exe when I read your original post.

I've tried your code on my laptop P4 WinXP SP3 and run it from Scite and as a compiled exe using AutoIt 3.3.0.0 and 3.3.1.1 and so far I have not been able to get it to crash, even by rapidly clicking the taskbar button to bounce the GUI between minimised and restored.

colafrysen · July 7, 2009

It crashes AutoIt on restore for me too, both Prod and Beta. That shouldn't happen regardless of the other GUI behaviors.

That's why i'm getting a bug reported for it.

Also, I noticed that in windows7 a different error occurs.

It seems that the progressbar places itself in the first part of the statusbar (note that I haven't tested this throughly)

@colafrysen
Sorry I missed the bit about it crashing the exe when I read your original post.
I've tried your code on my laptop P4 WinXP SP3 and run it from Scite and as a compiled exe using AutoIt 3.3.0.0 and 3.3.1.1 and so far I have not been able to get it to crash, even by rapidly clicking the taskbar button to bounce the GUI between minimised and restored.

Risking to look like an idiot, but what is P4?

Otherwise we are on the same systems (mayby exept that I have not taken the advantages of having genuine software from Microsoft (no windows update))

Do you think it could have something to do with the updates?

Well I'm reporting a bug anyways as I wasn't all alone.

Bowmore · July 8, 2009

Risking to look like an idiot, but what is P4?

P4 = Pentium 4 processor (relic of the steam age)

pdaughe · July 8, 2009

I tried it for you also -- running lastest beta and it immediately crashes on restore. Regarding the positioning of the progress bar after restore: I have an application which also uses an embedded progress bar in the status bar. I tried minimizing the window while the progress bar is showing and although it does NOT crash the application, the progress bar no longer displays. I am using option 3 (center vertically and horizontally), but that did not change the behavior of your test script. My application show/hides the progress bar; it seems problems only occur if the window is minimized while the progress bar is showing.

PsaltyDS · July 9, 2009

I tried it for you also -- running lastest beta and it immediately crashes on restore. Regarding the positioning of the progress bar after restore: I have an application which also uses an embedded progress bar in the status bar. I tried minimizing the window while the progress bar is showing and although it does NOT crash the application, the progress bar no longer displays. I am using option 3 (center vertically and horizontally), but that did not change the behavior of your test script. My application show/hides the progress bar; it seems problems only occur if the window is minimized while the progress bar is showing.

Previous Bug Tracs on this issue were closed as No Bug, meaning no AutoIt bug. Seems to be a bug in the Windows API. If that API got updated by Microsoft in Win7, maybe it will be different there.

colafrysen · July 9, 2009

Previous Bug Tracs on this issue were closed as No Bug, meaning no AutoIt bug. Seems to be a bug in the Windows API. If that API got updated by Microsoft in Win7, maybe it will be different there.

Yes i saw that when i first searched the issue tracker to avoid double posting the bug. So no bug was posted.

The answers to the issue where the progressbar reset its location has been aswered with the following:

Still not a bug with the embed function.

Work around if embedding controls in status bar and using WM_SIZE:

#include <GuiConstantsEx.au3>
#include <GuiStatusBar.au3>
#include <WindowsConstants.au3>
#include <ProgressConstants.au3>

Global $hStatus, $hProgress, $hProgress2, $hGUI, $progress, $progress2, $fSize = False

_Main()

Func _Main()

    Local $hInput, $input
    Local $aParts[4] = [80, 160, 300, -1]

    ; Create GUI
    $hGUI = GUICreate("StatusBar Embed Control", 400, 300)
    GUISetStyle(BitOR($WS_MINIMIZEBOX, $WS_MAXIMIZEBOX, $WS_SIZEBOX, $WS_CAPTION, $WS_POPUP, $WS_SYSMENU))

    $hStatus = _GUICtrlStatusBar_Create($hGUI)
    _GUICtrlStatusBar_SetMinHeight($hStatus, 20)
    _GUICtrlStatusBar_SetParts($hStatus, $aParts)
    _GUICtrlStatusBar_SetText($hStatus, "Part 1")
    _GUICtrlStatusBar_SetText($hStatus, "Part 2", 1)

    ; Embed a progress bar
    $progress = GUICtrlCreateProgress(10, 10, 100, 15, $PBS_SMOOTH)
    $hProgress = GUICtrlGetHandle($progress)
    _GUICtrlStatusBar_EmbedControl($hStatus, 2, $hProgress)

;~  ; *** Warning *** Resizing the window with the following enabled will hard crash AutoIt.
    $progress2 = GUICtrlCreateProgress(0, 0, 100, 15, $PBS_MARQUEE)
    $hProgress2 = GUICtrlGetHandle($progress2)
    _GUICtrlStatusBar_EmbedControl($hStatus, 3, $hProgress2)
    _SendMessage($hProgress2, $PBM_SETMARQUEE, True, 200)

    GUIRegisterMsg($WM_SIZE, "WM_SIZE")

    GUISetState()
    
    Do
        If $fSize Then
            _GUICtrlStatusBar_EmbedControl($hStatus, 2, $hProgress)
            _GUICtrlStatusBar_EmbedControl($hStatus, 3, $hProgress2)
            $fSize = False
        EndIf
            
    Until GUIGetMsg() = $GUI_EVENT_CLOSE
    GUIDelete()
EndFunc   ;==>_Main

; Resize the status bar when GUI size changes
Func WM_SIZE($hWnd, $iMsg, $iwParam, $ilParam)
    _GUICtrlStatusBar_Resize($hStatus)
    $fSize = True
    GUICtrlSetPos($progress2, -100, -100) ; hide the marquee off the window until the status bar part is big enough to hold it.
    Return $GUI_RUNDEFMSG
EndFunc   ;==>WM_SIZE

This does actually seem to fix the marquee as well, dont know why though

Anyways, I think that these issues should be mentioned in the documentation for _GUICtrlStatusBar_EmbedControl. How do i request that?

PsaltyDS · July 9, 2009

Yes i saw that when i first searched the issue tracker to avoid double posting the bug. So no bug was posted.
The answers to the issue where the progressbar reset its location has been aswered with the following:
This does actually seem to fix the marquee as well, dont know why though
Anyways, I think that these issues should be mentioned in the documentation for _GUICtrlStatusBar_EmbedControl. How do i request that?

You would post a New Bug Trac with a type of "Documentation", and provide your recommended verbiage change for the help file.

Can't hurt to try, but I don't know if the Devs want to start documenting everywhere external Windows bugs can make things go wrong.

colafrysen · July 9, 2009

You would post a New Bug Trac with a type of "Documentation", and provide your recommended verbiage change for the help file.
Can't hurt to try, but I don't know if the Devs want to start documenting everywhere external Windows bugs can make things go wrong.

I get your point, I like the helpfile small

But the error with the embedded controls not staying in the statusbar. Is that an windows bug, or a bad AutoIt implementation. I mean, do other languages have to deal with this WM_SIZE workaround as well?

PsaltyDS · July 9, 2009

I get your point, I like the helpfile small
But the error with the embedded controls not staying in the statusbar. Is that an windows bug, or a bad AutoIt implementation. I mean, do other languages have to deal with this WM_SIZE workaround as well?

You can trace it by opening GuiStatusBar.au3 and looking at the UDF code of _GuiCtrlSatatusBar_EmbedControl(). The work is done by calculating some dimensions and positions then calling _WinAPI_SetParent() and _WinAPI_MoveWindow().

Moving on to the _WinAPI_* functions, it's just DLL calls to the standard APIs. Those calls all succeed, and things don't go wrong until later when you minimize/restore the window.

If someone has the C-fu or some other language to try it in, they could create the same GUI with the same DLL calls and see how it behaves. But so far, it looks like the failure is entirely outside AutoIt.

The idea is, if you use the DLL correctly as intended, and a Windows bug causes a crash - that's not an AutoIt bug. Maybe it would be worth a warning in the help file that it might crash, but that goes down the road of trying to document everywhere else that might happen.

Could someone confirm this?

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members