Graphics bug?

[Walt Decker]

I know not if this has been mentioned but in the following code the vertical size of the graphic control is not honored when its parent window is resized in that direction. Looks like another bug.

'
GfxWide = 0
GfxHigh = 0

UpperLeftX = 50
UpperLeftY = 100
WindowWidth = DisplayWidth / 2
WindowHeight = DisplayHeight / 2

GfxWide = WindowWidth / 2
GfxHigh = WindowHeight / 2

OPEN "GFX BOX" FOR WINDOW AS #DMO
WinHndl = FN.GetHandle("DMO")
RetVal = FN.NewWin(WinHndl, GfxWide, GfxHigh)
WAIT

'-----------------------------------------------------------------
'-----------------------------------------------------------------

FUNCTION FN.CheckHandle$(Tag$)

IF LEFT$(Tag$, 1) <> "#" THEN Tag$ = "#" + Tag$

FN.CheckHandle$ = Tag$
END FUNCTION

'-----------------------------------------------------------------
'-----------------------------------------------------------------

FUNCTION FN.GetHandle(Tag$)

WinHndl = 0

Tag$ = FN.CheckHandle$(Tag$)

WinHndl = HWND(#Tag$)

FN.GetHandle = WinHndl
END FUNCTION

'-----------------------------------------------------------------
'-----------------------------------------------------------------

FUNCTION FN.NewWin(WinHndl, GfxWide, GfxHigh)

WS.BORDER = HEXDEC("&H00800000")

GfxHndl = 0
GfxWin  = 0

Ux = 0
Uy = 0
Bx = 0
By = 0

PRINT GfxHigh, WindowHeight
STYLEBITS #GFX.GFX, WS.BORDER, 0, 0, 0
GRAPHICBOX #GFX.GFX, 0, 0, GfxWide, GfxHigh

WindowWidth = GfxWide
WindowHeight = GfxHigh

OPEN "GFX" FOR WINDOW AS #GFX
PRINT #GFX.GFX, "down"
PRINT #GFX.GFX, "fill black"
PRINT #GFX.GFX, "flush"

END FUNCTION
'

[Brandon Parker]

Well, this is probably related to a parsing issue in LB. Since the Width & Height parameters are variables, something is going awry during the processing of the resize events(s). This is not the first time we have seen this. I do believe there is another post that Carl actually commented on not too long ago regarding a similar issue.

That being said, if you issue the following command at the end of your window creation function, the GraphicBox resizes with the window keeping its borders the same distance from the edges of the window. I think everything looks normal if you add this single line if I understand what you are trying to do.

#GFX.GFX "AutoResize"


{:0)

Brandon Parker

[Walt Decker]

Mr. Parker, autoresizing is not what I wanted to do nor is it the only way to get around the bug.

But that is not the point. These bugs should have been fixed years ago.

[Carl Gundel]

Hey Walt,

It's not clear to me what the bug is that you're pointing out.

[Walt Decker]

Mr. Gundel, it is here in the code:
STYLEBITS #GFX.GFX, WS.BORDER, 0, 0, 0
GRAPHICBOX #GFX.GFX, 0, 0, GfxWide, GfxHigh


I have pointed out bugs in STYLEBITS and defining control locations using variables, but this one is really weird. When the size border is dragged vertically the control expands in the vertical direction. It should not expand at all.

[Carl Gundel]

Dec 28, 2021 13:30:45 GMT -5 Walt Decker said:

Mr. Gundel, it is here in the code:
STYLEBITS #GFX.GFX, WS.BORDER, 0, 0, 0
GRAPHICBOX #GFX.GFX, 0, 0, GfxWide, GfxHigh


I have pointed out bugs in STYLEBITS and defining control locations using variables, but this one is really weird. When the size border is dragged vertically the control expands in the vertical direction. It should not expand at all.

If I comment out the stylebits statement it behaves the same for me.  I'll try to figure it out.  I'm not planning a v4.5.2 release but if enough people twist my arm I might change my mind.  Trying to focus on LB5.

[gidiom2]

Dec 28, 2021 15:54:09 GMT -5 Carl Gundel said:

If I comment out the stylebits statement it behaves the same for me.  I'll try to figure it out.  I'm not planning a v4.5.2 release but if enough people twist my arm I might change my mind.  Trying to focus on LB5.

  No pressure there, but I think some of the important bugs should be cleared. Please bear in mind that some of us will be using registered LB4 on 32 bit systems for the rest of our lives!