Context Navigation

Timeline

12:48 PM Ticket #3632 (The second parameter for _Net_Share_ShareCheck is incorrectly ...) closed by J-Paul Mesnage: Fixed: Fixed by revision [12152] in version: 3.3.15.1

4:41 PM FindTextTest.au3 attached to Ticket #3633 by davidjudysmith@…: Test script, showing that _FindText doesn't report failure
4:38 PM Ticket #3633 (_GUICtrlRichEdit_FindText does not flag failure to find CR) created by davidjudysmith@…: There seems to be a problem with _GUICtrlRichEdit_FindText, or at …

2:01 AM Ticket #3631 (StringRegExp - metacharacter "\R" in square brackets behaves incorrectly) updated by jchd18: I know what the help says because yours truly authored this topic. Saying "only this and that work" is equivalent (and shorter in our case) to saying that anything not listed doesn't.

5:14 PM Ticket #3631 (StringRegExp - metacharacter "\R" in square brackets behaves incorrectly) updated by Alofa <alofa.script@…>: Replying to jchd18: > As the helpfile says \R is not special in a character class. ---- I need to fix you, but in the help file (in the description of […]) the following is said: >"Note that in a character class, only \d, \D, \h, \H, \p{}, \P{}, \s, \Q...\E, \S, \v, \V, \w, \W, and \x sequences retain their special meaning, while \b means the backspace character (Chr(8))". ---- And unfortunately I didn't realize it right away. I apologize.
9:17 AM Ticket #3631 (StringRegExp - metacharacter "\R" in square brackets behaves incorrectly) closed by jchd18: No Bug: As the helpfile says \R is not special in a character class. Therefore [\R] is the same as [R] and hence the same as R @error set to 1 means no match occured. It's clear when you look closely to the meaning of your pattern. Please refrain to post a bug report before asking in the Help forum first.
5:06 AM Ticket #3632 (The second parameter for _Net_Share_ShareCheck is incorrectly ...) created by Bob Anthony: Per the documentation, the second parameter for _Net_Share_ShareCheck …

10:15 PM Ticket #3631 (StringRegExp - metacharacter "\R" in square brackets behaves incorrectly) created by Alofa <alofa.script@…>: Metacharacter "\R" in square brackets behaves incorrectly […]

6:00 PM Ticket #3630 (Superscripting attribute in the Rich Edit control doesn't work) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
5:09 PM Ticket #3630 (Superscripting attribute in the Rich Edit control doesn't work) updated by Melba23: Type changed
5:08 PM Ticket #3630 (Superscripting attribute in the Rich Edit control doesn't work) updated by Melba23: I do not see this as a bug, so I have changed it to a "Feature request". Why? Because the Help file quite correctly says that certain attributes do not display in an AutoIt RichEdit control - and indeed they do not. The fact you assumed them to be present but not active is an error on your part as such behaviour is not specified. Personally I would expect the streamed data to match what was shown in the RichEdit - which it does. M23
8:56 AM Ticket #3629 (Line Number in Arraydisplay) updated by Melba23: There are already line numbers displayed within the main display (unless you set the $ARRAYDISPLAY_NOROW flag) - are you asking for the line number to be displayed elsewhere in the dialog in addition? And if so, why do you require this? M23

9:22 PM SuperBug.au3 attached to Ticket #3630 by davidjudysmith@…: Demonstrates that superscripting in the Rich Edit control doesn't work
9:21 PM Ticket #3630 (Superscripting attribute in the Rich Edit control doesn't work) created by davidjudysmith@…: The documentation for _GUICtrlRichEdit_SetCharAttributes lists many …
12:00 PM Ticket #3629 (Line Number in Arraydisplay) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
11:47 AM Ticket #3629 (Line Number in Arraydisplay) created by wimhek11@…: Please add a Line number by default in the Head of the display …

8:43 AM Ticket #3627 (Feature Request: AutoItWinGetHandle()) updated by Melba23: Did you try to see if this was the case? When I run several concurrent instances of the same script I get a different handle returned for each instance, so it appears that the code will only return the handle associated with that instance, which is what I would expect. M23

4:34 PM Ticket #3628 (_WinAPI_GetCaretPos() does not work) closed by J-Paul Mesnage: Fixed: Fixed by revision [12145] in version: 3.3.15.1

3:51 PM Ticket #3628 (_WinAPI_GetCaretPos() does not work) updated by Jos: Looks like there is an error in the _WinAPI_GetCaretPos() UDF where the pointer used in the DllCall not the struct created ($tPOINT) but the string with the struct definition ($tagPOINT). COuld you try this update: […] Jos
2:02 PM Ticket #3628 (_WinAPI_GetCaretPos() does not work) created by anonymous: _WinAPI_GetCaretPos() is supposed to return an array. It only returns …
1:43 PM Ticket #3627 (Feature Request: AutoItWinGetHandle()) updated by therks: If you have more than one AutoIt process running you could end up with the handle for another process. Also because the default title is just "AutoIt v3" it's possible another (non-AutoIt) window with that title could be open as well.

7:50 AM Ticket #3222 (FileInstall) updated by mLipok: Owner, Status changed

6:07 AM Ticket #3219 (dllCall cause error with SetupDiEnumDeviceInfo) closed by J-Paul Mesnage: No Bug

7:00 PM Ticket #3627 (Feature Request: AutoItWinGetHandle()) updated by Melba23: Why so complicated? Why not simply: […] M23
4:05 PM Ticket #3627 (Feature Request: AutoItWinGetHandle()) created by anonymous: As simple as it sounds, can we get a function that just gives the …

Note: See TracTimeline for information about the timeline view.