Background Blip

[richmond62]

Trying to set the backGroundPattern of a rectangular graphic does not work properly (MacOS 12, OXT Lite 1.0.8):
-

Screenshot 2024-10-02 at 16.35.23.png (362.94 KiB) Viewed 5225 times

[tperry2x]

Seems to be the case in LCC 9.x too (on that and some other patterns):

bug.png (26.98 KiB) Viewed 5217 times

(moved to bugs topic)

[richmond62]

Well, while it's great fun to blame the fact that my hand-drill that I inherited from my grandfather does not work because of him
not oiling it properly it does behoove me to get out the WD40 . . .

In fact, as my grandfather died in 1975 blaming anything on him would be extremely cheap.

LC 963 'Community' "died" over 2 years ago (which in the wonderful world of computers is nearly the equivalent of when my grandfather died).

[tperry2x]

Yeah, I'm not saying it's great - or intentional, but it's not an error we created here.
Yes it wants fixing, but your post reads like it's specific to OXT which it isn't.

If I recall, you were in favour of ditching all these metacard compatible icons and patterns at one point as you were trying to save space. A fix would be to create & import an image. Then set that as a background pattern for the time being.

I'll probably eliminate all of these, especially if it turns out some aren't working.

It's certainly better than your normal tone of "feedback" 1 (disgusting icons), 2 (didn't even write that part), 3 (your ethnic minority 'woodpile' comment]... In fact, too many to count.

Although you've reported this in a more constructive way this time, I feel you need to re-read your previous post here and take that into consideration:

...these sorts of posts will send the wrong message at the moment.

Actively pointing out bugs is one thing, but the phrasing you use to do so just sets my teeth on edge.

Coming back to the original point, of blaming what we've inherited - you say that things should have been fixed and point this criticism at the 'livecode faithful', however you could always check if the 'bug' exists in LCC9.x first!

[richmond62]

A fix would be to create & import an image.

I did:
-

Screenshot 2024-10-02 at 19.41.55.png (148.55 KiB) Viewed 5198 times

-
And, frankly, those MetaCard patterns are 'ever so slightly' out-of-date and might have looked good on my Mac LC475 with it 'teeny-tiny' VDU: but not nowadays.

[OpenXTalkPaul]

Exactly! Not about blaming LC Team for pre-existing bugs (hell some these bugs may be so old, they have even been inherited by LC from MC too!), it is about narrowing down a problem to when and where the problem originated so that we can find it and fix it if we can.

Without looking more into this right now (because I can't currently), my guess is that this bug is in the Image Library? Or is there a separate copy of this icon grid thing that's in one of the 'Property Inspector Editor files? Either way these stacks are editable from within the IDE, so feel free to have a look under the hood yourself to see if you can find where.

I did make a few small modifications to the Image Library (which is also the Objects library) stack to allow for drag-drop-to-place objects onto a card, and to be able to create new 'library' stack files again. The handler for making new assets libraries was non-functional, so I guess not many other people besides me have ever uses this thing for their own libraries.

[OpenXTalkPaul]

Make sure your graphic control doesn't have it's opaque property set to false?

I don't have any problem at all on macOS 11 (Big Sur), I'll have to check on Sonoma.
I don't have any mac that's running macOS 12 Monterey.

I'm actually going the other direction and downgraded a repurposed mac to 10.14 Mohave, the last macOS version that can run (and compile) 32bit code. I figure that's probably our best bet for compiling the engine on macOS.

[OpenXTalkPaul]

That last bit should be in compilation section, it's very easy to go off topic here because it's a lot of different things we need/want to work on.

Have you tried compiling the source from previous releases?
I guess 9.7.x was more beta testing than it is release quality, they had just made a release a month prior to dropping 'community'.

Back OT:
The first bit should be in a bug report thread.

I can't image why this pattern-fill selection thing would be a problem with macOS 12 but not on macOS 11?
Did Apple change something related to image decompression or something?
And why exactly was 'prepare image' syntax added by LC around the time of v6.5? Like I've mentioned previously, I've had situations where images look corrupt but then I use 'prepare image' and then the image appears OK. But I have not a clue why nor context for the 'prepare' syntax addition. I've not really looked into it though, since it's only been a problem for me on rare occasions.

[tperry2x]

I can't imagine why this pattern-fill selection thing would be a problem with macOS 12 but not on macOS 11?

I can also replicate this in Linux too, not just MacOS.

[OpenXTalkPaul]

I can't imagine why this pattern-fill selection thing would be a problem with macOS 12 but not on macOS 11?

I can also replicate this in Linux too, not just MacOS.

Oh then I would think the problem must be in an IDE stack.
Maybe I'm not understanding what the issue is?
I don't see this problem but I'm also not using the old revTools as my tools palette.
I can make a Rect. and because I had no swatch colors set, it inherits effective background color, but it also had the new rectangle's opaque property set to false. Once I made it opaque I could set fill and stroke fill-patterns from any of the patterns in the image libraries, no problem (as Windows 3.0 looking as they may be).

Screen Shot 2024-10-12 at 1.03.06 AM.png (200.36 KiB) Viewed 4794 times

No problem with patterns in custom shapes either

Screen Shot 2024-10-12 at 12.58.18 AM.png (425.9 KiB) Viewed 4792 times

[tperry2x]

Yes, setting the fill pattern does work - it's just that some seem to be missing.
It's not in the tools palette, rather the inspector. The same happens in LCC 9.6.3
As per this. Try setting it to id 156. I just think it's missing patterns somewhere, but these are probably only included for metacard/hypercard compatibility.

[OpenXTalkPaul]

Hmm, OK now I'm really confused... how can you pick a pattern in that picker UI if the image isn't there, non-existent?
Does he mean he can't use imageID numbers for certain ancient images that came with MC (and/or HC)? The MetaCard compatibility icons and patterns is what I was using in the screen shots I posted, along with (my modified) HyperCard icons set. But you saying some of these MC images are missing?

I have a stack somewhere that allows to scan number ranges for available images by imageID number, and, then if finds an image with the given number it copies the image's text/data to an image control to view or export the image. I wrote that while trying to figure out how to add better paint brushes to the Paint tools brushes palette, so I could see what imageID slots were empty and therefore suitable for adding some image into the IDE.

I also started to compiled a list of all of the imageID numbers that have been reserved by the IDE for a particular purpose (such as the small & large App Icons, Cursors, etc.).
Here's the ranges listed in the Dictionary entry for 'ID':

1-100: reserved for built-in cursors
101-135: reserved for built-in brush shapes
236-300: reserved for built-in patterns
301-1000: reserved for built-in icons
101,000-103,000: reserved
200,000-299,999: reserved for application use

I was going to insert new Brush shapes into the ID's 136-140, however the IDE already had images in those imageID slots.