pixelsearch

@TheAutomator glad I could help Just a reminder : in case one day you'll have to check $Bar and $Tumb in your main loop (please add them to your script, for a quick test) While 1 Switch GUIGetMsg() ... Case $Bar ConsoleWrite("Bar" & @crlf) Case $Tumb ConsoleWrite("Tumb" & @crlf) EndSwitch WEnd Then this is what would happen, when you click the Bar control or the Tumb control : 1) Order of creation of the 2 overlapping controls, as found in your script above : $Bar = GUICtrlCreateLabel('', 70, 70, 40, 270, $SS_BLACKRECT) $Tumb = GUICtrlCreateLabel('', 70, 70, 40, 80, $SS_GRAYRECT) Bad ConsoleWrite : "Bar" is always displayed in the Console, even when clicking on Tumb ! 2) Let's reverse the order of creation : $Tumb = GUICtrlCreateLabel('', 70, 70, 40, 80, $SS_GRAYRECT) $Bar = GUICtrlCreateLabel('', 70, 70, 40, 270, $SS_BLACKRECT) Now it's worse : the Tumb doesn't even show in the GUI ! 3) Correct way of creation + use of $WS_CLIPSIBLINGS $Tumb = GUICtrlCreateLabel('', 70, 70, 40, 80, $SS_GRAYRECT) $Bar = GUICtrlCreateLabel('', 70, 70, 40, 270, BitOr($SS_BLACKRECT, $WS_CLIPSIBLINGS)) Tumb appears normally in the GUI, ConsoleWrite shows correctly "Bar" or "Thumb" depending on the clicked control. I did several tests like these, using overlapping label + label, then label + pic, then label + button. I also checked at the same time GUIGetCursorInfo() to make sure the last element of the returned array corresponds to the correct control hovered over. Gladly it seemed to work in all cases As you scripted it differently (without the need to check $Tumb and $Bar in the main loop) then you're not concerned with all this, just remember this post if one day you need it, who knows. For what it's worth...

You caught me while I was in the PM section Gonna have a look at it and let you know later, see ya. @TheAutomator i tried your code, it works fine when you scroll by dragging the thumb. Now the thumb moves up or down while you drag it, which was a missing feature as noted by WildByDesign. Well done.

<deleted>

Nice catch. I just tried it (instead of _GUICtrlRichEdit_SetScrollPos) and it forces line 1 to display at the top in all cases Edit: now my test script becomes a bit longer but well... I have to remember all this : ; _GUICtrlRichEdit_SetScrollPos($hRichEdit, 0, 0) ; bad behavior when placed before GUISetState (in case total lines = total visible + 1) ; better is : _GUICtrlRichEdit_SetSel($hRichEdit, 0, 0) ; Kafu's solution 100% ( https://www.autoitscript.com/forum/topic/212823-richedit-issue/ ) GUISetState(@SW_SHOW) ; _GUICtrlRichEdit_SetScrollPos($hRichEdit, 0, 0) ; good behavior when placed after GUISetState (in case total lines = total visible + 1)

What a great forum with people answering so quickly, thank you guys I found this annoyance yesterday while testing thoroughly my script here, then confirmed with Nine's script found there (example 3) . As both of our scripts don't use (on purpose) a $WS_VSCROLL style while creating the richedit control, then I started the actual thread with a richedit control that uses a $WS_VSCROLL style (as it should be) and here we are... If not mistaken, this annoyance happens only when the number of total lines = number total visible lines + 1 . We can confirm it like this, using the script above : 1) Let's keep these 2 lines of code untouched, ordered like this : _GUICtrlRichEdit_SetScrollPos($hRichEdit, 0, 0) ; bad behavior when placed before GUISetState (in case total lines = total visible + 1) GUISetState(@SW_SHOW) 2) Now we increase the value in this line... If _GUICtrlRichEdit_GetNumberOfFirstVisibleLine($hRichEdit) > 1 Then ExitLoop ... by changing its "> 1" to bigger values (like > 2 , > 3 etc...) How is the display ? Well it's always correct starting from > 2 ("correct" means line 1 is visible at top) , the only value that brings a bad display is "> 1" (bad display means line 2 is visible at top) So in the end, where should be placed the following line, before or after GUISetState() ? _GUICtrlRichEdit_SetScrollPos($hRichEdit, 0, 0) My advice is it should always be placed after, because even with 10.000 lines in the richedit control, the display is immediate (not in "2 times", tested) and who knows (it may happen one day) in case the richedit control got exactly a total number of lines = total visible lines + 1 , then its display will always be correct (e.g. line 1 appearing at the top)

