|
|
Post by Robert on Mar 16, 2023 16:13:51 GMT -5
Scroll bars? Sure wish you had 'em.
Yes, I know it is contrary to the SPFLite design. Yes, I know it is impossible. Yes, I know it would require a total rewrite. (Doesn't everything?)
But, imagine the hypothetical case where you were so inclined to do the impossible. How could you do it anyway?
First answer: Beats me. I am not the developer. Still ...
Maybe it's not impossible. Supposing it weren't, how could it possibly be done?
Well, SPFLite is a true Windows application. Somehow, somewhere, are the various Windows components that implement scrolling. If you could somehow "attach" scroll bars to an SPFLite edit window, you would have to handle scrolling actions as new items in the Windows message queue. You would then (I think) have to translate those messages into SPFLite equivalents, and insert them into the SPFLite input queue, AS IF they were simulated key strokes or mouse clicks.
Perhaps the tricky part would be to make that translation. Based on the size of the current file being edited, you would have to calculate a scrolling-factor number.
For example, if you moved the vertical scroll bar "half way" down, it would mean 50% of the file. If the file had 1000 lines, you'd need to scroll down 500 lines. Right now, primitives like (ScrollDown) can take a repetition factor, so going down 500 lines could be done with (500:ScrollDown). I believe you have some primitives involved with 'motion' that can take a number on the right, like (Right/10) that is supposed to run faster. Maybe that could be applied to (ScrollDown/500) to make it run faster than the generic (500:ScrollDown) format.
The calculation to convert scroll-bar motion to a number of lines to scroll would be done as a "best effort" but would be approximate. That's how a 'real' Windows app scrolls. You scroll the best you can, then 'fine tune' it once you get close to where you want.
If the scroll bars had the usual scrolling arrows like ▲ ▼ ◀ ▶ these could be translated into simple (ScrollUp), (ScrollDown), (ScrollLeft) and (ScrollRight) primitives.
I don't want to go any further on specifics. We all know how easily ideas can descend into arguments, and I don't want to go there.
Well, that's the idea.
|
|
|
|
Post by George on Mar 17, 2023 9:15:49 GMT -5
Robert: No arguments. And no, it's not impossible. And no, not a total re-write.
But it does get into a messy area - the whole screen layout / resize area.
There's nothing else going on, I'll explore the scrollbar control and it's details as a start.
George
|
|
|
|
Post by Robert on Mar 17, 2023 21:40:20 GMT -5
Well, no doubt it could get tricky in places. I am guessing the first thing is to determine just how, exactly, you could even do it at all. Maybe the biggest initial hurdle is how would you go about "attaching" a scroll bar to an SPFLite edit window? Once that part is figured out, it might be somewhat easier from there.
One simplifying approach would be to only support vertical scrolling. I use MS Word daily. It has both vertical and horizontal scrolling, but I very seldom scroll horizontally. Same for Notepad++. Even in SPFLite, My F10 and F11 are LEFT and RIGHT, but I don't often need these either. This is where user input is really needed. What do all y'all users want? Is this a feature you'd benefit from? Before George does anything really hard, your input would really help a lot here.
If people wanted scrolling but only needed vertical scrolling, that would be quite a reduction in the work effort to implement this.
|
|
|
|
Post by Stefan on Mar 18, 2023 4:42:46 GMT -5
I can't help wondering ..... Why?I'm unclear about... - How a scroll bar will improve productivity, given the many different ways we already have to scroll (accurately and/or approximately) through the data in the window. - What could I do BETTER with a scroll bar or what can I not do unless I have a scroll bar? - Why would I want to lose at least one line and one column from the display height/width to gain this ability? To do this properly, you need vertical and horizontal scroll bars. And they would need to work on all display formats, FM, EDIT, etc I think this proposal would benefit from a consultation with the forum's user community.
Currently I'm in the "not a fan" category, unless I'm missing some fundamental USP.
|
|
|
|
Post by George on Mar 18, 2023 8:53:14 GMT -5
Stefan: Well, I wouldn't mind having it, but just vertical, horizontal is just not worth it. I scroll a lot with the mousewheel, and in a big document it becomes painful. Dragging a scrollbar would be nicer.
Initial 'look at' says this isn't too painful a change.
George
|
|
|
|
Post by mueh on Mar 18, 2023 12:47:31 GMT -5
George: I would prefer Dragging in Status Bar Box 10 without losing 1 or 2 columns of data .
Thanks
|
|
|
|
Post by Robert on Mar 18, 2023 12:56:39 GMT -5
George, a good case could be made for making the scroll bar(s) optional. A new check box would be needed in the Options GUI, either in the General tab or in Screen tab, to enable their use. The GUI screen space on both of those tabs is pretty tight right now, so you may need a crowbar - or else you may have to enlarge the Options screen's overall size a little to make it fit.
Mueh, there seems to be agreement that horizontal scrolling isn't needed - or, at least, not needed initially.
Here is a crazy idea: Suppose the status bar semantics were changed to be "dual usage". That is, suppose you could click on the Status Bar and HOLD it. When that condition is detected, the status bar would get *temporarily* changed into a horizontal scroll bar. You would then move the mouse left or right (only left or right mouse movements would be accepted, and all other mouse motions ignored) to scroll the file left or right. Once you let go of the mouse button, the status bar would 'revert' back to its normal function.
That way, you could have a horizontal scroll control, without giving up *any* screen space.
The logistics of pulling that off would be tricky, and it's not something that's needed at all at first. Just an idea to kick around.
|
|
|
|
Post by George on Mar 18, 2023 13:48:00 GMT -5
Guys: I've been experimenting. And the MS and PB support for ScrollBars is pretty good, making things much simpler.
But really? The width of a ScrollBar (a couple columns at best) is a problem? I have a real problem with that. I've seen some of your CFG files and experienced what you're screen looks like.
MUEH: A scrollbar in the StatusBar? Never seen that, let alone any code that even attempts it. Doubt it's possible.
Robert: Same for a 'dual purpose' Status bar.
I will try to make this optional, but doing so is total 'code clutter'; as well as a new option and all that support, it means IF/ELSE code blocks in a whole bunch of places.
I knew I never should have touched this one.
George
|
|
|
|
Post by Robert on Mar 18, 2023 15:36:57 GMT -5
Well, the "optional" part was only to placate those objecting to giving up a column on the right. Personally, I almost never consume the very last column. I think if I were really in THAT much of a bind on screen space, I'd either remove a column from the line command width, or else make the font smaller.
Ditto comments on dual purpose status bar. Don't need it myself. Making it optional is more work than it's worth.
Here is my alternative that I *think* could help a lot:
Right now, in Screen global options, you have the ability to type in the font size. I use Courier New 13. If I could enter a font size of 12.5 it would free up more than enough room to make way for a scroll bar.
Problem is, the dialogs (yours AND the Windows font selection dialog) won't allow me to type 12.5
This is odd, because I can say 12.5 as a font size in MS Word and it works find. And, MY Word software goes way back to the 2003 version.
If you could allow a fractional font size, that would solve the 'extra space for scroll bar' objection.
I *think* there might be an alternate font selection dialog that DOES allow ".5" font sizes, if you could just find it.
P.S. Even Word only allows a fraction of .5 and no other fractional amount.
|
|
|
|
Post by Robert on Mar 19, 2023 12:38:46 GMT -5
George, just tried the new beta with scrollbars.
Gotta say, it looks real good, works fine and scrolling a large file (about 12,000 lines) is real fast. Just like the big boys downtown.
The only "hitch", if you can call it that, is that with large files, the scrolling "handle" is (inversely) proportional to the size of the file, and it can get pretty small to aim for with the mouse. Not sure if there is anything you can do about it. The scroll bar itself seems *slightly* wider than others I can readily compare to, like my browser. Wouldn't mind if it were a 'tad' narrower. But again, I am not sure if there is anything you can do about that.
I hope some day you would look into the fractional font size thing I mentioned above.
Overall, I have to say, well done, and surprisingly fast.
R
|
|
|
|
Post by Robert on Mar 19, 2023 13:16:14 GMT -5
Except ...
I have a macro that runs on a fairly large file about 12,000 lines long. In the prod version, the macro takes about 2 seconds to run. In the beta, it takes a very long time and issues the "loop" message for the same macro running against the same data file. The macro involves doing several thousand line inserts as part of its processing.
If the scroll bar metrics get recalculated every time a new line is inserted, this could be a problem. I had to go back to the prod version to get things to work reliably.
|
|
|
|
Post by George on Mar 19, 2023 15:12:21 GMT -5
Robert: OK, I've adjusted the ScrollBar width to match the system's default.
And I've made a change to hopefully fix the macro overhead thing - to be checked.
I'll check out fractional font sizes. Probably the variable is defined as an integer and should be floating.
The custom change for your 1 char auto-selection is a real problem. A fudge like that because it may be difficult to mark a single character is a roadblock. I don't think we can continue accomodating an request like this. This kludge has to go. BTW, I tried selecting a single character with the mouse - yes, you have to be careful, but it's not ridiculous.
George
|
|
|
|
Post by Stefan on Mar 20, 2023 6:13:57 GMT -5
Stefan: Well, I wouldn't mind having it, but just vertical, horizontal is just not worth it. I scroll a lot with the mousewheel, and in a big document it becomes painful. Dragging a scrollbar would be nicer. Initial 'look at' says this isn't too painful a change. George
I see you've already coded up a scroll bar, so this may be irrelevant. But with an eye on the macro issue...
I just wondered if modifying the scroll wheel effect 'on the fly' is a possibility.
The mouse scrolls the number of lines defined in the Windows 10 - Mouse Settings dialog.
Maybe the application (SPFLite) could multiply that number by, say, 10 to facilitate faster scrolling.
Simple mouse scroll would perform as now. Holding down SHIFT key while scrolling goes 10 times faster. The multiplier would be set on one of the OPTIONS pages, either as a numeric multiplier or a pseudo value like PAGE or HALF.
|
|
|
|
Post by George on Mar 20, 2023 8:39:52 GMT -5
Stefan: From the Help file.
Scrolling
If scrolling is activated (see "Options - General") the mouse wheel may be used to scroll the text window
in an edit session, or a list of files in the File Manager. The number of lines scrolled by each mouse-wheel
click is set in Options.
Scrolling is normally done vertically. Holding the Shift key while using the mouse wheel causes horizontal scrolling.
(Think: "shift = sideways")
Holding the Ctrl key while using the mouse wheel will cause a 4 X speedup of the scrolling action when
you want to scroll long distances within a large text file. This is called Turbo Motion, or Turbo Mode scrolling.
If you want to do horizontal scrolling in Turbo Mode, you can hold the Ctrl and Shift keys at the same time while using the mouse wheel.
|
|
|
|
Post by Stefan on Mar 20, 2023 9:16:49 GMT -5
George, I had no idea about that. Guess I've never looked up SCROLLING in the Help document. So you already allow the user to specify how many lines/cols each 'notch' on the mouse wheel represents and a fastscroll hardcoded to "4 x normal". Perhaps you only need a user-modifyable setting for the 'fast' repeat factor when CTRL is held down too. Why not add one for this and the mousewheel can scroll slow/fast at any user-defined rate. YOu'd get vertical and horizontal scrolling and all without the need for wider-ranging code interventions. To release some space on the OPTIONS-GENERAL page, I might also consider introducing a 'pseudo-key' specifically to represent the mouse-wheel on the KEYMAP dialog. That way users can pick which SHIFT/CTRL/ALT/etc combination does what. To keep this all together, I'd also move the 'values' for each action from OPTIONS-GENERAL to KEYMAP. The scroll values would be arguments to the existing primitives, eg: (ScrollDown <arg>), etc, where <arg> is a number-of-lines or H or P.
|
|
