Custom Query


Show under each result:

Results (25 - 27 of 3870)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Ticket Resolution Summary Owner Reporter
#2945 Fixed Center and right justified text broken on native buttons when colours set Jon AlanParry


After upgrading my scripts from to 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 and 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 In 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


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

Regards Alan Parry

#3697 Fixed _WinAPI_GetOverlappedResult fails to set the [out] parameter $iBytes in some cases Jpm AlanParry

_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:[]).

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

The code back was correct In at least the following versions it isn't:,,,,,

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 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

#3755 Fixed _ArrayInsert fails with Error 3 when the Insert Positions parameter is a delimited string Melba23 AlanParry

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"

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Note: See TracQuery for help on using queries.