@Minuous

My suggestion would be:
Adjust the ReAction macros in reaction/reaction_macros.h to your preferences by prefixing them with proper casting (struct Gadget *).

Last edited by RNS-Amiga-Scientist on 20-Nov-2014 at 08:19 PM.
Last edited by RNS-Amiga-Scientist on 20-Nov-2014 at 08:17 PM.

@Minuous

Quote:

OK, I'm going through the code and adding the hundreds of casts necessary...

Once it's done it's done though...

Quote:

@Trixie: There are situations where there is no suitable OM_GET/OM_SET method available. Eg. to ascertain where the left edge of a gadget is, you need to look at the LeftEdge field in the Gadget structure. (Unless there is some other equally efficient way of doing it of which I am unaware?)

It really depends on the Gadget as some , for example the space.gadget have dedicated attributes for retrieving the RenderBox etc etc

But

GetAttrs(myGagget,GA_Left,&left, etc etc

Ought to work for almost any.

I use the image equivalents IA_Left et al to layout an image manually in my SnakeEyes ProAction example.



Quote:

As a general comment about compiler warnings, just because a particular warning may indicate a real problem, or even definitely indicates a real problem, doesn't mean I want to see the warnings every time I run the compiler, as there are so many that they just scroll out of the window faster than I can read them. (GCC is buggy because it doesn't use stdout correctly, so redirection isn't possible via the "greater than" operator, and the default OS4 console is awful (no scrollbar, no way of logging its output).) It's odd that most of the more important warnings can be turned off but not the less important ones, if anything it should be the other way around

Three things:

1. GCC is not buggy and uses sdtout for standard output and stderr for errors (warnings count as errors in this context).
2. Under AmigaOS4 To redirect stdout >ram:output To redirect stderr *>ram:errorout
3. The new console should be out in FE as far as I understand it
4. The warning in question *is* one of the more important, it's just that in this usage case we know the warning is less critical, but, in a more general case, if you pass a pointer to the wrong type it will often mean the wrong pointer, which may well be catastrophic.

Oh that's 4 things ...

Last edited by broadblues on 21-Nov-2014 at 01:46 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Minuous

Quote:

Minuous wrote: As a general comment about compiler warnings, just because a particular warning may indicate a real problem, or even definitely indicates a real problem, doesn't mean I want to see the warnings every time I run the compiler, as there are so many that they just scroll out of the window faster than I can read them...

That's why you need to go through the code and fix whatever is causing each and every one of those warnings. Otherwise the warnings that are about genuine bugs will get lost in the mass of scrolling.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@itix

Quote:

No, the program design is just fine. If you change struct Gadgey * types to Object * type you get nowhere. It is going to throw warnings when compiled to 68k or MorphOS target so it is completely pointless.

I use Object * arrays in all programs I did/do and never get any RA related warnings about incompatible pointers. If struct Gadget * is really needed for 68k/MOS, I would #define it accordingly.

To me it seems that minous just wants to go the easy way (to circumvent bad design decisions. Nothing really new in Amiga world). As far as I read it, he got the answer he wanted.

@minous

Why on earth do you need the left edge position of a RA gadget? And of which gadget type?

Last edited by whose on 21-Nov-2014 at 01:06 AM.

@whose

For doing custom rendering: the emulator display is a space gadget. It seems there are some other ways of doing it, however they involve passing BOOPSI messages, which would be less efficient.

@Minuous

You should really use Object* for your array. it is the generic Object type. Gadget is more specific. not all objects are gadgets, but all (BOOPSI) gadgets are Objects.

This way your GUI will no long throw warning, but you will get some warnings in the rest of the code. There you can make stub functions for SetGadgetAtts() for example:
mySetGadgetAtts(Object *obj) {
SetGadgetAtts((struct Gadget*)obj);
}

@broadblues

Quote:

I'm not sure why the warnings are only emited for AmigaOS4 SDK, did the include drop a cast, or did the compiler get fussier?

The compiler got fuzzier, yes, but when building a GUI, one should use Object*. C is an obnoxious language. Use (Portabl)E instead

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Minuous

You should be using GetAttr(SPACE_RenderBox)

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@Minuous

I´m a bit confused here... is it just one space.gadget or "hundreds of them"? Because, if it´s just a space.gadget, you could buffer the properties of the space.gadget until a layout change happens. You will get a message about this, e.g. window resizing (AutoDocs).

@whose

Really you shouldn't cache the RenderBox, at least not between more than short batches of drawing operations.

You can as you say get Window resize message etc. but I can guarantee you they won't always come in before you draw into the window borders.

In fact even without cacheing I could only get SketchBlocks window sizeing to work right by creating a custom subclass of render gadget, that could handle the rendering on gadget relayout.

A similar problem exited in AWeb which is why I switched the AmigaOS4 version to Sizeverify (earlier OSversions didn't resize with contents so no issue).

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Deniil715

Quote:

You should really use Object* for your array. it is the generic Object type. Gadget is more specific. not all objects are gadgets, but all (BOOPSI) gadgets are Objects.

Which is why I use an Array of Gadgets for all the Gadgets and an array of Images for all the images, that way the two are never confused.

The fact that NewObject() retuens an Object does not stop you casting that to a specific type of Object ie Gadget when you know what it it. Especially since SetGadgetAtrrs() et al take a pointer Gadget not Object.

You shouldn't snoop inside that struct Gadget (unless you writing a Gadget class) but using the type to help track usage via compiler warnings etc can only be a sensible idea.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@whose

>I´m a bit confused here... is it just one space.gadget or "hundreds of them"?

One space.gadget plus hundreds of other gadgets.

@broadblues

>You shouldn't snoop inside that struct Gadget (unless you writing a Gadget class)

Is that an official guideline? I seem to recall seeing official examples that did so (I will have to check to confirm this though), and I've never read of any prohibition against it.

Last edited by Minuous on 21-Nov-2014 at 04:06 PM.

@Minuous

Quote:

@broadblues >You shouldn't snoop inside that struct Gadget (unless you writing a Gadget class) Is that an official guideline? I seem to recall seeing official examples that did so (I will have to check to confirm this though), and I've never read of any prohibition against it.

No Examples in the SDK do so. You may well have found examples on earlier SDKs but more likely ones dealing with gadtools and earlier GUI types. For Reaction / BOOPSI the gadget should be considered a black and only accessed via the GetAttrs SettAttrs etc functions, particularly when setting an attribute as you can't know what else a high level gadget may be doing when you modify or even Get a value.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

ListBrowserExample.c from the OS3.9 NDK reads a field from the Gadget structure. But anyway I will try to avoid doing so in future if it isn't considered best practice.

@Minuous

Does it? I only have the 3.5 version but I can't see it for looking. For purposes of comparison with the SDK 53.22 version, what line?

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

He may be refering to this:

case IDCMP_GADGETUP:
	gadget = (struct Gadget *)imsg->IAddress;
	IDOS->Printf("Gadget: %ld  Code: %ld\n",
		(LONG)gadget->GadgetID, (LONG)imsg->Code);

Yes, it's the piece of code shown by Gazelle. It's getting the gadget pointer by a slightly different method to how I do it, but it does demonstrate the architectural feature of ReAction that gadgets are implemented as struct Gadget*. Which is a good thing in my opinion; it doesn't needlessly reinvent the wheel but instead extends the basic Intuition gadget functionality in a compatible manner.

Last edited by Minuous on 23-Nov-2014 at 08:00 AM.
Last edited by Minuous on 23-Nov-2014 at 07:59 AM.