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.
After learning how to program it and the modern ways I always use OpenClass() now. For a very simple reason. When ever you give a text label to look up you know it is incurring overhead by looking for it and then opening it as a library.
You wouldn't normally open a library every time you wanted to call a function, you would open it once and cache the library base for calling functions off it. But using NewObject() and passing a class name every time does exactly this, it forces it to do a textual lookup for a library and reopen it under a system lock!
Whatever platform or language I use, I always cache a named resource, for latter use. To minimise overhead and optimise code. It's just good programming practice.
But using NewObject() and passing a class name every time does exactly this, it forces it to do a textual lookup for a library and reopen it under a system lock!
It is even worse. NewObject does not open a library, it only looks through the already opened classes in memory. You have to open the class library anyway, otherwise your program only works if another program ran before and opened all classes you need.
It is even worse. NewObject does not open a library, it only looks through the already opened classes in memory. You have to open the class library anyway, otherwise your program only works if another program ran before and opened all classes you need.
Oh dear. Sounds like a playground for bugs to hide in. Without knowing that would be annoying to figure out. Having OpenClass() is useful. But 68k lacks it so it must be done the harder way.
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/RadeonRX550/SSD240GB/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/RadeonRX550/SSD240GB/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/RadeonRX550/SSD240GB/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
After learning how to program it and the modern ways I always use OpenClass() now. For a very simple reason. When ever you give a text label to look up you know it is incurring overhead by looking for it and then opening it as a library.
You wouldn't normally open a library every time you wanted to call a function, you would open it once and cache the library base for calling functions off it. But using NewObject() and passing a class name every time does exactly this, it forces it to do a textual lookup for a library and reopen it under a system lock!
Whatever platform or language I use, I always cache a named resource, for latter use. To minimise overhead and optimise code. It's just good programming practice.
It is even worse. NewObject does not open a library, it only looks through the already opened classes in memory. You have to open the class library anyway, otherwise your program only works if another program ran before and opened all classes you need.
@thomas
Oh dear. Sounds like a playground for bugs to hide in. Without knowing that would be annoying to figure out. Having OpenClass() is useful. But 68k lacks it so it must be done the harder way.