PureBasic Forums - English

Posted: **Mon Aug 18, 2025 12:24 am**

Owoowush ! I am alive ! (and tired lil bit...). What about a small concrete scrolling on the (burp...) "Window GUI" ?

3rd simulation, just to see, no problem of speed, except if you see anything boring !

Artefacts ? Freeze ? Anything boring ?
-> Write your misery, I ll try to clear !

Code: Select all

win = OpenWindow(#PB_Any, 0, 0, 1, 1, "", #PB_Window_ScreenCentered | #PB_Window_MaximizeGadget | #PB_Window_MinimizeGadget | #PB_Window_Maximize | #PB_Window_SystemMenu | #PB_Window_SizeGadget)
w = WindowWidth(win)
h = WindowHeight(win)

max = 255
Global Dim img(max)
Global Dim ig(max)
con = ContainerGadget(#PB_Any, 0, 0, w, h)
visibleRowQty = h / 16
font0 = LoadFont(#PB_Any, "courier new", 12)
font1 = LoadFont(#PB_Any, "courier new", 12, #PB_Font_Bold | #PB_Font_Italic)
For i = 0 To max
  img(i) = CreateImage(#PB_Any, w, 16)
  StartDrawing(ImageOutput(img(i) ) )
  Box(0, 0, w, h, RGB(255 - Random(31), 255 - Random(31), 255 - Random(31) ) )
  DrawText(0, 0, Str(i) + "  line #" + Str(i + 1), RGB(0, 0, 0), RGB(255, 255, 255) )
  If Random(1)
    DrawingFont(FontID(font0) )
  Else
    DrawingFont(FontID(font1) )
  EndIf
  DrawingMode(#PB_2DDrawing_Transparent)
  DrawText(100 + Random(w - 200), 0, Str(i) + "  line #" + Str(i + 1), RGB(Random(85), Random(85), Random(85) ), RGB(255, 255, 255) )
  StopDrawing()
  ig(i) = ImageGadget(#PB_Any, 0, 16 * i, 1, 1, ImageID(img(i) ) )
Next
CloseGadgetList()

winC = OpenWindow(#PB_Any, 0, 0, 1, 1, "", #PB_Window_BorderLess)
gadC = CanvasGadget(#PB_Any, 0, 0, 1, 1, #PB_Canvas_Keyboard)
SetActiveGadget(gadC)
Repeat
  SetWindowTitle(win, "Wheel the mouse " + Str(WindowMouseX(win) ) + " * " + Str(WindowMouseY(win) ) )
  ev = WaitWindowEvent()
  SetActiveGadget(gadC)
  If WindowMouseX(win) <> -1 And WindowMouseY(win) <> -1
    dmx = DesktopMouseX()
    dmy = DesktopMouseY()
    ResizeWindow(winC, dmx, dmy, 1, 1)
    wd = GetGadgetAttribute(gadC, #PB_Canvas_WheelDelta) * 3
    While wd
      oldOffset = offset
      If wd < 0
        offset + 1
        wd + 1
        If offset + visibleRowQty > max
          offset = max - visibleRowQty
        EndIf
      Else
        offset - 1
        wd - 1
        If offset < 0
          offset = 0
        EndIf
      EndIf
      If offset <> oldOffset
        For i = 0 To visibleRowQty
          SetGadgetState(ig(i), ImageID(img(i + offset) ) )
        Next
      EndIf
    Wend
  EndIf
Until ev = #PB_Event_CloseWindow

Posted: **Mon Aug 18, 2025 12:27 am**

Fancy, I like it!

Posted: **Mon Aug 18, 2025 12:38 am**

Thank you miso !

I have more problem to fix this GUI which has not changed since Windows 3 than already know how to do the final !!!

All is embedded in the container named con. But two hours wasted to observe no click can be detected in this gadget... Anyway....

Posted: **Mon Aug 18, 2025 12:54 am**

I can see 44 lines (whom the height is 16 pixels) on one screen. Who has more ?
What are your maximum ? (y resolution)

Posted: **Mon Aug 18, 2025 1:08 am**

44 Here, 64 on my other (1080 pix Height)

Posted: **Mon Aug 18, 2025 1:44 am**

Okay I can wait a test from a "4K" (135 lines) to know if there is no problem of speed (freeze or other)

Also, two technologic choices :

1) keep the height of each line up to 16 pixels and create the scrolling engine on this base.

2) modify each line height on the fly, depending of the font size of what it is displayed.

It is two methods fully different. I prefer the second one, which is more realistic and whom I already wrote an algo. But in this way, I will loose lots of you, because the algo is very strong. Unable to comment usefully : in this way, lots of schemes to tell the mechanism.

The first one, the problem is the step of 16 pixels : it is not beautiful. And I have no idea about the zoom... However the story of 4K, etc... No performance problem... Sure...

I will wait if anybody looks a performance problem with this small 3rd simulation.

And I will need a convention language to enrich the text, because the RTF language is absolutely not what I prefer. I d like a simpler language, an intuitive thing, which eases the write of a rich text.

Ex :

Code: Select all

//Arial//48//Green//Title of document
//Verdana//12//Black//
Introducing a concept of the headaches in our civilization has ever been considered as a __bold__strategy__ not to understand anything about the importance of all these flu.

Posted: **Mon Aug 18, 2025 12:25 pm**

Hi,
I am not sure if I catched the latest?
Maybe you should add a comment with version (counter) or similar.
So in maximized mode I see 130 lines. 4K-Monitor with 96 dpi (100%).

Observation:
In my opinion, scrolling is quite unacceptable compared to other editors (slow/not smooth).
Maybe the effect is because of the different background colors on every line.
White background is a little better, but still not eye friendly.

BTW: I never worked in maximized mode with my editors.

Posted: **Mon Aug 18, 2025 1:19 pm**

Interesting !
Howmany does your screen measure physically ?

Posted: **Mon Aug 18, 2025 3:57 pm**

entire (full) screen resolution: 3840 x 2160 Px
Well, you have to substract the taskbar-height and the window title height (maybe thats why onle 130 and a bit of line 131)

Posted: **Mon Aug 18, 2025 11:03 pm**

I said the adverb 'physically' : howmany inch ? Or howmany meter ?

My biggest screen had a diagonal of 80 meters, low resolution.
I tested a third method I shared 16 years ago. But I observe there is no synchronization link between Windows and the PureBasic program. Result : same effect as a ZX81, white horizontal band in the area which appears.

I think, natively, for the 4K, there are three ways : windowed openGL, windowed screen or full screen. These 3 ways allow the coder to set the synchronization.

If your screen is physically (= the size you can observe even when it is stand off) large, I am not surprised you never use the full screen to edit a text.

I factorized the line height value (actually 16 pixels on the previous source code) onto a variable : this will ease the change of this row height.
For your screen, we have two choices :
1) change the row height and test if a smaller quantity of rows displayed simultaneously on the screen (bigger font size so) restores the smoothness, and grows the displaying speed;
2) prepare a functional bottleneck to change easily the logical device target (windowed text versus accelerated screen).

Thank you for the approach between the page queue and the system task bar : it is a little bit more complex than a simple substraction.
a0) prepare the bottom or the top (depending of the key cursor direction) text line to insure ourselves this text line will be completely displayed (no height troncature). Adding (if from top to bottom) or substracting (if from bottom to top) each row height . Ever calculates, but displays only if it is not the first cycle (toward vertical sync)
a1) get the future row ("FR") height ("FRH") to be displayed, which is actually the first fully hidden row.
a2) Check the vertical overlap ("VOL") between ("delta" difference) the FR Y value and the bottom scope Y value. If delta = 0 then overlap is true. SHIFT = FRH else SHIFT = delta
a3) substract (if from down to up) or add (if from up to down) each row height with the SHIFT variable, displaying each of them, (so : calculates plus displays).(backward vertical sync)
a4) (next scroll cycle) go to a0 while the scrolling is wanted (arrow key, mouse wheel, etc...) .

As you can see, the process has a symetry, depending of the binary direction, so the code will be compacted.

As all these sums (positive or negative) are able to be predicted, all these sums won't be calculated on the fly, but on each scope resizing, or on each font size change.

This is the method #2 (shortly described above in this page). A scrolling of rows whom the heights are not equal not prime between them.

I shared a source code in the trick n tips (Or feature request, I do not remember) section in 2023. It was a blend of the 2 methods (what the row heights are equal or not), but the row heights was prime between them. (= no back zoom compatibility). As there was no opinion, I decided to delete it any days after. The most tooled here have got so this source code : it is very well structured (only one very big structure), but absolutely everything is commented in this big structure, my friends who have a "good automatic memory" !

But no back zoom (to the one-pixel row height preview), and no predictive cache, in this old very good code. So the future source code will be strangely short and complex.

The result for your eyes on 4K will be as bad as actually, but it is not a problem : the functional bottleneck described above will solve this synchro gap.

Posted: **Tue Aug 19, 2025 11:19 am**

Oh, l see. It is a desktop monitor of 28 inch. Not fancy.
You do not have to think about a solution for me. I wanted to share some of my observations, thats all.

Posted: **Wed Aug 20, 2025 11:54 am**

I go forward step by step, not for you, strongly, but for the owner of 4K in general. I find good to receive such remarks. Thanks to you !

Posted: **Wed Aug 20, 2025 2:55 pm**

Okay, then everything's fine.

PureBasic Forums - English

Build a text editor

Re: Build a text editor

Re: Build a text editor

Re: Build a text editor

Re: Build a text editor

Re: Build a text editor

Re: Build a text editor

Re: Build a text editor

Re: Build a text editor

Re: Build a text editor

Re: Build a text editor

Re: Build a text editor

Re: Build a text editor

Re: Build a text editor