DoGadgetMethod() not talking to my object

Have a question about our Software Developer Kit? Ask them here.
User avatar
gonegahgah
Posts: 43
Joined: Fri May 31, 2013 4:22 pm

DoGadgetMethod() not talking to my object

Post by gonegahgah »

I was using IDoMethod() orginally.
I've now changed my code over to using DoGadgetMethod() to start utilising a GInfo but for some reason the change isn't working?

The following works:

Object *pOver = (Object *)
cb->cb_IIntuition->IDoMethodA((Object *) pWindow->UserData,
(Msg) &rOverTestMsg.MethodID);


but the following doesn’t:

Object *pOver = (Object *)
cb->cb_IIntuition->DoGadgetMethodA((struct Gadget *) pWindow->UserData,
pWindow, NULL, (Msg) &rOverTestMsg.MethodID);

The later doesn’t send any message to my Window object at all?
It’s as though the command isn’t even done. Am I doing something wrong?

Here is some further detail:

pWindow->UserData // Currently I store a back pointer to the Window Object here.
This is so that my MouseZone commodity can call the related Window Object which is the purpose of the above calls.
The window object is of type “zone.window” which is just “group.zone”–>”zone.class” adapted over “window.class”.

pWindow // is the corresponding window.

I’ve intialised rOverTestMsg before the call as:

struct zpOverTest rOverTestMsg =
{
ZM_OVERTEST,
NULL, // where GInfo is to be put by DoGadgetMethod().
{
iMouseX, // int16 iMouseX
iMouseY, // int16 iMouseY
}
};


Could anyone help me with what might be wrong?
User avatar
salass00
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 530
Joined: Sat Jun 18, 2011 3:12 pm
Location: Finland
Contact:

Re: DoGadgetMethod() not talking to my object

Post by salass00 »

Are your classes subclasses of gadgetclass? I don't think DoGadgetMethod() will work if they are not.
User avatar
gonegahgah
Posts: 43
Joined: Fri May 31, 2013 4:22 pm

Re: DoGadgetMethod() not talking to my object

Post by gonegahgah »

Hi salass. I was wondering something along similar lines but how would DoGadgetMethod() know what type of class you are providing it with? The only flag I can see is CLF_INLIST.

In the SDK docs it says:

"You should use this function for BOOPSI gadgets , or for 'models' which propogate information to gadgets."

The later aren't gadgets either?

The full lineage of my "zone.window" class is: group.zone->zone.class->window.class->rootclass.
The lineage of "modelclass" is: modelclass->icclass->rootclass.
The lineage of "gadgetclass" of course is: gadgetclass->rootclass.

How would DoGadgetMethod() reject my class if it is doing that?
User avatar
salass00
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 530
Joined: Sat Jun 18, 2011 3:12 pm
Location: Finland
Contact:

Re: DoGadgetMethod() not talking to my object

Post by salass00 »

All objects created from gadgetclass subclasses contain a struct Gadget at the beginning (rootclass uses negative offsets for it's class data so that this is possible). This is why it's legal to cast them to (struct Gadget *) to use with functions like DoGadgetMethod() and SetGadgetAttrs().

The reference to "models" might be something that was simply left in by mistake as the text was copy/pasted from SetGadgetAttrs() description as AFAICT DoGadgetMethod() only works with gadgets.
User avatar
gonegahgah
Posts: 43
Joined: Fri May 31, 2013 4:22 pm

Re: DoGadgetMethod() not talking to my object

Post by gonegahgah »

Cool, I know about the negative offset of rootclass aspect.

I am curious how it decides it is dealing with a gadget.
The only other thing I can see that it might test for is GTYP_CUSTOMGADGET - to make sure it is a BOOPSI gadget instead of a legacy gadget.

I'm curious why it would need to exclude non-gadgetclass based objects. Is there a reason?
If we are using BOOPSI we should already know not to send BOOPSI commands to non-BOOPSI gadgets?

I can test this out easily though so I will go test it.
I'll try it as: group.zone->zone.class->window.class->gadgetclass->rootclass
If it begins to talk to my object I'll be able to confirm what you're saying.
User avatar
gonegahgah
Posts: 43
Joined: Fri May 31, 2013 4:22 pm

Re: DoGadgetMethod() not talking to my object

Post by gonegahgah »

I've done that now and it works... So I think you are absolutely correct.

Hmm, but I don't want to have a gadgetclass wedged into my class that does nothing except make DoGadgetMethod() work!

Is there a reason why there has to be a gadgetclass present?
If there isn't; may I submit this as a bug?

Alternatively, could a:
....DoGInfoMethodA(Object *pObject, struct Window *pWindow, struct Requester *pRequester, Msg pMsg)
command be added to allow GInfo added calls to be passed to non-gadget BOOPSI objects?
User avatar
thomasrapp
Posts: 310
Joined: Sat Jun 18, 2011 11:22 pm

Re: DoGadgetMethod() not talking to my object

Post by thomasrapp »

An ObtainGadgetInfo(Window,Requester) / ReleaseGadgetInfo(GInfo) function pair would be more convenient.

The other question is, why do you need a GadgetInfo if you don't implement a gadget?
User avatar
Rigo
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 360
Joined: Mon Jan 17, 2011 9:42 pm

Re: DoGadgetMethod() not talking to my object

Post by Rigo »

Above all, I think the clue is in the name: DoGADGETMethod - which would definitely suggest that a method for a gadget should be performed.

I see no bug here, except perhaps to add bloat clarification to the Autodoc that this function call is for GADGETS only :)