Hello everybody Could you please run the following script, then report if the line immediately visible at the top is line 2 or line 1 ? #include <GUIConstantsEx.au3> #include <GuiRichEdit.au3> #include <WindowsConstants.au3> Opt("MustDeclareVars", 1) ;0=no, 1=require pre-declaration Example() Func Example() Local $hGui, $hRichEdit, $idButton, $iCounter = 0 $hGui = GUICreate("1st line hidden when...", 300, 286) $hRichEdit = _GUICtrlRichEdit_Create($hGui, "", 10, 10, 200, 266, _ BitOR($ES_MULTILINE, $WS_VSCROLL, $ES_AUTOVSCROLL)) $idButton = GUICtrlCreateButton("Button", 225, 10, 60, 30) While True $iCounter +=1 _GUICtrlRichEdit_AppendText($hRichEdit, ($iCounter > 1 ? @crlf : "") & "Line " & $iCounter) If _GUICtrlRichEdit_GetNumberOfFirstVisibleLine($hRichEdit) > 1 Then ExitLoop ; richedit became scrollable WEnd _GUICtrlRichEdit_SetScrollPos($hRichEdit, 0, 0) ; bad behavior when placed before GUISetState (in case total lines = total visible + 1) GUISetState(@SW_SHOW) While True Switch GUIGetMsg() Case $GUI_EVENT_CLOSE _GUICtrlRichEdit_Destroy($hRichEdit) GUIDelete() Exit Case $idButton ConsoleWrite("1st visible line (1-based) is : " & _GUICtrlRichEdit_GetNumberOfFirstVisibleLine($hRichEdit) & @crlf) EndSwitch WEnd EndFunc ;==>Example On my computer, the line visible at the top is line 2 (left part of the pic) with this code... _GUICtrlRichEdit_SetScrollPos($hRichEdit, 0, 0) ; bad behavior when placed before GUISetState (in case total lines = total visible + 1) GUISetState(@SW_SHOW) ...but it becomes line 1 (right part of the pic) with that code : GUISetState(@SW_SHOW) _GUICtrlRichEdit_SetScrollPos($hRichEdit, 0, 0) ; good behavior when placed after GUISetState (in case total lines = total visible + 1) Is it the same for you ? Thanks

You're welcome, it was interesting to script. As I just did a new update today (7th april), may I suggest you delete the old quoted code from your last post, so we keep only the updated version ? Thanks and have a great day

