Scrollbars in SCREEN 0. Some advantages of QB64 over QB45.

[Pete]

Advantage, speed. The extra speed of QB64 allows for simple use of CLS 2 and screen reprinting. PCOPY, also available in QB45, stops CLS flicker. I can't remember QB45 running fast enough to use CLS 2. I always made a custom printing routine like DIM a as string * 149 to print blank unused spaces over other strings on a screen with a width of 150 and a scrollbar at the 150 position.

I posted the routine here: https://www.tapatalk.com/groups/qbasic/i-m-working-on-a-scrollbar-rotine-t39417.html#p212427

It works with arrow up and down keys, mouse clicks on arrows, mouse clicks inside scrollbar, mouse drag on scroll block, and auto scrolling if you hold the left mouse button down while scrolling. My only improvement would b to find a way to get the drag part faster. There is lag. If the EXIT DO is eliminated in the drag routine, so it doesn't print to the screen, the drag timing is perfect. So it's just the time it takes to reprint the screen that messes with it a bit.

I wish I could easily find my old algorithm for different kinds of scrollbars. This one I made from scratch. Also, in the old days, I took the time to optimize the code, due to memory limits of QB45. Sure, QB45 had plenty to run programs like this one, but not so much when you started incorporating many programs together. QB64 eliminates the need for that. Bill would say I like QB64 like I liked my old girlfriends, fast and sloppy. SHUT UP BILL!

Pete

[FellippeHeitor]

Looking good, Pete.

What other kinds of scrollbars would there be?

[Pete]

Horizontal scrollbars
Scrollbars straight from Mars
Scroll up
Scroll down
Scroll right
And all around

We didn't start the program...

Pete :D

[bplus]

"And all around"

Aha! idea: Scrollballs!

If we can keep your antivirus program from scanning it. :D

[Pete]

You just ruined the whole concept of drag and drop for me.

Pete :D

[bplus]

Sorry about that, today I realized the scrollbar is a great visual cue of where you are in a large text block or list. That is nice advantage.

Speaking of lists, my list item selection code updates the screen fairly quick when using a mouse wheel, so the slight delay with the scrollbar is definitely a curiosity.

What are your future plans with scroll bar, maybe combine with the editor code started for Android?

[STxAxTIC]

nearly fixed the drag problem with two edits that differ by a minus sign. barely tested for errors but the idea is to take the average of the slider position and the vertical mouse position to determine the "jump"

Code: QB64: [Select]

1.                     IF slide < my% THEN
2.                         index = INT((noe / (vp2% - vp1% - 1)) * (slide + 1 - vp1%))
3.                         LOCATE slide, w1%: PRINT CHR$(177);
4.                         LOCATE slide + 1, w1%: PRINT CHR$(254);
5.                         slide = CSRLIN + INT(.5 * (my% - slide))
6.                         _DELAY .05
7.                     ELSEIF slide > my% THEN
8.                         LOCATE slide, w1%: PRINT CHR$(177);
9.                         LOCATE slide - 1, w1%: PRINT CHR$(254);
10.                         slide = CSRLIN + INT(.5 * (slide - my%))
11.                         index = INT((noe / (vp2% - vp1% - 1)) * (slide - vp1% - 1)) + 1
12.                         _DELAY .05
13.                     END IF
14.  

[bplus]

Has the original code in OP been changed? I don't remember it working so well with mouse wheel?

Testing STxAxTIC mod with current copy from link, I get error when below text lines.

May I ask what the _DELAY .05 lines are supposed to do?

[STxAxTIC]

oh yeah i think i copied from the forum he linked to

[FellippeHeitor]

@bplus:

Speaking of lists, my list item selection code updates the screen fairly quick when using a mouse wheel, so the slight delay with the scrollbar is definitely a curiosity.

May I ask what the _DELAY .05 lines are supposed to do?

That.
@STxAxTIC: hi, man!

[bplus]

Hi Fellippe,

