Reaction first encounter

I'm trying to get into reaction, and my first test
is this:

http://dl.dropbox.com/u/5482530/Code%20examples/reaction/test.c

I'm curious to know, what I am doing wrong here. The button never reacts to input, and printf("hello world\n"); is never called. What am I doing wrong???

@alfkil

You need to add "GA_RelVerify, TRUE" to the button attributes so that the event loop detects the hit.

Simon

@Rigo

Thanks!

@alfkil
Make sure to reference the SDK examples. There are all sorts of weird things like GA_RelVerify, TRUE when doing BOOPSI code and they may save you a lot of time.

@ssolie

I had managed to copy my example code from probably the only SDK example that doesn't define GA_RelVerify for a button...

Does anyone have a small, tangible example of how to use the reaction requester class ??

@alfkil

@alfkil

Quote:

Edit: afxgroup was faster.

@afxgroup & TSK

Brilliant, thanks

Now, say I want to retrieve the string from a REQTYPE_STRING requester, how do I do that??

EDIT: Ok, it turns out I just have to use REQS_Buffer. Got it.

@alfkil



didn't test it but should work..

@alfkil, afxgroup, TSK

REQUESTER_GetClass() is deprecated as of V52, it is advised to use the public class ID instead:

reqobj = IIntuition->NewObject(NULL, "requester.class",
REQ_Type, REQTYPE_INFO,
REQ_TitleText, "Message",
REQ_BodyText, "Hello world",
REQ_GadgetText, "_OK",
TAG_END);

@afxgroup

Quote:
It should but it's better practice to always use IIntuition->GetAttr() to obtain BOOPSI object attributes:

uint32 buffertext;

IIntuition->GetAttr(REQS_Buffer, reqobj, &buffertext);
printf("buffer is %s\n", (char *)buffertext);

@alfkil

Could you publish your final version, taking the above remarks into account?

@trixie

If you use that method you should keep in mind that libraauto won't take care of opening requester.class for you, but instead you have to do this yourself manually and there won't be a linker error if you don't, only difference will be that your program will fail to work for no apparent reason if requester.class hasn't been loaded into memory by another program before.

@salass00
Quote:
Actually, libraauto.a does absolutely nothing and has been deprecated for a while now. All the auto-lib opening stuff has moved to libauto.a and only there. You can remove any and all references to libraauto. Not all of the classes and libraries are included in libauto.a either. This info is now documented in the SDK as well.

@all
The use of functions like REQUESTER_GetClass() is deprecated because it is 100% redundant. All AmigaOS classes are guaranteed to begin with a struct ClassLibrary so at a minimum you can simply peek into that structure to grab the Class pointer.

The future proof way to use classes (datatypes, images, gadgets, etc.) is to use IIntuition->OpenClass() to open them and IIntuition->CloseClass() to close them. There are very few cases (e.g. intuition.library internal classes and page.gadget) where you actually need to use the string name to obtain the class pointer.

When you do use the string name that means the class must already be loaded if it is a disk-based class. This fact has never changed since BOOPSI was designed.

What has changed is that all BOOPSI classes (including datatypes) have been cleaned up and now begin with a struct ClassLibrary which was not the case before 4.x and thus there was no reliable method of obtaining the Class pointer. This is why you see those #?_GetClass() functions still lingering around. No new classes should provide them.

@ssolie

Thank you for such a detailed technical information, that's very valuable !
That's somehing that would worth to be included in the Migrating guide PDF included in the SDK (or even better in a small new "BOOPSI 4.x quick guide" document)

@ssolie

About the xxx_GetClass() thing: the reaction/reaction_macros.h uses these functions a lot. Will the macros be updated soon?

Marko

Stupid question again: Is there
a way to disable an entire window
the same way as with a gadget?
Like WA_Disabled, TRUE? (I know
this doesn't work).

@alfkil

As far as I know, the concept of a disabled window doesn't really exist in AmigaOS (does it exist in *any* OS?). You may have to do some trickery yourself; maybe something along the lines of reacting on the window getting focus (being activated) and promptly deactivating it again, plus you'd need to keep track of whether a window is currently supposed to be kept "disabled", so you can make it and its gadgets swallow any messages arriving for them between the time it gets activated and the time you are able to deactivate it again (e.g. the mouseclick which activated it in the first place).

Disclaimer: The above is purely theoretical speculation; I've never done anything like this. But this is how I'd plan to attempt to implement it.

Best regards,

Niels

@nbache

Having such behaviour in a window would be highly confusing for the user.

The usual way is to block input to a window by opening an invisible requester attached to it. This can be done very simply by setting the WA_BusyPointer attribute to TRUE on the window.class object.

Simon