@TheAutomator there are always good things to learn from @Nine's code, but it takes time to (try to) understand it, because our knowledge of AutoIt/Windows isn't as high as his. I always said he's a great coder ! Nine uses Subclassing a lot, which seems to be the shortest way to accomplish many tasks, which would require much code when not used. For example, with the code below I can mimic a scrollbar (using 4 label controls) without subclassing, by registering WM_COMMAND & WM_NOTIFY, but it requires more code than subclassing : #include <GUIConstantsEx.au3> #include <GuiRichEdit.au3> #include <Misc.au3> #include <StaticConstants.au3> #include <WindowsConstants.au3> Opt("MustDeclareVars", 1) ;0=no, 1=require pre-declaration Global $g_hRichEdit, $g_idDummy, $g_idThumb, $g_idUp, $g_idDn, $g_idBack, $g_aBack Global $g_aCheckLine[3] ; [0] = 1st visible line, [1] = last visible line, [2] = total lines Example() Func Example() ; Constants changeable in these 4 lines Local $hGui = GUICreate("Label is Scrollbar", 320, 416) Local $aEdit[4] = [10, 10, 210, 396] ; coords richedit control Local $iGap = 3 ; number of pixels between right border of edit control & vertical scrollbar Local $aUp[4] = [$aEdit[0] + $aEdit[2] + $iGap, $aEdit[1], 15, 20] ; coords Up arrow ; Nothing to change here Dim $g_aBack[4] = [$aUp[0], $aUp[1] + $aUp[3], $aUp[2], $aEdit[3] - $aUp[3] * 2] Local $aDn[4] = [$aUp[0], $aEdit[1] + $aEdit[3] - $aUp[3], $aUp[2], $aUp[3]] Local $sString For $i = 1 To 100 $sString &= @crlf & "Line " & $i Next $sString = StringTrimLeft($sString, 2) ; remove 2 first characters (@cr & @lf) $g_hRichEdit = _GUICtrlRichEdit_Create($hGui, $sString, $aEdit[0], $aEdit[1], $aEdit[2], $aEdit[3], _ BitOR($ES_MULTILINE, $ES_AUTOVSCROLL)) $g_idUp = GUICtrlCreateLabel(Chr(241), $aUp[0], $aUp[1], $aUp[2], $aUp[3], BitOr($SS_CENTERIMAGE, $SS_CENTER)) GUICtrlSetFont(-1, 15, $FW_MEDIUM, $GUI_FONTNORMAL, "Wingdings") GUICtrlSetBkColor(-1, 0xE0DFE3) ; my GUI light grey background $g_idDn = GUICtrlCreateLabel(Chr(242), $aDn[0], $aDn[1], $aDn[2], $aDn[3], BitOr($SS_CENTERIMAGE, $SS_CENTER)) GUICtrlSetFont(-1, 15, $FW_MEDIUM, $GUI_FONTNORMAL, "Wingdings") GUICtrlSetBkColor(-1, 0xE0DFE3) ; my GUI light grey background ;======= create $g_idThumb BEFORE $g_idBack (as they overlap) . $WS_CLIPSIBLINGS style for $g_idBack $g_idThumb = GUICtrlCreateLabel("", $g_aBack[0], $g_aBack[1], 0, 0) GUICtrlSetBkColor(-1, 0xFF0000) ; red $g_idBack = GUICtrlCreateLabel("", $g_aBack[0], $g_aBack[1], $g_aBack[2], $g_aBack[3], $WS_CLIPSIBLINGS) GUICtrlSetBkColor(-1, 0x808080) ; dark grey ;======= $g_idDummy = GUICtrlCreateDummy() Local $idButton = GUICtrlCreateButton("Button", $aUp[0] + $aUp[2] + 10, $aUp[1], 60, 30) _GUICtrlRichEdit_SetEventMask($g_hRichEdit, $ENM_SCROLLEVENTS) GUIRegisterMsg($WM_NOTIFY, "WM_NOTIFY") GUIRegisterMsg($WM_COMMAND, "WM_COMMAND") GUISetState(@SW_SHOW) _GUICtrlRichEdit_SetScrollPos($g_hRichEdit, 0, 0) ; good behavior when placed after GUISetState (in case total lines = total visible + 1) While True Switch GUIGetMsg() Case $GUI_EVENT_CLOSE _GUICtrlRichEdit_Destroy($g_hRichEdit) GUIDelete($hGUI) Exit Case $g_idDummy ; triggered by WM_COMMAND . Needed to process ALL repeated clicks on labels Local $iDummyVal = GUICtrlRead($g_idDummy) Switch $iDummyVal Case $g_idUp, $g_idDn ; line up / line down _GUICtrlRichEdit_ScrollLines($g_hRichEdit, ($iDummyVal = $g_idUp) ? -1 : 1) Sleep(200) While _IsPressed("01") _GUICtrlRichEdit_ScrollLines($g_hRichEdit, ($iDummyVal = $g_idUp) ? -1 : 1) Sleep(100) WEnd Case $g_idBack ; page up / page down If BitAnd(GUICtrlGetState($g_idThumb), $GUI_SHOW) Then Local $aPosThumb, $iY, $iOpt = Opt("MouseCoordMode", 2) ; 2 = relative to client area While True $aPosThumb = ControlGetPos($hGUI, "", $g_idThumb) $iY = MouseGetPos(1) If $iY < $aPosThumb[1] Then _GUICtrlRichEdit_ScrollLineOrPage($g_hRichEdit, "pu") ElseIf $iY > $aPosThumb[1] + $aPosThumb[3] Then _GUICtrlRichEdit_ScrollLineOrPage($g_hRichEdit, "pd") EndIf Sleep(200) If Not _IsPressed("01") Then ExitLoop WEnd Opt("MouseCoordMode", $iOpt) EndIf EndSwitch Case $g_idThumb ; based on Nine's formula Local $iOpt = Opt("MouseCoordMode", 2) Local $aThumb = ControlGetPos($hGUI, "", $g_idThumb) Local $iTop = $g_aBack[1], $iTop2, $iBottom = $g_aBack[3] - $aThumb[3] Local $iY = MouseGetPos(1), $iY1 = $iY, $iY2, $iDeltaInit = $aThumb[1] - $iY While _IsPressed("01") $iY2 = MouseGetPos(1) If $iY2 <> $iY1 Then $iY2 += $iDeltaInit $iY2 = $iY2 < $iTop ? $iTop : ($iY2 > $iBottom ? $iBottom : $iY2) $iTop2 = _ScrollCalc(($iY2 - $iTop) / ($iBottom - $iTop)) _GUICtrlRichEdit_ScrollLines($g_hRichEdit, $iTop2 - $g_aCheckLine[0]) $iY1 = $iY2 EndIf Sleep(10) WEnd Opt("MouseCoordMode", $iOpt) Case $idButton _ScrollCalc() ; just to display the result of 1st visible line, last visible line, total lines ConsoleWrite("Button pressed " & $g_aCheckLine[0] & " " & $g_aCheckLine[1] & " " & $g_aCheckLine[2] & @crlf) EndSwitch WEnd EndFunc ;==>Example ;=========================================== Func WM_NOTIFY($hWnd, $iMsg, $wParam, $lParam) Local $tMsgFilter = DllStructCreate($tagMSGFILTER, $lParam) If $tMsgFilter.hwndFrom = $g_hRichEdit Then _GUICtrlRichEdit_ScrollLines($g_hRichEdit, $tMsgFilter.wParam ? 1 : -1) Return $GUI_RUNDEFMSG EndFunc ;==>WM_NOTIFY ;=========================================== Func WM_COMMAND($hWnd, $iMsg, $wParam, $lParam) If $lParam = $g_hRichEdit Then If BitShift($wParam, 16) = $EN_UPDATE Then ; Hi Word (control notification code) _ScrollUpdate() EndIf Else Local $iIDFrom = BitAND($wParam, 0xFFFF) ; Low Word (control ID) Switch $iIDFrom Case $g_idUp, $g_idDn, $g_idBack GUICtrlSendToDummy($g_idDummy, $iIDFrom) EndSwitch EndIf Return $GUI_RUNDEFMSG EndFunc ;==>WM_COMMAND ;=========================================== Func _ScrollUpdate() _ScrollCalc() If $g_aCheckLine[0] = 1 And $g_aCheckLine[1] = $g_aCheckLine[2] Then GUICtrlSetState($g_idThumb, $GUI_HIDE) Return EndIf Local $fRatio = ($g_aCheckLine[1] - $g_aCheckLine[0] + 1) / $g_aCheckLine[2] Local $iThumbHeight = Int($g_aBack[3] * $fRatio), $iY Select Case $g_aCheckLine[0] = 1 $iY = $g_aBack[1] Case $g_aCheckLine[1] = $g_aCheckLine[2] $iY = $g_aBack[1] + $g_aBack[3] - $iThumbHeight Case Else Local $iTotalHiddenLines = $g_aCheckLine[2] - ($g_aCheckLine[1] - $g_aCheckLine[0] + 1) Local $fRatio2 = ($g_aCheckLine[0] - 1) / $iTotalHiddenLines Local $iYPosThumb = Int(($g_aBack[3] - $iThumbHeight) * $fRatio2) $iY = $g_aBack[1] + $iYPosThumb EndSelect GUICtrlSetPos($g_idThumb, $g_aBack[0], $iY, $g_aBack[2], $iThumbHeight) GUICtrlSetState($g_idThumb, $GUI_SHOW) EndFunc ;==>_ScrollUpdate ;=========================================== Func _ScrollCalc($nPos = 0) Local Static $aRect = _GUICtrlRichEdit_GetRECT($g_hRichEdit) Local $iCharIndex = _GUICtrlRichEdit_GetCharPosFromXY($g_hRichEdit, $aRect[0] + 2, $aRect[3] - 2) $g_aCheckLine[0] = _GUICtrlRichEdit_GetNumberOfFirstVisibleLine($g_hRichEdit) $g_aCheckLine[1] = _GUICtrlRichEdit_GetLineNumberFromCharPos($g_hRichEdit, $iCharIndex) ; last visible line $g_aCheckLine[2] = _GUICtrlRichEdit_GetLineCount($g_hRichEdit) If $nPos Then Local $iShown = $g_aCheckLine[1] - $g_aCheckLine[0] + 1 Local $iTop2 = Int($nPos * ($g_aCheckLine[2] - $iShown)) + 1 Return $iTop2 EndIf EndFunc ;==>_ScrollCalc In this script, the scroll "thumb" (a label control) has a dynamic height, it's not static as in your script (or Nine's) and its height varies with the number of total lines in the richedit control . Also I can click on the "scroll background rectangle" (another label control which overlaps with the thumb control) to scroll 1 page up/down, or on the 2 scrolls arrows (2 other label controls) to scroll 1 line up/down, as in a normal scrollbar. I'm not satisfied with the fact that clicking quickly on the scroll arrows doesn't scroll 1 line up/down each time the user clicks on a scroll arrow. I just discovered why today : clicking quickly twice on a label control doesn't trigger (twice) the corresponding Case in main loop, because it's recognized as a double click on the label control, which should be taken care of in WM_COMMAND as @Melba23 indicates here . This "annoyance" doesn't occur with button controls. [ Note : the preceding "Strikethrough" comment has been fixed in the code by using a Dummy control, triggered by WM_COMMAND and processed in main loop. ] Using Pic controls (as you do) instead of Label controls seem to work , as both are static controls. What is important is the order of creation of the 2 overlapping controls, as found in the script, e.g. the big "scroll bar rectangle" (dark grey in the pic) and the smaller "scroll thumb" (red in the pic) I scripted this only for educational purpose, because simply adding the "WS_SCROLL" style to the richedit control would solve it all, but I understand why you don't want to use WS_SCROLL (you explained it before) Maybe the script above will help you, maybe not, or maybe it will be a good occasion for you to spend some time on Nine's subclassing part & the learning of DllCallbackRegister etc... For example, see in this post how @LarsJ quickly used subclassing to efficiently solve OP's question, amazing ! Good luck Update: April 8th : simplified code in Case $g_idBack

