Our legacy application has a couple hundred references to backcolor in objects or bitmapbackcolor in menus set to 141454956. This isn't a legitimate RGB value, but I know in the past PB has had special values for special colors. This setting is currently causing the IDE to crash when opening some of the objects with this value set. Has anyone else experienced this issue? Now that I've discovered this, the fix/workaround seems to be fairly easy by editing the source, but wondering why this should be occurring now.
- You are here:
- Home
- Q&A
- Q&A
- PowerBuilder
- Backcolor = 141454956 Causing PB2022 IDE crash when editing object
- Jim Reese
- PowerBuilder
- Monday, 17 July 2023 16:18 PM UTC
Accepted Answer
- Tuesday, 25 July 2023 15:56 PM UTC
- PowerBuilder
- # Permalink
A colleague of mine who's been here much longer than I tracked it down in the old source code management system I don't have access to, a consultant in 2013 during an application beautification effort accidentally added the '6' at the end of the intended value, probably doing mass source code edits. So it's been like this for almost 10 years in 89 objects, 393 occurrences. Another 677 objects have the correct value. (thanks Roland/PBSearch).
Comment
There are no comments made yet.
- Monday, 17 July 2023 17:02 PM UTC
- PowerBuilder
- # 1
Great find and great question! I'd recommend reporting it as a bug on https://www.appeon.com/standardsupport/newbug?check_logged_in=1
regards
Comment
- Miguel Leeuwe
- Monday, 17 July 2023 17:26 PM UTC
LOL, I don't know, what I do know is that PB is crashing quite a bit more lately. Used to be a lot stabler in PB 2017
-
Helpful Loading... Helpful 0
- Roland Smith
- Monday, 17 July 2023 17:32 PM UTC
My guess is the number is too large and causing the variable in the C++ code to wrap around to negative which then causes an error calculating the RGB value.
-
Helpful Loading... Helpful 2
- John Fauss
- Monday, 17 July 2023 18:29 PM UTC
The "special" colors that PB has names for (such as "ButtonFace", "WindowBackground" and "Transparent" all have non-zero bits in the high-order byte (above the encoded RGB value) of an unsignedlong color value, resulting in decimal values for these colors in excess of 16,777,215 (0x00FFFFFF), so there is not a restriction per se for a color value being too large.
Most (but not all) of the values of these named colors utilize 0x08 in the high-order byte, and 141454956 is 0x086e6e6c, which does not match any recognized named color, by the way.
My guess is that beginning in PB 2022, color values are now being validated at some point. If this is the case, however, an exception or other run-time error should be thrown instead of crashing the IDE/app.
Most (but not all) of the values of these named colors utilize 0x08 in the high-order byte, and 141454956 is 0x086e6e6c, which does not match any recognized named color, by the way.
My guess is that beginning in PB 2022, color values are now being validated at some point. If this is the case, however, an exception or other run-time error should be thrown instead of crashing the IDE/app.
-
Helpful Loading... Helpful 1
There are no comments made yet.
- Page :
- 1
There are no replies made for this question yet.
However, you are not allowed to reply to this question.
However, you are not allowed to reply to this question.
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here. Register Here »