OpenXTalk Forums

I wanted to see every image ID that gets used by or is reserved by the IDE, so I made this tool stack that can generate a list of IDs in a given range, resolves the chunk/path to the image, and displays a 128x128px preview of the image that's selected from the list. Not as straight forward as one might think. You can also scan for images of a non-srciptOnly mainstacks from the pop-up menu. You can use the arrow-keys to scroll through the list of images, which is interesting because some are ordered frames of an animated sequences.
Plenty of room to make it more robust, do more like scan any substacks of stacks.

a list of IDs in a given range

Isn't there a risk, because you confine yourself to a given range, that you'll miss some images?

richmond62 wrote: ↑Mon Jul 08, 2024 5:09 pm

a list of IDs in a given range

Isn't there a risk, because you confine yourself to a given range, that you'll miss some images?

I was, at least initially, only interested in certain ranges of Image IDs because they're reserved by the IDE and I'm interested in possibly making changes to some or maybe adding a few into any empty slots (like 'smooth' versions of the 'brushes' images) but in order to do that I first need to know if there are any empty 'ID' slots in a particular range.

I added the 'scan selected stack' for images popup menu as an after-thought. That listing method certainly could be more robust. It currently does NOT look into substacks, so that listing certainly will miss any images that are in any substacks of a stack.

One of the limitations of the FIND stack is that it cannot perform an object search:
-

To access details of resources in substacks you will have to open them all so you can search in them.

-

I made a few changes to the original stack, including looking inside substacks of stacks in the stack image lister method.
I kept getting what appeared to be image corruption, but only with certain index color GIF lz compressed images or certain SVG data compiled and placed into an image control. But then manually placing the very same images they looked fine. So I thought that maybe it's my method of copying the data of an image to into a new image and resizing to 128x128px preview. Then I found the syntax 'prepare image tMyImage' which was introduced in 6.0 engine. Using that syntax loads the image into memory first which decompresses and subsequently renders these images properly.