What is the difference between opening a window using IIntuition->OpenWindowTags and using IIntuition->IDoMethod(win, WM_OPEN)? In the AutoDocs for the latter, it says "Don't use this function unless you're a class implementor", but yet this is what the SDK example section suggests to do in the LB_Example (SDK:Examples/ReAction/os4examples/ListBrowser/LB_Example).
I know we need an window.class object (with NewObject()) for IDoMethod, and a few tags for OpenWindowTags, so I know they aren't directly interchangeable.
I don't know where you found this. WM_OPEN is the only way to open a window when using ReAction or ClassAct as GUI engine. Ususlly you hide it behind the RA_OpenWindow macro.
OpenWindow/Tags is a lower programming level. WM_OPEN internally uses OpenWindow to actually open the window with the attributes stored in the object.
@jaokim
From the viewpoint of the programmer, there are two kinds of window in Intuition. The "classic" window is opened through OpenWindowTags() and ultimately closed with CloseWindow(). The "BOOPSI" (or "ReAction", or "object") window is created through NewObject() and opened/closed via the Window Class methods WM_OPEN and WM_CLOSE, respectively. Do not mix up the classic API with the object-oriented API!
Functions from the classic Intuition API, related to windows:
OpenWindowTags()
CloseWindow()
SetWindowAttrs()
GetWindowAttrs()
SetWindowTitles()
SetWindowPointer()
Functions from the BOOPSI/ReAction API (universal - for all objects, not just windows):
NewObject()
DisposeObject()
GetAttrs()
SetAttrs()
IDoMethod()
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
Hello everyone, I'm beginning Amiga programming and this is my first post here :)
I am also curious about the notes on the IDoMethod() autodoc:
For what I've seen we ARE supposed to use it when using BOOPSI/ReAction API, so maybe the autodoc is outdated?
And also, what is "BOOPSI reentrancy protection"?
I see the exact same note on the following functions:
The autodocs are brand new, older versions didn't have this note.
I've written many ReAction programs and I never needed this function unless I called some custom methods I invented myself (i.e. as a class implementor).
So why do you think you need to use this function in your programs?
All public methods can be called by individual functions (SetAttrs, GetAttr, RefreshGList etc.) or macros (RA_OpenWindow, RA_CloseWindow, RA_Iconify, RA_Uniconify etc.)
Hello Thomas
Well other than IDoMethod() I don't think I need to use any of the other ones I mentioned... I mean I don't even yet fully understand what they do, I'm in the process of learning how to use ReAction to build a GUI.
My question is because as I understand we have 2 options: Use the macros or call IDoMethod() directly. Now the macro (in this case, RA_OpenWindow) is defined as a call to IDoMethod() so in the end we are calling that function. I guess the macros are just a convenience then?
I was just wondering why the note says what it says, for example about BOOPSI reentrancy protection... maybe I don't need to worry about it at all but I honestly don't understand what that protection means.
Thanks!
@thomas
You did - the RA_ macros in fact use IDoMethod(); just look at the window.class include file :-)
But yes, the note about not using IDoMethod() other than for class implementation should be explained. I've been wondering about it myself but never asked.
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
Knowing what the macro resolves to does not change the fact that you never need to call this function explicitely in a program.
The only deficit is that the window.class autodoc does not mention the macros. You only find them in examples.
@thomas
Fair enough. So how do you open ReAction windows in your programs?
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
Object *winobj;
struct Window *window;
winobj = WindowObject,
...
EndObject;
window = RA_OpenWindow (winobj);
@thomas
It's not a deficit, it's done on purpose: the ReAction macros are being phased out. Various examples contain macros because that's how things were supposed to be done in the past. The macros are ClassAct legacy and employ certain practices that have been deprecated in OS4. I've tried to explain that in this article.
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
Ok, then Bender is right and the note should be removed from the autodocs for IDoMethod. (Not for the other functions, though).
IMHO not everything in OS4 is good and not everything declared as "deprecated" by only a few developers deserves to be given up. There are surely better ways to improve an operating system than to tell programmers that everything they did before was bad.
@thomas
Before we jump to conclusions, I'd still like to hear an explanation from the "official quarters", ie. from Rigo or ssolie.
Thomas, you seem to be missing the point. It's not about "a few developers" randomly deciding about this or that. The changes I've described in my article are part of an effort to better integrate ReAction with Intuition and provide a more consistent GUI programming framework.
As you know, ReAction was adopted in AmigaOS as a third-party product, and as such it had its specifics. One of them was the XYZ_GetClass() function that retrieves the class pointer and that had to be implemented as part of the class. But other BOOPSI classes do not need such a function, which leads to inconsistency. This is why Intuition got the OpenClass() function that can be used to open any BOOPSI class (and retrieve its pointer), whether it comes from the original ReAction set or not.
As for the macros, the reason is similar. When creating a BOOPSI-based GUI you construct a layout that can mix and match various classes. Now if we went on and promoted the use of the macros, some objects ("the ReAction ones") in the layout would be created via macros while others (those that are not part of the ReAction set) would call NewObject() directly. How do we explain this inconsistent mess to new programmers? Shall we tell them a story about ReAction having been, unce upon a time, something different that should also be treated differently?
No, I think not. ReAction is now part of the Intuition/BOOPSI framework so historical inconsistencies should be rid of. The same things should be treated the same.
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
You are looking so much into details that you miss the view of the whole thing.
For example GetClass(). You are the first in this thread who mentions it. Why? Because you removed the macros. A macro approach is usually choosen to hide certain implementation details the programmer should not need to know about.
Did you even have a look at the example I gave you last week? You won't find the word GetClass in the source code, not even once.
So if you think that GetClass() is evil, you just need to change the macros and nobody will use it any more.
There are no macros for existing BOOPSI classes? Really? Look at reaction/reaction_macros.h, there are macros for ColorWheel and GradientSlider objects. What hinders you to add macros for frbutton, propgclass and so on, too?
While we are at it, I would move the class-specific macros into the class-specific include files and eliminate reaction/reaction.h completely. If I'm not wong the only common macro is EndObject. It could be moved to intuition/classusr.h or somewhere else. This would be one step towards integration.
However, the first step of integration would be of technical nature: make BOOPSI and ReAction classes work together.
- make builtin BOOPSI classes properly support GM_DOMAIN as used by layout.gadget.
- make layout.gadget use SetAttrs to change an object's size and don't poke directly into the gadget structure.
These two minor changes would immediately make frbutton objects work with layout.gadget and render button.gadget almost useless. Oh wonder! *This* is what *I* call integration.
Look into my textgclass example and show me the inconsistency. It creates a new BOOPSI class and integrates it into a ReAction GUI. It does not have GetClass() function and it does not have a public name, either. But it has a macro which hides these details and make it look like all the other GUI objects.
"Macros are evil" is not the right way to integrate.
@bender
The note on reentrancy is there because of the way Intuition is designed. It all has to do with context. See wikipedia regarding what reentrancy is.
When you create a GUI object (instantiate a class) you own that GUI element and it exists only in your context (Task/Process). The NewObject() function is used to create these objects.
In this case, you are creating a window.class object. That object is only under your control and there are no reentrancy problems. You can change things with SetAttrs() and not worry at all about reentrancy.
As soon as you open that window (e.g. IIntuition->IDoMethod(WM_OPEN)) then you have essentially passed control over to Intuition. Intuition uses the input.device to handle input and perform rendering. That is a different context from the one you are running on. From this point on, you can have possible problems with reentrancy.
Now take a look at DoGadgetMethod(). That function has protection against input.device trampling on your context and vice versa. The problem is, it only works for gadgetclass objects. So you are left with no choice but to use IDoMethod() to invoke methods on window.class objects. That is OK because internally, window.class is designed to be used this way. You will also find all the examples in the SDK use IDoMethod() as well.
We are working on documenting window.class based GUIs as well as why you should avoid using the macros. The official place for all such reference documentation is http://wiki.amigaos.net
The autodocs and includes only get you so far. That is why the RKRMs exist. The good old RKRMs are now back but in wiki form.
@ssolie
Thank you very much for the detailed explanation! :)
It's a pity won't make it to AmiWest this year... I hope you guys have a great programming seminar and I'll be looking forward for any video or posts that may come out of that.