Maybe it's because you got a Windows option to uncheck for your search : "Include compressed files (zip,cab...)" * AutoIt doesn't use it, so it will return a smaller number of files (the "real" number of files) * Windows uses it when checked, so the number of files returned will be bigger as soon as you got zip file(s) inside your folder, because the number of files inside the zip(s) will be included in your result. Edit: I see you got another solution. Anyway I'll keep my post unchanged, just in case... https://www.isunshare.com/windows-10/change-search-options-for-files-and-folders-on-windows-10.html

Yes I wasn't sure it will work for you. Let me explain why it worked for me : I got 2 opened windows whose names start with "C:\" , these windows are : 1) Scite : window name : C:\Documents and Settings\Administrateur\blablabla - SciTE - blablabla 2) Explorer : window name when opened at C root : C:\ So when I run your script (with of course $sSrcPath = "C:\") it's like I'm running it using this default line : Opt("WinTitleMatchMode", 1) ;1=start (default), 2=subStr, 3=exact, 4=advanced, -1 to -4=Nocase As the default is 1 (start) then... my Scite window closes instead of my Explorer window, because the 1st window retrieved was unfortunately the Scite window, whose name starts with C:\ But when I run your script with this line : Opt("WinTitleMatchMode", -3) ;1=start (default), 2=subStr, 3=exact, 4=advanced, -1 to -4=Nocase Then the correct Explorer window is closed because I asked for an exact match (3 or -3) So even if the solution I indicated in my preceding post didn't make it in your case, it's good to know what to do in case one day you face the same situation that just happened to me. Edit: glad to see you made it using CLASS

