Help File/Documentation Issues. (Discussion Only)

[pixelsearch]

1 hour ago, WildByDesign said:

According to help file, default is $CCS_TOP, $RBS_VARHEIGHT

You're right, the help file should be amended, here is what it stipulates :

Function Reference
_GUICtrlRebar_Create
Create a Rebar control

#include <GuiReBar.au3>
_GUICtrlRebar_Create ( $hWnd [, $iStyles = 0x513] )
...
Default styles: $CCS_TOP, $RBS_VARHEIGHT
Forced styles: $WS_CHILD, $WS_VISIBLE, $WS_CLIPCHILDREN, $WS_CLIPSIBLINGS

As you noticed, 0x513 doesn't correspond at all to BitOr($CCS_TOP, $RBS_VARHEIGHT), that's why the help file should be amended, because the default styles indicated in the help file doesn't equal 0x513

In fact, if we create a rebar control without indicating any style, it is created... at the bottom of the Gui with the following styles :

Local $hReBar = _GUICtrlRebar_Create($hGUI)

Control Viewer => 0x56000513 = CCS_BOTTOM, CCS_NOHILITE, RBS_TOOLTIPS, RBS_BANDBORDERS, WS_CHILD, WS_VISIBLE, WS_CLIPSIBLINGS, WS_CLIPCHILDREN

[0x40000000, 'WS_CHILD'], _
[0x10000000, 'WS_VISIBLE'], _
[0x04000000, 'WS_CLIPSIBLINGS'], _
[0x02000000, 'WS_CLIPCHILDREN'], _

[0x0400, 'RBS_BANDBORDERS'], _
[0x0100, 'RBS_TOOLTIPS']]
[0x0010, 'CCS_NOHILITE'], _
[0x0003, 'CCS_BOTTOM'], _

0x513 seems to correspond to BitOr($RBS_BANDBORDERS, $RBS_TOOLTIPS, $CCS_NOHILITE, $CCS_BOTTOM)

[WildByDesign]

18 minutes ago, pixelsearch said:

In fact, if we create a rebar control without indicating any style, it is created... at the bottom of the Gui with the following styles :

I noticed this as well. Many users would likely run it without the extra parameters with the assumption of getting default values.

I started to realize that maybe I am the only one to create a Rebar control in the last decade. 🤣

[jpm]

3 hours ago, WildByDesign said:

I'm not sure if this is the right place to report a bug with a function from the standard UDFs, but I've got a bug in _GUICtrlRebar_Create.

;Func _GUICtrlRebar_Create($hWnd, $iStyles = 0x513)
Func _GUICtrlRebar_Create($hWnd, $iStyles = BitOR($CCS_TOP, $RBS_VARHEIGHT))
    Local Const $ICC_BAR_CLASSES = 0x00000004 ; toolbar
    Local Const $ICC_COOL_CLASSES = 0x00000400 ; rebar

    Local $iStyle = BitOR($__GUICTRLCONSTANT_WS_CHILD, $__GUICTRLCONSTANT_WS_VISIBLE, $__REBARCONSTANT_WS_CLIPCHILDREN, $__REBARCONSTANT_WS_CLIPSIBLINGS)
    If $iStyles <> BitOR($__REBARCONSTANT_CCS_TOP, $RBS_VARHEIGHT) Then
        $iStyle = BitOR($iStyle, $iStyles)
    Else
        $iStyle = BitOR($iStyle, $__REBARCONSTANT_CCS_TOP, $RBS_VARHEIGHT)
    EndIf

    Local $tICCE = DllStructCreate('dword;dword')
    DllStructSetData($tICCE, 1, DllStructGetSize($tICCE))
    DllStructSetData($tICCE, 2, BitOR($ICC_BAR_CLASSES, $ICC_COOL_CLASSES))

    Local $aCall = DllCall('comctl32.dll', 'int', 'InitCommonControlsEx', 'struct*', $tICCE)
    If @error Then Return SetError(@error, @extended, 0)
    If $aCall[0] = 0 Then Return SetError(-2, 0, 0)

    Local $nCtrlID = __GuiCtrl_GetNextGlobalID($hWnd)
    If @error Then Return SetError(@error, @extended, 0)

    Local $hReBar = _WinAPI_CreateWindowEx(0, $__REBARCONSTANT_ClassName, "", $iStyle, 0, 0, 0, 0, $hWnd, $nCtrlID)
    If @error Then Return SetError(-1, -1, 0)

    Return $hReBar
EndFunc   ;==>_GUICtrlRebar_Create

