Yes. Unterminated Macro Call errors usually happen because of MUI/Reaction macros being defined like this:
#define WindowObject NewObject( WINDOW_GetClass(), NULL
As can be seen the closing bracket for NewObject is missing. This will be added when taglist is closed with End or TAG_DONE). When the vararg function NewObject itself is defined as macro (inline stdarg) it causes the error because of the way and order macro expansion is done, obviously.
So this macros only work if NewObject itself is not a macro == when not using inline stdarg.
AROS defines macros like WindowObject in a different way - with no missing close bracket - and to be able to do that it requires some more magic for the "End" macro. This way it works even if the vararg function NewObject is a macro, too. A disadvantage would be that it can clash if two libs' includes are used which both use the "End" macro. Like popupmenu + MUI. Then even more magic would be needed for the "End" macro to figure out if it is a MUI call, or a popupmenucall.
#define MUIOBJMACRO_START(class) (IPTR) \
({ \
ClassID __class = (ClassID) class; \
enum { __ismuiobjmacro = 1 }; \
IPTR __tags[] = {0
#define BOOPSIOBJMACRO_START(class) (IPTR) \
({ \
Class *__class = (Class *) class; \
enum { __ismuiobjmacro = 0 }; \
IPTR __tags[] = {0
#define OBJMACRO_END \
TAG_DONE}; \
( \
__ismuiobjmacro \
? MUI_NewObjectA((ClassID)__class, (struct TagItem *)(__tags + 1)) \
: NewObjectA((Class *)__class, NULL, (struct TagItem *)(__tags + 1)) \
); \
})
#define End OBJMACRO_END
#define WindowObject MUIOBJMACRO_START(MUIC_Window)