Hello, could you try to add this line to your script ? Opt("WinTitleMatchMode", -3) ;1=start (default), 2=subStr, 3=exact, 4=advanced, -1 to -4=Nocase

@Nine great line found in your UDF : ($mScroll[$iID])[0]($iID, ($iY2 - $iTop)/($iBottom - $iTop), $iData) with ($mScroll[$iID])[0] corresponding to the UserFunction ScrollEdit found... in the calling script RoundGUI Example3.au3 Nice interaction between the UDF and its example

Yes I know The purpose of my preceding post was just to indicate how to calculate precisely the number of the last visible line, which seems to me a very important step before doing anything else : remember the height of the scroll thumb should be recalculated when comparing the number of visible lines to the number of total lines, which will constantly change while the user adds/removes lines. In a 2nd step, I went a bit further, adding a registered WM_COMMAND message to take care of $EN_CHANGE or $EN_UPDATE, which could call a function dedicated to resize/move the scroll thumb (or hide it when all lines are visible in the richedit area) Maybe $EN_UPDATE is a better choice than $EN_CHANGE because the scrolling function will be called only from this place ($EN_UPDATE) . Because if you choose instead to monitor $EN_CHANGE, then you'll have to call the scrolling function from several other places (for example from inside WM_NOTIFY while you're using the mouse wheel to scroll [this triggers $EN_UPDATE but not $EN_CHANGE], or from a resize function, in case one day you allow the richedit control to be resized while you resize the GUI etc...) The annoyance with $EN_UPDATE is that it's called more often than $EN_CHANGE, which means the scrolling function will also be called more often when using $EN_UPDATE (compared to $EN_CHANGE) Anyway, all this is challenging for educational purpose. If I succeed achieving some working code, I"ll post it here. Glad to know you're feeling better

