Custom Query (3921 matches)

The SplashTextOn dialog treats an ampersand in the 'text' parameter as a hotkey mnemonic prefix indicator unless the ampersand is doubled, even though the static text control in the dialog isn't a clickable-action control.

The $SS_NOPREFIX style flag should be applied to the static control inside the SplashTextOn window to prevent this.

Test script:

SplashTextOn("Sample", "This&That", 200, 100)

Hi,

I'm using _FileListToArray function and I'm getting error code 4 when I don't have enough right access to the folder I want to list.

I modified this function to my need by adding "If _WinAPI_GetLastError() = 5 Then SetError(5, 0, 0)" in the code.

It's not essential but could the dev consider adding this error return ?

Thanks for your work.

There seems to be a problem with _GUICtrlRichEdit_FindText, or at least a problem with its documentation.

The attached script FindTextTest.au3 illustrates the problem. The script creates a Rich Edit control and fills it with three lines, one of which is blank; each line is followed by a CR. The For loop sets the character position, initially at the beginning of the text, then searches for the next CR character. Results of these searches are reported in a MsgBox when the loop completes.

According to the documentation, _GUICtrlRichEdit_FindText should return "the inter-character position before start of matching text if found, else -1." But my test program never gets a -1 from that function, even when it is obviously searching beyond the end of the text.

The third pass through the For loop correctly returns the position of the last CR. The fourth pass should return a -1 status or a code in @error, because there are no more CR characters, but it does not. In the last two passes, the FindText function returns a value that is one less than the starting position, apparently because the starting position is beyond the end of the text, but that behavior is not documented. (Note that GotoCharPos does not fail.) The error only comes from GetTextInRange, because End<Start.

I suggest one or more of the following:

• Return a failure from GotoCharPos if the position is beyond the end of the text;
• Correctly handle searches for CR characters, which seem to be different from printable characters;
• Provide a different way to search for CR characters (actual end of a line/paragraph, not just end of displayed line);
• Document that FindText returns the position of the end of the text, if it is started beyond that point, or generate an error in that case.

Note also that _GUICtrlRichEdit_GetTextLength returns a number that's larger (25 vs 22) than the actual number of characters. That makes it useless for a comparison with character positions.