According to help file, default is $CCS_TOP, $RBS_VARHEIGHT

Notice how the original Func line (commented out) has 0x513 as default. Well, I'm guessing that does not equal the BitOR for those two values. I added the Func line below that with the BitOR and that seems to go through the function properly and work as intended.

true never change since 2007 introduction

[argumentum]

4 hours ago, WildByDesign said:

I'm not sure if this is the right place to report a bug with a function from the standard UDFs,

Yes and no. autoit-technical-discussion is the right place.
This thread is for the help file.
To add an issue with a standard function, you'd open a new thread here in autoit-technical-discussion named something like: "_GUICtrlRebar_Create() don't work like it used to 😢" ( Or something like that 😅 )
..because as you can see, as we start going down the rabbit's hole, we take over the thread  

[jpm]

I fix it for next beta/release

[argumentum]

ObjEvent ( "AutoIt.Error" [, "function"] )
...If the second parameter is omitted, it will return a string containing the name of the current Error handler function. If no Error handler function has been set, it will return an empty string.

If ObjEvent("AutoIt.Error") = "" And FuncName(ObjEvent("AutoIt.Error")) = "" Then $oMyError = ObjEvent("AutoIt.Error", MyProjectErrFunc)

Should we add that if the function name is not a string we should check for the FuncName ?
Since the help was written before the need to encapsulate the function as a string, ... .
Maybe: it will return a string containing the name of the current Error handler function. and remove the "string" detail ?

P.S.: ..the detail came up scripting zip-your-project-nicely and I had to think of why wasn't it returning a string.

 

Edited May 26 by argumentum

[pixelsearch]

@jpm AutoIt actual release 3.3.18.0 : wrong error codes in help file for both functions _GDIPlus_ImageResize() and _GDIPlus_ImageScale()

This is what we read actually, but it corresponds to older code of AutoIt (checked) :

_GDIPlus_ImageResize() - @error:
1 - unable to create new bitmap
2 - unable to create graphics context
3 - unable to set interpolation mode on graphics context
4 - unable to copy image to scaled bitmap


_GDIPlus_ImageScale - @error:
1 - unable to get width of image
2 - unable to get height of image
3 - unable to create new bitmap
4 - unable to create graphics context
5 - unable to set interpolation mode on graphics context
6 - unable to copy image to scaled bitmap

In version 3.3.18.0, both functions should indicate these 4 error codes :

1 - unable to get width of image
2 - unable to get height of image
3 - unable to create new bitmap
4 - error from __GDIPlus_ImageAttributesSetImageWrapMode()

Maybe @UEZ would like to rephrase error #4 to make it more understandable, thanks.

Also let's not forget the important missing line in code (to avoid memory leak) in _GDIPlus_ImageResize(), confirmed by UEZ in this link.

[UEZ]

Error return value from __GDIPlus_ImageAttributesSetImageWrapMode() according to MS can be:

Global Enum $Ok = 0, $GenericError, $InvalidParameter, $OutOfMemory, $ObjectBusy, $InsufficientBuffer, _
    $NotImplemented, $Win32Error, $WrongState, $Aborted, $FileNotFound, $ValueOverflow, $AccessDenied, _
    $UnknownImageFormat, $FontFamilyNotFound, $FontStyleNotFound, $NotTrueTypeFont, _
    $UnsupportedGdiplusVersion, $GdiplusNotInitialized, $PropertyNotFound, $PropertyNotSupported, $ProfileNotFound

 

[pixelsearch]

Hello everybody
Help file topic GUICtrlCreatePic, this is what we read :

Style [optional] Defines the style of the control.
default (-1) : $SS_NOTIFY
forced style : $SS_BITMAP | $SS_CENTERIMAGE

If not mistaken, $SS_CENTERIMAGE shouldn't be mentioned. This is what AutoIt window info tool, WinSpy, or Yashied's tool indicate, when you run "example 1" found at topic GUICtrlCreatePic :

Style : 0x5002010E
SS_BITMAP, SS_NOTIFY, WS_CHILD, WS_VISIBLE, WS_GROUP

[0x40000000, 'WS_CHILD']
[0x10000000, 'WS_VISIBLE']
[0x00020000, 'WS_MINIMIZEBOX | WS_GROUP'] ; GUI | Control
[0x00000100, 'SS_NOTIFY']
[0x0000000E, 'SS_BITMAP']

$SS_CENTERIMAGE is 0x0200 and doesn't seem to be present in the pack.
Thanks for reading and have a great day.

[jpm]

Thanks,

Already fixed in January 2026 ready for next Beta/relase