Hi everybody If I'm not mistaken, there are 2 examples in the help file where an inappropriate structure is created. Though the result is correct, it's a bit confusing. Topics are : _GUICtrlRichEdit_AutoDetectURL _GUICtrlRichEdit_GetTextInRange Here is the incorrect part : ... _GUICtrlRichEdit_SetEventMask($g_hRichEdit, $ENM_LINK) ... Func WM_NOTIFY($hWnd, $iMsg, $wParam, $lParam) ... Case $iCode = $EN_LINK $tMsgFilter = DllStructCreate($tagMSGFILTER, $lParam) If DllStructGetData($tMsgFilter, "msg") = $WM_LBUTTONUP Then $tEnLink = DllStructCreate($tagENLINK, $lParam) $iCpMin = DllStructGetData($tEnLink, "cpMin") $iCpMax = DllStructGetData($tEnLink, "cpMax") MsgBox($MB_SYSTEMMODAL, "", "Invoke your web browser here and point it to " & _ _GUICtrlRichEdit_GetTextInRange($g_hRichEdit, $iCpMin, $iCpMax)) EndIf ... EndFunc The structure $tagMSGFILTER has nothing to do with $EN_LINK . Only $EN_MSGFILTER should use $tagMSGFILTER . Imho both examples should be modified like this : ... _GUICtrlRichEdit_SetEventMask($g_hRichEdit, $ENM_LINK) ... Func WM_NOTIFY($hWnd, $iMsg, $wParam, $lParam) ... Case $iCode = $EN_LINK $tEnLink = DllStructCreate($tagENLINK, $lParam) If DllStructGetData($tEnLink, "msg") = $WM_LBUTTONUP Then $iCpMin = DllStructGetData($tEnLink, "cpMin") $iCpMax = DllStructGetData($tEnLink, "cpMax") MsgBox($MB_SYSTEMMODAL, "", "Invoke your web browser here and point it to " & _ _GUICtrlRichEdit_GetTextInRange($g_hRichEdit, $iCpMin, $iCpMax)) EndIf ... EndFunc Thanks for reading

@argumentum I deleted my initial post : what I suggested works for older Scite versions, it won't work for OP's Scite version 4.4.6 (just tested) . So please feel free to remove your like, sorry for the inconvenience. For the record, what I suggested was to add, not only the line "indent.size=4" but also the following line in the file SciTEUser.properties (I got both lines in my properties) : indent.size.*.au3=4 On older Scite versions, without this line, indentation of au3 scripts is 3 : On older Scite versions, with this line, indentation of au3 scripts is 4 : But it doesn't seem to work with Scite 4.4.6 @HezzelQuartz Could you try Scite menu => Options => Use Monospaced Font Who knows, maybe it will solve your indentation issue ?