Keep the caret visible after resize

[Mike Lischke]

Hi,

when you move the caret (either by using the arrow keys or by writing) it is always kept visible by scrolling the content. However when the scintilla window is resized (say, the height decreased) and the caret was at the bottom it is no longer visible, irritating so the user. Is it possible to let Scintilla also scroll automatically in this case? Or do I have to adjust the scroll offset explicitly in such situations?

Thanks,

Mike

[Chinh Nguyen]

I usually follow the rule of WWXCD (what would Xcode do?) but in this case,
Xcode's behavior is weird. In Xcode, if the caret is visible and you
decrease the height, no scrolling is done to make the caret visible. If
the caret is visible and you increase the height, the caret is scrolled to
the middle.

To keep the caret/selection visible when a window is resized, I wrote a
method that returns the selection's rectangle in the InnerView's
coordinates by offsetting the values returned by SCI_POINTXFROMPOSITION and
SCI_POINTYFROMPOSITION (from the selected range) by the InnerView's
visibleRect and when the selection length is zero, I used SCI_TEXTWIDTH of
a space and SCI_TEXTHEIGHT to set the width and height of the rectangle.
In my subclass of ScintillaView, I have a viewWillStartLiveResize method
that sets a flag if the selection is visible in the InnerView's
visibleRect. In my viewDidEndLiveResize method, if the selection was
visible but will not be visible at the end of resizing, I

NSRect selectionRect = self.selectionRect;

if (!NSPointInRect(selectionRect.origin, self.content.visibleRect)) {

[self.content scrollRectToVisible:selectionRect];

}
However, I turned off this code because I didn't really have time to fully
test it and none of my users have complained.

Post by Mike Lischke
Hi,
when you move the caret (either by using the arrow keys or by writing) it
is always kept visible by scrolling the content. However when the scintilla
window is resized (say, the height decreased) and the caret was at the
bottom it is no longer visible, irritating so the user. Is it possible to
let Scintilla also scroll automatically in this case? Or do I have to
adjust the scroll offset explicitly in such situations?
Thanks,
Mike
--
www.soft-gems.net

[Mike Lischke]

Hey Chinh,

I usually follow the rule of WWXCD (what would Xcode do?) but in this case, Xcode's behavior is weird. In Xcode, if the caret is visible and you decrease the height, no scrolling is done to make the caret visible. If the caret is visible and you increase the height, the caret is scrolled to the middle.

As usual things highly depend on the circumstances. I my case it's so that a user can have several queries in the editor and run each individually (using a shortcut, for instance, to run the query near the caret position). When you have to resize the editor after that (e.g. to show query results) and the just run query disappears from the screen you can highly irritate and even annoy users. I have therefore added automatic scrolling in this scenario.

Mike

[Philippe Lhoste]

Post by Mike Lischke
As usual things highly depend on the circumstances. I my case it's so that a user can have
several queries in the editor and run each individually (using a shortcut, for instance,
to run the query near the caret position). When you have to resize the editor after that
(e.g. to show query results) and the just run query disappears from the screen you can
highly irritate and even annoy users. I have therefore added automatic scrolling in this
scenario.

People get easily irritated by their software... Personally, I tend to develop workarounds
for these minor annoyances that can rarely happen and aren't work a bug report...
For example, no need to resize (I rarely resize my windows anyway): just click somewhere
and scroll the text: the caret just disappear. It is normal behavior, I don't want the
caret position to be lost or to be prevented of scrolling!
In this case, I just hit one arrow key and bam! I am back where the caret is...

I don't mean your problem cannot or shouldn't be addressed, but to be "highly irritated"
by the behavior seems a bit overreacting, IMHO. :-)
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[Mike Lischke]

I don't mean your problem cannot or shouldn't be addressed, but to be "highly irritated" by the behavior seems a bit overreacting, IMHO. :-)

It's also sometimes suprising how people recognize free software and what they expect from it. I got more than once bug reports with comments like "how has this s* piece of software made it through QA if such a simple feature does not work as people expect it" (read: it's bad software if it does behave exactly like I want it). And if there are no more important things to solve then I try to satisfy also such people ;-)

Mike

[Neil Hodgson]

Platform functions such as subclassing can be used to detect resizing then the app can respond by scrolling the window in its preferred way, perhaps by calling SCI_SCROLLCARET. A resize notification could be posted by Scintilla if there is sufficient demand and people are willing to contribute implementation code.

The platform's concept of resizing may differ from yours: scroll bars turning on/off may change the size of the text area and may be treated as resizes or not. Moving the Scintilla widget may or may not cause a resize event. Live resizing can generate many resize events so slow notification code can make things laggy - you may only want one event when the resizing gesture is complete. Resizing is problematic with Direct2D on Windows as it destroys the drawing surface so it may be better to delay the notification and use SCN_UPDATEUI.

Neil

[Mike Lischke]

Neil,

Post by Neil Hodgson
Platform functions such as subclassing can be used to detect resizing then the app can respond by scrolling the window in its preferred way, perhaps by calling SCI_SCROLLCARET. A resize notification could be posted by Scintilla if there is sufficient demand and people are willing to contribute implementation code.

That would be the best solution. Not sure I come around implementing that in the near future (have already trouble answering the mails in time).

Post by Neil Hodgson
The platform's concept of resizing may differ from yours: scroll bars turning on/off may change the size of the text area and may be treated as resizes or not. Moving the Scintilla widget may or may not cause a resize event. Live resizing can generate many resize events so slow notification code can make things laggy - you may only want one event when the resizing gesture is complete. Resizing is problematic with Direct2D on Windows as it destroys the drawing surface so it may be better to delay the notification and use SCN_UPDATEUI.

SCN_UPDATEUI is sent for many other events so I would start scrolling in many unrelated cases.

Mike

[Neil Hodgson]

Post by Mike Lischke
SCN_UPDATEUI is sent for many other events so I would start scrolling in many unrelated cases.

The updated field is a bit mask of the reasons for the notification.

Neil