Actually the new code is working well, and if there is a delay while dragging the slider it might be because getting off the X track with the mouse.

I commented out delays (at slider code) and see no problem though tests weren't extensive.

[bplus]

Ha! I just found a big fat _DELAY .2 ! in my list item selection code: https://www.qb64.org/forum/index.php?topic=529.0

There, it was needed to stop code reacting as if a section of screen was clicked multiple times, a problem Qwerkey has noted and discussed with the "Is There a Mouse Equivalent of  _KEYCLEAR" thread: https://www.qb64.org/forum/index.php?topic=935.0
 I had a page up and page down bar and when clicked without the big fat delay if would page up or down to the beginning or the end of the list.

But I am not seeing that problem with Pete's code which is why I am asking why the delay is needed there.

[Pete]

Hi Mark: Yes, I updated my code yesterday, to include a _mousewheel function it didn't have before. Fell mentioned that to me. QB45 did not have that option.

I had to get used to QB64 _MOUSE workings. I had pretty well mastered using CALL INTERRUPT routines for mouse movement in QB, but i decided since I switched to QB64 to get used to the new mouse functions. At first, I noted some problems as you mentioned, needing delays, etc., but I worked them out with some methods like button releases. Some events happen as soon as you press the button, others wait until the button is released. You can effect how that happens by adding the button release code either before or after the event takes place. For example, in your code at line...

IF _MOUSEBUTTON(1) THEN 'click contols or select array item

you could wait until the left mouse button is released to act by adding...

 WHILE _MOUSEBUTTON(1): somevariable = _MOUSEINPUT: WEND

right after your statement.

If you wanted the action to happen on the downward press, you would need to assign a variable to _MOUSEBUTTON(1) like lb% or something and use a mouse call to poll it. Something like this would do...

Code: QB64: [Select]

1. DO
2.     CALL mouse(mi%, mx%, my%, lb%)
3.     IF lb% THEN LOCATE 1, 1: PRINT "Left mouse button down...     ": mflag% = -1
4.     WHILE _MOUSEBUTTON(1): CALL mouse(mi%, mx%, my%, lb%): WEND
5.     IF mflag% AND lb% = 0 THEN
6.         LOCATE 1, 1: PRINT "Left mouse button released...     ": mflag% = 0
7.     END IF
8. LOOP
9.  
10. SUB mouse (mi%, mx%, my%, lb%)
11.     mi% = _MOUSEINPUT
12.     mx% = _MOUSEX
13.     my% = _MOUSEY
14.     lb% = _MOUSEBUTTON(1)
15. END SUB

As far as the .05 delay is concerned, I included an auto-scroll feature so when the button is held down, the scrolling speeds up. That speed had to have a timing factor, and I liked the effect at .05.

At Bill: I was able to fix my one complaint about dragging by getting rid of a WHILE:WEND statement I just didn't need it the original code. Thanks for having a look at it though. I know it's difficult when you don't get to see all the things tat need to be integrated. As Mark pointed out, the adjustment worked in one way but caused an unexpected problem, too.

Thanks for trying it out guys!

Pete

[bplus]

Thanks Pete, I tried

Code: QB64: [Select]

1. WHILE _MOUSEBUTTON(1): somevariable = _MOUSEINPUT: WEND

in place of

Code: QB64: [Select]

1. _DELAY .2

It worked fine and makes more sense to me because we are just waiting for the mouse button to be released before proceeding.

Do you have plans for scrollbar code?

[Pete]

I use databases a lot and just thought I'd implement this code, which I did yesterday, to one of the address programs I developed. It worked great, so now instead of clicking a page up  / down button, I can just use the scrollbar. I had those for earlier programs, like my appointment book program, drop down menus, etc. I just like making them from scratch so I don't end up old and stupid. My wife said, oh well, at least you accomplished half your goal. When I asked her which half that was, she just smiled and said when you accomplish the other half, you'll figure it out!

Pete