This is my first usage of aiss images, and it's almost working as expected.
I have a horizonital layout group of five Buttons. Before now they used GA_Text labels and looked normal. To add images I replaced each GA_Text tag with the following:
- BUTTON_RenderImage, IIntuition->NewObject(BitMapClass, NULL,
- BITMAP_Screen, screen,
- BITMAP_Masking, TRUE,
- BITMAP_SourceFile, "tbimages:tapepause",
- BITMAP_SelectSourceFile, "tbimages:tapepause_s",
- BITMAP_DisabledSourceFile, "tbimages:tapepause_g",
Of course, slightly changing the filenames as needed.
You may assume that BitMapClass is properly opened and screen is a valid pointer
to struct Screen.
It works, in that I get all the graphics, but the weird part is that the first button
displays the BitMaps properly, and the next four display the images over a black
background instead of the usual grey scaled background.
I tried combinations, looked for differences, apparently I'm just missing it.
I have reviewed the code others have posted for loading AISS images, did not
see a significant difference. I have viewed the images in Multiview and they
are all properly grey there.
I'm just hoping someone has seen this and can suggest a fix.
I have an image available, but it's not hosted.. :(
Don't know if the following would affect it but I notice you call NewObject() directly instead of using BITMAP_GetClass(). (Which was depreciated somehow in V52.) Although you supply a BitMapClass how is generated? According to the API passing a class pointer is only for private classes. Is your BitMapClass a private class? Doesn't seem like it. :-)
From NewObject() API:
You specify a class either as a pointer (for a private class) or
by its ID string (for public classes). If the class pointer
is NULL, then the classID is used.
I believe the document you are quoting was written about the same time as the Reaction macros.
At one time that was considered easier, but it carries a lot of unnecessary overhead.
I open each class once as part of my startup routine.
I open libraries and devices there as well.
This lets me gather all the "housekeeping" into a single OpenAll(), and close
with a CloseAll() later, which cuts down on clutter in main();
It should also improve performance, as each Class is opened once for the
life of the executable, instead of once per Instance of bitmap, or button,
or layout etc.
If my understanding is not correct, I hope someone will reply with better info.
Your understanding is correct.
However, your description says that the first button shows correctly but the second and third and so on doesn't. For me this implies that you need at least two buttons for the problem to show. But your excerpt only shows one button. So it should be obvious that your mistake cannot be in this part of the code.
I would make some macros like these:
Then I can define my tool bar like this:
And I am sure that all buttons are defined in the same way.
They are transparant on a grey background. The images are actually black in the transparent areas, so that suggests an isue with masking.
Can you post the actual code that isn't working? That way we can spot the error.
Aslo note button.gadget will not dispose of your image, and in your example you don't save a pointer it. So you will have no way of disposing of it.
Do you have BUTTON_Transparent,TRUE set?
How I handle images and buttons
The images are added to an array of pointers. (named using an enum)
Adding to button:
The above provides a text fall back if the button doesn't load. Means SketchBlock can carry on even it the wrong version of AISS is installed.
The button it's self is cleaned up by the layout.gadget it's attached too when the window is disposed of, the images are disposed later:
IN the above dispsosing the window cleans up all gadgets then the for loop cleans up alol the images.
Thanks to all..
As this is my first attempt at using aiss, or any images in gadgets, it's all quite helpful.
As my first attempt, I had not yet got around to handling a fallback in case the aiss image did not load, etc..
regarding the freeing of images, it does seem a bit surprising that _most_ of the GUI objects will self-dispose, but Images do not.
Again, big thanks for all the help.. As soon as I get a chance, I'll try to build up a complete framework for image handling.
I actually agree with your method here and would prefer to do it the same way myself. I only pointed it out as the API seeemd to be saying otherwise. It would be more efficient to pass a pointer than a string used to reopen a class anyway. I suppose passing a string seems safer. You can ofcourse then implement your own macros based on your pointer which would run more optimised. :-)
Gadgets are (usually) unique whereas Images can often be shared (between two windows in the sam app forexample), so it doesn't make sense for a gadget to autodispose it's image (unless it created it itself internally)
I'm glad you like it, but I can not take credit.
I learned a great deal from reading Trixies reaction guide on this website.
It made a lot of things easier to understand. HIghly recommended.
Thanks for your help. I have a working framework now and my apps will look better for it.
The guide you've linked above is Jim Tubbs' guide, not mine :-) I've only written the tutorial.
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
Has this issue with BITMAP_Masking been solved/confirmed? I seem to have an issue consisting in, that the exact same image loaded from different locations yield differences in masking abilities. It would be wonderful if these could somehow resolve.
Sadly, I cannot remember.
I'm sure my original issue was for Score, and the gadget graphics there are all good now, but the details of then vs now are forgotten.
Getting old sucks, but NOT getting old sucks even more.
Sure, staying healthy is the only option ;).
The issue I'm pressing, is the fact that
string imagePath = "tbimages:" + iconName;
yields an icon with masking, whereas
string imagePath = "Icons/" + iconName;
(refering in this instance to the exact same file just placed differently) yields an icon without.
The entire code snippet:
Are you 100% sure the file is the same? Load it inot MultiView(er) and test if both locatsions have an alpha channel.
As secondary comment, why are you doing strdup(somestring.c_str()) all over the place? Surely the result string.c_str() is not going out of scope so need to dup it. Using strdup() without saving the result and free()ing it will be leeking memory?
The files are 100% identical. I confirm this by running
diff tbimages:file Icons/file
The reason I am running strdup is, that apparently there are problems with CopyText attributes in some classes. I know it is probably unnecessary in some cases, but for generic purposes it has just been added all over the place. To remedy the memory loss, I am going to add some kind of garbage collection to avoid having to keep track of the excess strings.
I think only ListBrowser has that CopyText issue, in the case above the text does not need to persist and is not copied.
I would think if where you do need text to persist beyond the function scope you would be better altering the scope of your string object? Would seem more C++ in style.
WRT to the original point of images rendering without alpha, may be run Snoopy whilst starting the app with the tbimages: and the local paths and see if any obvious anomalies show up. The path shouldn't make any difference and doesn't in any of my own apps, so something odd is going on.
I think, that there is definitely a better way to handle string transfers in this context. I just haven't gotten to the point, where I want the perfection of that aspect to guide my transactions in coding space.
I am not too much of a fan of Snoopy. It doesn't strike me as the good solution to snoop around in system calls to solve coding issues. My theory is, that to solve a coding issue, you need to think conceptually rather than try and keep track of the procedures. It has actually helped me get past some real issues, so I think I am gonna stick to that theory for the time being.
Best of all.