Strange Window Stuttering

I am testing a custom control (container with canvas and two scrollbars), this control is then inside a document window

when I move or resize the window, it jumps all over the screen and changes sizes (there is no code that directly refereces the actual window at all)
same thing if I use the vertical scroll bar on the control (but seeming not the horizontal one)

Hmmmm… it seems to be related to creating a Event Definiton for the Canvas Paint Event.
it does custom drawing, then calls Paint to allow the developer to add more paint operations

CONTAINER CONTROL PAINT EVENT

Sub Paint(g As Graphics, areas() As REALbasic.Rect) Handles Paint
  #Pragma unused g
  #Pragma unused areas
  displayArea.Invalidate
  //
End Sub

DISPLAY AREA (canvas) PAINT EVENT

Sub Paint(g As Graphics, areas() As REALbasic.Rect) Handles Paint
  
  g.ClearRect 0,0,g.Width,g.Height
  //
  // Set Controls BACKGROUND color
  //
  If HasBackColor Then 
    g.ForeColor=BackColor
  Else
    If IsDarkMode Then 
      g.ForeColor=RGB(22,22,22)
    Else
      g.ForeColor=Color.white
    End If
  End If
  
  g.fillrect 0,0,g.Width,g.Height
  
// Do some drawing stuff
.....

  // the purpose of this is to forward the Paint Event to the outside world
  paint(g,areas) 
  
    g.drawrect 0,0,g.Width,g.Height
End Sub

Event Definition in CONTAINER

[code]
Event Paint(g as graphics, areas() as REALbasic.Rect)

[code]

wondering if this is causing some kind of loop?

the problem is (or how I see it)…
to the develper there is ONE control (ie. the Container)… therefore the exposed PAINT event must belong to that container…
BUT… all the Painting happens inside DISPLAYAREA… not on the container itself

[quote=445077:@Dave S]// the purpose of this is to forward the Paint Event to the outside world
paint(g,areas) [/quote]
Dave, you’re better at this stuff than I am but I think you are trying to pass it up the chain to <Parent.>Paint (container control paint). But wouldn’t this call at the end of the display area (canvas) event cause a recursive condition in the canvas?

yeah… that is what is seems is happening…

I used a Canvas to avoid having to “clip” for the areas covered by the scrollbar.
but now I’ve removed that and will draw directly to the container… thus removing that “problem”

initial testing seems to indicate that solved the problem

Spoke too soon :frowning:

Container.PAINT forwards PAINT event (no intervening canvas)
and it STILL stutters

both 32bit and 64bit (macOS 10.14, Xojo 2019r1.1)

OH! SOLVED IT!

In the 2nd Paint Event (the one forwarded from the control)… I referenced a variable called TOP… turns out this was WINDOW.TOP so yeah things went to heck in handbasket …