Simon
User avatar
gonegahgah
Posts: 43
Joined: Fri May 31, 2013 4:22 pm

Re: DoGadgetMethod() not talking to my object

Post by gonegahgah »

Hi thomas,

I'm implementing a zone.class and move.class and derivatives and thought I may as well conform with the system convention of utilising GInfo for objects that are interacted with.
I could go all the way and base all the zone.class classes upon gadget class but the gadget structure isn't necessary for the zone side of things.
But zones and gadgets can be easily married also when desired.

I put a complement.zone over a button.gadget and this works. I also put a pointer.zone over a string.gadget and that works as well (but only when a window is active sadly).
You can put both a complement.zone and a pointer.zone over the same gadget and that will work too.
So zones can certainly work in with gadgets when its wanted so I thought it would be nice to pass the same information as gadgets use.

The primary differences between zones and gadgets is that zones don't have to be clicked. They respond to the mouse being over them and can operate even when a window is inactive (except for pointer.zone presently).

Your suggestion would certainly work just as well. Does anyone know of a special purpose for the GInfo that they should only be used by gadgets?

I've been implementing the zone.class as separate from gadgetclass because zones don't have to be gadgets and obviously gadgets don't have to be zones.
The OS team may prefer otherwise once I get my old code redone to where it needs to be.

There have been a few additions already to the OS since I used it back in the OS3.5 days.
- I like the new OpenClass() which is better than the work-a-round I was using.
- I like the new libraries and find them more understandable than the old approach thanks to the help I was given.
- I like the new DoGadgetMethod() except I have to make my zone.window a gadget to use it.
- Reaction may even have been improved in a fashion I can now use.

I'm not sure if Reaction wasn't always useable and I just didn't realise it.
All I can remember is that I had rejected it way back then; but now I find it can work with what I am doing.

The system has certainly grown in ways that I find very useful.

For the time being I'll make my zone.window class have a gadgetclass as its base class so that I can communicate through it to the zones using DoGadgetMethod().
The zones still won't have to be gadgetclass based as the zone.window will simply pass on the already converted message.

If your solution were provided I would certainly use that; unless there is a specific reason why only gadgets should use the GadgetInfo struct?
User avatar
gonegahgah
Posts: 43
Joined: Fri May 31, 2013 4:22 pm

Re: DoGadgetMethod() not talking to my object

Post by gonegahgah »

Hi Simon,

The main purpose of DoGadgetMethod() is to create a GInfo structure and place that into the Msg isn't it?
I'm guessing that perhaps other code could have also been put in to DoGadgetMethod() to handle standard functions on legacy gadgets maybe?
That would certainly hamper making it more generalised.

Lol. Actually, the AutoDocs presently mention that it can be used for gadgets and for other things.
ie. "You should use this function for BOOPSI gadget objects, or for "models" which propagate information to gadgets.

salass mentioned that this may just have been copied from SetGadgetAttrs() and accidentally left in by mistake.
So the bloat is already there and just probably needs to be amended or removed ;) .

I also read in the autodocs:
Same as the IDoMethodA() function but provides context information and arbitration for classes which implement custom Intuition gadgets.
I imagine the arbitration is via the ObtainGIRPort()? Is this arbitration the reason that it is aimed at gadgets?
Wouldn't that arbitration also be useful to me when I'm calling zones that may also be gadgets?
Post Reply