I'm afraid no-one has enough free time to rewrite complete sources for you. Why don't you post the actual code of yours, for us to see what you're doing wrong? Perhaps it's something obvious and quick to fix.
And if you are wondering why Jabirulo's GUI definition differs from mine it's because he instantiates his GUI objects using their public class names ("layout.gadget" etc.) whereas I'm using their class pointers. Both are valid ways. My example explicitly opens the individual classes using OpenClass() whereas Jabirulo's (being just a code snippet) assumes that the classes are already open - so bear this in mind!
Both can be used, depending on how you instantiate your GUI later in the program. If you instantiate all your GUI objects from their public name (IIntuition->NewObject(NULL,"chooser.gadget", ...), you don't need a class pointer so OpenLibrary() will be allright because all you need is to have the class and its interface opened. On the other hand, if you instantiate from the class pointer (IIntuition->NewObject(ChooserClass, NULL, ...), you'll need OpenClass() because OpenLibrary() does not provide the class pointer.
Instantiating from the class pointer can be faster, depending on the number of objects and complexity of your GUI. Steven says there's hardly a noticeable difference compared to using the public name; this may be true on his X1000 but on a lowly 600MHz Sam I can definitely tell :-)
Instantiating from the class pointer can be faster, depending on the number of objects and complexity of your GUI. Steven says there's hardly a noticeable difference compared to using the public name; this may be true on his X1000 but on a lowly 600MHz Sam I can definitely tell :-)
Using class pointers also forces you to open the classes before you use them (which is good), while when using class names it can be easy to forget as the compiler won't produce an error if you don't handle this part and might not even cause your compiled program to fail if the classes are already in use by other programs.
I'm afraid no-one has enough free time to rewrite complete sources for you. Why don't you post the actual code of yours, for us to see what you're doing wrong? Perhaps it's something obvious and quick to fix.
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
Thank you trixie.
I looked at sdk\include\... reaction\reaction_macros...
This helped me a little. I will post specific problem i encountered as soon as possibile.
1)Replace 'ButtonObject,' with 'IIntuition->NewObject(NULL, "button.gadget",'
BitMapObject -> "bitmap.image"
WindowObject -> "window.class"
LayoutObject -> "layout.gadget"
2)Replace all the 'xxxEnd,' with 'TAG_END),', note the last tag (semicolon) 'WindowEnd;' -> 'TAG_DONE);'
'VLayoutObject,' -> 'IIntuition->NewObject(NULL, "layout.gadget", LAYOUT_Orientation,LAYOUT_ORIENT_VERT,'
'RA_OpenWindow(win)' -> '(struct Window *)IIntuition->IDoMethod(win, WM_OPEN))'
'RA_HandleInput(win, &code)))' -> 'IIntuition->IDoMethod(win, WM_HANDLEINPUT, &code)))'
and comment out 'reaction/reaction_macros.h' include
Hope it helps.
AOS4.1/SAM460ex/PPC460EX-1155MHZ/2048MB/RadeonHD6570/SSD120GB/DVDRW :-P
@jabirulo
i need this part particularly:
" LAYOUT_AddChild, LayoutObject,
LAYOUT_VertAlignment, LALIGN_CENTER,
LAYOUT_HorizAlignment, LALIGN_CENTER,
LAYOUT_AddChild, OBJ(OBJ_IBUT_1) = ButtonObject,
BUTTON_BevelStyle, BVS_NONE,
BUTTON_Transparent, TRUE,
BUTTON_RenderImage, OBJ(OBJ_SEL) = BitMapObject,
BITMAP_SourceFile, "images/unsel.gif",
BITMAP_DisabledSourceFile, "images/ghosted.gif",
BITMAP_Screen, screen,
BITMAP_Masking, TRUE,
BitMapEnd,
BUTTON_SelectImage, OBJ(OBJ_UNSEL) = BitMapObject,
BITMAP_SourceFile, "images/sel.gif",
BITMAP_Screen, screen,
BITMAP_Masking, TRUE,
BitMapEnd,
ButtonEnd,
CHILD_WeightedWidth, 0,
CHILD_WeightedHeight, 0,
LayoutEnd,"
could you please help me?
@AmigaBlitter
Look at how I do ReAction GUI without macros here in this source code - the main() function there should give you the answer.
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
As previous post:
1)Replaced XXXObject with IIntuition->NewObject(NULL, "Name_Of_The_Object",
2)Replaced XXXEnd with TAG_END
AOS4.1/SAM460ex/PPC460EX-1155MHZ/2048MB/RadeonHD6570/SSD120GB/DVDRW :-P
@AmigaBlitter
And if you are wondering why Jabirulo's GUI definition differs from mine it's because he instantiates his GUI objects using their public class names ("layout.gadget" etc.) whereas I'm using their class pointers. Both are valid ways. My example explicitly opens the individual classes using OpenClass() whereas Jabirulo's (being just a code snippet) assumes that the classes are already open - so bear this in mind!
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
BTW: just a classes load question, how do I open/use chooser.gadget in case I want to use IChooser->AllocChooserNode()?
or do I have to use (or both are valid):
TIA
AOS4.1/SAM460ex/PPC460EX-1155MHZ/2048MB/RadeonHD6570/SSD120GB/DVDRW :-P
@jabirulo
Both can be used, depending on how you instantiate your GUI later in the program. If you instantiate all your GUI objects from their public name (
IIntuition->NewObject(NULL, "chooser.gadget", ...
), you don't need a class pointer so OpenLibrary() will be allright because all you need is to have the class and its interface opened. On the other hand, if you instantiate from the class pointer (IIntuition->NewObject(ChooserClass, NULL, ...
), you'll need OpenClass() because OpenLibrary() does not provide the class pointer.Instantiating from the class pointer can be faster, depending on the number of objects and complexity of your GUI. Steven says there's hardly a noticeable difference compared to using the public name; this may be true on his X1000 but on a lowly 600MHz Sam I can definitely tell :-)
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2
Using class pointers also forces you to open the classes before you use them (which is good), while when using class names it can be easy to forget as the compiler won't produce an error if you don't handle this part and might not even cause your compiled program to fail if the classes are already in use by other programs.
Absolutely!
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2