No Auto-Scrolling of text in GUI Edit controls

Report problems with documented functionality
niculaegeorge
Posts: 3
Joined: 06 Dec 2017, 13:26

No Auto-Scrolling of text in GUI Edit controls

06 Dec 2017, 13:49

I'm using Autohotkey 32bit v1.1.26.01 and Windows 7 Ultimate 64bit SP1
I want to make a teleprompter with smooth-middle-button-drag&scroll text pixel by pixel (a.k.a "Auto-Scrolling") (Easier to read). Apparently multi-line Edit control fields won't let you press & hold the middle mouse button and move your mouse to scroll smoothly, only manual line by line:

Code: [Select all] [Download] GeSHi © Codebox Plus

;No smooth scroll:
FileRead, mytext, C:\IN.TXT
Gui, Add, Edit, h200 w200, %mytext% ;This edit control can't smooth-middle-button-drag&scroll text!
Gui, Show
return

But this script can:

Code: [Select all] [Download] GeSHi © Codebox Plus

FileSelectFile, OutputVar      ;a very totally useless line of code here... hmm ... or is it now?
FileRead, mytext, C:\IN.TXT
Gui, Add, Edit, h200 w200, %mytext% ;This edit control MAGICALLY CAN smooth auto-scroll text!!! WTF???
Gui, Show
return

Just a completely unrelated line, :problem: MAGICALLY allows the user to smooth-middle-button-drag&scroll the text pixel by pixel. :wtf: How can this be? I've lost over 20hours of programming Autohotkey to do something that was never intended to do by forcing dynamic gui text fields with "GuiControl Move" and complex adjustable-interchangeable text field contents for my teleprompter only to reach dead ends. If interested I can post my code, maybe of some use to someone. All until I "accidentally" (if there even is such a thing) ran an old script of mine where I could smooth scroll a text inside an Edit control. Imagine my frustration wasting so many hours BECAUSE OF THIS BUG that made me believe I can't auto-scroll inside an Edit control. :headwall: Shouting and screaming in vain... pulling my hair off...Does anyone even care confirming this? :cry:
Guest

Re: No Auto-Scrolling of text in GUI Edit controls

07 Dec 2017, 03:19

The problem with this auto-scrolling in edit controls is too fast and even though looks smooth, :geek: i believe internally is still done one line at a time, as it's impossible to stop the auto-scroll somewhere in-between lines once started (I've tried every combination of mouse controls and delays imaginable). :think: The Autoscroll in Autohotkey GUI Edit controls seems to be "faked" and emulated somehow just to look cool and appear smooth. It still auto-scrolls a minimum of one line at a time, tough more smoothly than jumping from one line to the next by manually spinning the mouse wheel. Nothing like we see for instance the auto-scroll in Autohotkey help file window or any modern browser for that matter, which are OS windows where a true pixel-by-pixel smooth-insanely...S...L...O...W...-autoscroll function is possible.
niculaegeorge
Posts: 3
Joined: 06 Dec 2017, 13:26

Re: No Auto-Scrolling of text in GUI Edit controls

07 Dec 2017, 04:12

Since I'm already using a black windows theme, I'll build my prompter around this core script: :dance:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



COM Standard Library for Autohotkey required:
https://github.com/ttnnkkrr/COM.AHK/releases/tag/1.0
lexikos
Posts: 5979
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: No Auto-Scrolling of text in GUI Edit controls

09 Dec 2017, 00:52

Is there some reason you think the absence of this feature is a bug? As far as I am aware, the documentation does not mention this feature at all. Microsoft's documentation does not indicate the feature even exists, let alone how to activate it.

Notepad uses the same type of Edit control (along with countless other applications and system dialogs). When you initially open Notepad, middle click does nothing. After you bring up the Open or Save dialog, middle click activates auto-scroll. So clearly this is a Windows quirk.

niculaegeorge wrote:COM Standard Library for Autohotkey required:
That's obsolete. See ActiveX.

Code: [Select all] [Download] GeSHi © Codebox Plus

Gui, +Resize +LastFound
Gui, Margin, 0, 0
Gui, Add, ActiveX, w500 h500 vweb, Shell.Explorer
Gui, Show, w500 h500
web.Navigate2("C:\in.htm")
Return

GuiClose:
ExitApp
or

Code: [Select all] [Download] GeSHi © Codebox Plus

Gui, +Resize +LastFound
Gui, Margin, 0, 0
Gui, Add, ActiveX, w500 h500, C:\in.htm
Gui, Show, w500 h500
Return

GuiClose:
ExitApp

I'm guessing that initialization of the components required by Explorer (which is also used by the file dialogs) indirectly enables auto-scroll.

Code: [Select all] [Download] GeSHi © Codebox Plus

Gui, temp: Add, ActiveX, , Shell.Explorer
Gui, temp: Destroy
FileRead, mytext, C:\IN.TXT
Gui, Add, Edit, h200 w200, %mytext%
Gui, Show
return


i believe internally is still done one line at a time
Not on my system. I can see that it is pixel by pixel (when it functions at all), although the last line of text appears to have some clipping issues. (This might be peculiar to my system or 125% DPI setting.)
niculaegeorge
Posts: 3
Joined: 06 Dec 2017, 13:26

Re: No Auto-Scrolling of text in GUI Edit controls

09 Dec 2017, 05:28

I'm sorry. :oops: You are totally correct. IN ANY SOFTWARE THE ABSENCE OF A FEATURE IS NOT A BUG. Silly me for thinking otherwise. I stand corrected. Yes, i concur, code i posted it's a Windows quirk not Autohotkey. :salute: I apologize for missing that and thank you for the info. I shouldn't even be in this bug section of the forum. :shifty:
My code so far:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



Can't seem to send CTRL key to resize text and don't know how to smart detect EOF in this auto-scroll state, except for a clumsy no_change_in_PixelGetColor somewhere_on_the_GUI_window...

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 3 guests