Custom Query

Hi,

After upgrading my scripts from 3.3.8.1 to 3.3.12.0/3.3.13.19 it appears that center and right justification of native buttons aren't working properly now when either

i) GUICtrlSetDefColor or GUICtrlSetDefBkColor called before a button wiht aligned text is created

ii) GUICtrlSetColor or GUICtrlSetBkColor is called after the text alignment has been set.

An alternate problem is: if the alignment is set using GUICtrlSetStyle after the colour has been set then the colours settings are lost (but the alignment is then correct). (Note also:- Strangely after loosing set default colours with a style change, setting just the background colour restores the foreground colour as well, as can be seen in the last set of examples).

The problems occur on 3.3.12.0 and 3.3.13.19. Slightly different but similar issues occurred in 3 3.8.1. My suspicion is that it that it might be related to the bug fix for #2299 at milestone 3.3.9.21. In 3.3.8.1 Left and Right alignment were wrong but center was correct.

The permutations of: default color settings; alignment at creation; style changes; and color changes effect the issue in different ways. So I have attached a script that shows the permutations and labels those which are wrong.

Without wishing to state the obvious I wonder if the values used by MS for alignments are causing any confusion as

BS_CENTER = BitOR(BS_LEFT, BS_RIGHT)

so simple bit tests don't always do what expected.

Regards Alan Parry

_WinAPI_GetOverlappedResult does not set the $iBytes [out] parameter in the case where GetOverlappedResult() returns False.

However the $iBytes has a meaningful value in the case when it returns False and GetLastError()==ERROR_MORE_DATA which can occur when using Named Pipes in message mode (see here if you wish to read about named pipes:[ ​https://docs.microsoft.com/en-us/windows/desktop/ipc/named-pipe-client]).

Note though that it should return the value for all cases regardless of the reason for the error.

The code back 3.3.8.1 was correct In at least the following versions it isn't: 3.3.9.22, 3.3.12.0, 3.3.13.19, 3.3.14.5, 3.3.15.0, 3.3.15.1

The incorrect code is

Func _WinAPI_GetOverlappedResult($hFile, $tOverlapped, ByRef $iBytes, $bWait = False)
	Local $aResult = DllCall("kernel32.dll", "bool", "GetOverlappedResult", "handle", $hFile, "struct*", $tOverlapped, "dword*", 0, _
			"bool", $bWait)
	If @error Or Not $aResult[0] Then Return SetError(@error, @extended, False)

	$iBytes = $aResult[3]
	Return $aResult[0]
EndFunc   ;==>_WinAPI_GetOverlappedResult

The old 3.3.8.1 CORRECT code (though missing the struct* change) was

Func _WinAPI_GetOverlappedResult($hFile, $pOverlapped, ByRef $iBytes, $fWait = False)
	Local $aResult = DllCall("kernel32.dll", "bool", "GetOverlappedResult", "handle", $hFile, "ptr", $pOverlapped, "dword*", 0, "bool", $fWait)
	If @error Then Return SetError(@error, @extended, False)
	$iBytes = $aResult[3]
	Return $aResult[0]
EndFunc   ;==>_WinAPI_GetOverlappedResult

Regards Alan Parry

For example, if the Insert Positions parameter $vValue is "7;10" _ArrayInsert fails with Error code 3.

The reason is that when _ArrayInsert compares the insertion points to check that they are in ascending order, what it compares are the string representation of the numbers and guess what: "7" is NOT less than "10"