GadgetRender and FreeGadgets

[FirstNE]

Hi all - I'm having a big issue with these two items. I have buttons in which I supply a custom image. I do a CreateContext, make the gadgets, and then FreeGadgets in the glist. The program crashes inside the FreeGadgets function call (80000004) If I remove the GadgetRender the list of gadgets gets freed properly and the program exists gracefully. Does anyone have a simple example that works? I found online a simple window with a couple of gadets, but as soon as I add the GadgetRender to a button I see the same crashing behavior. In any case the buttons function like they are supposed to.

[thomas]

You found the solution already. Everything created by gadtools.library is a black box. You must not change it. If you change it anyway you have to change it back before you return it to the library.

[FirstNE]

So are you saying that before I do the FreeGadgets call I should make gad->GadgetRender=NULL? mmm, I will have to give it a try.

Edit: WOW! this actually worked. I'm not sure why it should - but hey it does. Thank you for the hint.

[thomas]

Originally Posted by FirstNE

before I do the FreeGadgets call I should make gad->GadgetRender=NULL?

No, you should set it back to what it was before you poked the image pointer into it. If you don't you might leak memory.

[FirstNE]

I guess I'm not following then. When I create the gadget (that is after the call to gad = CreateGadget) it returns a pointer to the gadget. I then set the gad->GadgetRender to the image. The image and all it's data are structures, not pointers... so there is no memory to free. I presume that the GadgetRender was NULL before I set it to point to the image data. Maybe that's a BIG presume? I will have to check and see what it is before I set the image. Thanks!

[thomas]

Originally Posted by FirstNE

I then set the gad->GadgetRender to the image.

Yes, but it has a GadgetRender already, allocated by the library. Apparently FreeGadgets tries to free that memory. By setting it to NULL you unlink the memory, so that FreeGadgets cannot free it. You have to put the old GadgetRender pointer back which was there before you put the image pointer in.

Actually what you do is illegal. As already mentioned what CreateGadget returns should be considered a black box. An object of a class. Private data. Which may only be changed by GT_SetGadgetAttrs.

gadtools.library is only a thin cover over the "old style" to make gadgets. It looks like an object oriented approach, but technically it just allocates memory areas and uses the existing pointers to link them together. It relies on that these pointers remain unchanged. If you overwrite pointers, you confuse the library.

If you want a real object oriented approach you should move over to BOOPSI resp. ClassAct a.k.a. ReAction.

Or step back to the old style and allocate the image buttons yourself. gadtools.library is able to distinct between gadtools-allocated gadgets and other ones, so it is safe to mix them.

[FirstNE]

Great explanation! Thank you. Later on in my code I change the image using the GT_Set GadgetAttrs. I will have to ponder which direction to go. I have not been in the Amiga circles for a long time and I see that there are various (it seems to me) different directions the development of the OS is going. I've been using V37 of the OS, but I see now that there is at least a V50 and new OSes as well (AROS?). I will probably step back as you suggest. I have developer conference notes from 1990 in which BOOPSI is kind of discussed, but I never actually got into developing software using it. Guess I'll have to do some research. It's kind of exciting to see on ancient OS being updated. I still wonder at (sophisticated) programs that take less than 880K whereas on modern OSes it takes megabytes. Many, many thanks for the insights you provided.

[thomas]

Originally Posted by FirstNE

I've been using V37 of the OS, but I see now that there is at least a V50 and new OSes as well (AROS?).

V50 and above is what they call "next generation". De-facto it is a different platform. Amiga OS 4 and MorphOS require a PowerPC CPU and AROS an x86 CPU. They have different compatibility layers to be able to execute 68k software through emulation.

"The" Amiga which is now called "classic" had a break at V40 (OS 3.1), was then developed to V44 (OS 3.5) and V45 (OS 3.9), but this branch is lost, so they stepped back to OS 3.1 and developed V46 (OS 3.1.4) and V47 (OS 3.2).

[FirstNE]

Wow! I *have* been out of the loop for a while. So I guess I will stick to V37... I want backward compatibility. I actually do still have a CD-ROM that offers Motif for Amiga. I used to program a *lot* professionally in Motif - not for the Amiga but for the Unix/Linux OSes.

Thanks for the history lesson.