+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2)
+--- Thread: Color CONST Warning v1.5+ (/showthread.php?tid=346)
Color CONST Warning v1.5+ - bplus - 05-05-2022
I just ran into the problem again last night, checking out an old program that worked fine before version 1.5
This WAS a set of CONST's (without suffix because at one time you didn't need suffix for a CONST)
Code: (Select All)
Dim Shared As _Unsigned Long skyC, ballC, groundC, cannonC, printC ' fix color Const for v 2.0 and 1.5 broken too
skyC = &HFF9988FF
ballC = &HFF000000
groundC = &HFF405020
cannonC = &HFF884422
printC = &HFFEEDDCCI was reviewing a Mod I made of Ken's Artillary program years ago and surprised the dang cannon balls were blowing up at the ends of the cannons not having moved a pixel!?!? WTH
The Point value for sky was not matching the color Const for skyC.
Oh yeah, something (not so) funny happened to Color constants and now they need suffix or the above fix.
I am classifying this as a bug because code is not compatible with the past.
RE: Color CONST Warning v1.5+ - SMcNeill - 05-05-2022
All I can say here is, "I dunno." It's been some time since v1.3 or whichever it was prior to the change in the code. It'll take time to dig into it and see what's happened, but for now, if you know a work around (such as using suffixes to force type), I'd use those and not hold my breath on a fix. There's a ton of glitches we've inherited and are just now uncovering. Who knows how long it'll be to get everything sorted out!
RE: Color CONST Warning v1.5+ - bplus - 05-05-2022
Yeah I don't expect perfection, just trying to help with a warning.
RE: Color CONST Warning v1.5+ - Pete - 05-05-2022
@admin and @bplus
To chime in on a similar issue. If a user goofs the math on a _NEWIMAGE screen size, and uses the SCREEN function to get the screen color at a row and column, the system will return an illegal function call at the bottom of the screen. That's because let's say at a screen height of 630, the 40th row is shown by the mouse, on the screen, but beyond the 630 height limit. Fix the screen size to height 640, a multiple of the default 16 pixel font height, and problem solved. So I'd call this a user bug, but I'm thinking about documenting it for wiki help.
Oh, if you guys want a sample... I can whip one up with the 630 instead of 640 height goof, here:
Code: (Select All)
' Mouse down to row 40 and it throws error 5 because the screen height is 10 pixels too short.
SCREEN _NEWIMAGE(1120, 630, 256) ' Should be 640, not 630.
_DELAY 1
_SCREENMOVE 0, 0
bkgdcolor = 3
PAINT (0, 0), bkgdcolor
GOSUB kybrd
kybrd:
DO
_LIMIT 30
WHILE _MOUSEINPUT: WEND
mx = _MOUSEX
my = _MOUSEY
LOCATE 1, 1: PRINT my; mx; " "; my \ _FONTHEIGHT + 1; mx \ _FONTWIDTH + 1; " ";
hp = SCREEN(my \ _FONTHEIGHT + 1, mx \ _FONTWIDTH + 1, 1) ' Screen read function for color.
b$ = INKEY$
IF b$ = CHR$(27) THEN SYSTEM
LOOP
RETURNNote if you change...
hp = SCREEN(my \ _FONTHEIGHT + 1, mx \ _FONTWIDTH + 1, 1)
to
hp = SCREEN(my \ _FONTHEIGHT, mx \ _FONTWIDTH, 1)
it will just error out when the mouse is moved to the very top of the screen, instead of the bottom. The screen function count starts at 1, while mouse row starts at 0, but the point is unless the height of _NEWIMAGE is a multiple of the _FONTHEIGHT, a user is going to experience this error. Again, just something I thought I'd stick in the wik.
Pete