A very, very complex issue [ solved ]

3 posts / 0 new
Log in or register to post comments
Last post
Tue, 2021-01-05 17:27
#1
OldFart
OldFart's picture
Offline
Last seen: 3 months 1 week ago
Joined: 2010-11-30 14:09
A very, very complex issue [ solved ]

Hi,

Now, right after resurrecting my X5000, I run into a problem. A real problem for which I hope you can point me in the right direction.

Please bear in mind that it USED to work! Virtually all of my released titles that make use of Reaction on OS4Depot use it. Right before I folded up some 5 years ago and put my X5000 in storage, I changed something and I don't know why, how and what.

An introduction might be in place here for you to grasp the underlying complexity of the problem, as I make use of what I think is a rather sophisticated way of ensuring the necessary classes for a project are opened, by including a '#include'-line for those classes.

  1. #ifndef  MAIN_H
  2. # define MAIN_H
  3.  
  4. # include <interfaces/button.h>
  5. //# include <interfaces/checkbox.h>
  6. //# include <interfaces/chooser.h>
  7. //# include <interfaces/clicktab.h>
  8. //# include <interfaces/colorwheel.h>
  9. //# include <interfaces/datebrowser.h>
  10. //# include <interfaces/fuelgauge.h>
  11. //# include <interfaces/getcolor.h>
  12. # include <interfaces/getfile.h>
  13. //# include <interfaces/getfont.h>
  14. //# include <interfaces/getscreenmode.h>
  15. //# include <interfaces/integer.h>
  16. //# include <interfaces/listbrowser.h>
  17. //# include <interfaces/palette.h>
  18. //# include <interfaces/partition.h>
  19. //# include <interfaces/radiobutton.h>
  20. //# include <interfaces/scroller.h>
  21. //# include <interfaces/sketchboard.h>
  22. //# include <interfaces/slider.h>
  23. //# include <interfaces/space.h>
  24. //# include <interfaces/speedbar.h>
  25. //# include <interfaces/string.h>
  26. //# include <interfaces/texteditor.h>
  27. //# include <interfaces/virtual.h>

File 'main.h' is a physical component of any project and contains project-specific data.

Next is a file called 'Gadgets.h' and here a structure is defined (an array of, actually) and initialised.

  1. struct GadDesc {CONST_STRPTR          gd_Name;
  2.                 UWORD                 gd_Version;
  3.                 UWORD                 gd_Revision;
  4.                 struct ClassLibrary **gd_GadBase;
  5.                        Class        **gd_Class;
  6.                 struct Interface    **gd_IFace;
  7.                 uint32                gd_Failure;
  8.                } GD[] = {
  9. /*
  10. ** --- classes --------------------------------------------------------------------------------------------------------------------------------------
  11. */
  12. # ifdef INTERFACES_AREXX_H
  13.   {     "arexx.class",    ARexxLV,    ARexxLR,      (struct ClassLibrary **)&ARexxBase,     (Class **)&ARexxClass,     (struct Interface **)&IARexx,     (uint32)0},
  14. #  endif
  15.  
  16. #  ifdef INTERFACES_POPUPMENU_H
  17.   { "popupmenu.class",    PopupLV,    PopupLR,      (struct ClassLibrary **)&PopupMenuBase, (Class **)&PopupMenuClass, (struct Interface **)&IPopupMenu, (uint32)0},
  18. #  endif

'Gadgets.h' is NOT physically present in a project, but by means of a link it is virtually present. All of these virtual files reside in 'BlackBox'.

The array of gadget descriptions is fed to a function called 'Open_Gadgets'.

Prototype for that function and it companions:

  1. BOOL    Open_Gadgets(struct GadDesc *);
  2. void    Close_Gadgets(struct GadDesc *);
  3. void    Report_FailedClasses(struct ExecParam *, struct GadDesc *);

The relation between these 3 is actually quite straightforward:

  1.                if (Open_Gadgets(GD))
  2.                 {
  3.                  .
  4.                  .
  5.                  .
  6.                 }
  7.                else
  8.                 {
  9.                  ERROR("Open one or more GadgetClasses");
  10.                  Report_FailedClasses(xn, GD);
  11.                 }
  12.  
  13.                Close_Gadgets(GD);

where the argument 'GD' stands for a pointer to the array mentioned above.

The code for 'Open_Gadgets' is:

  1. BOOL Open_Gadgets(struct GadDesc *GaDe)
  2. {
  3. INFO_ENTER
  4.  BOOL   Success = TRUE;
  5.  
  6.  struct GadDesc *gd = GaDe;
  7.  
  8.  while (gd->gd_Name != NULL)
  9.   {
  10.    if ((*gd->gd_GadBase = IIntuition->OpenClass(gd->gd_Name, 0, gd->gd_Class)) != NULL)
  11.     {
  12.      if ((*(uint32 *)&((struct ClassLibrary *)*gd->gd_GadBase)->cl_Lib.lib_Version) >= (*(uint32 *)&gd->gd_Version))
  13.       {
  14.        if ((*gd->gd_IFace = IExec->GetInterface((struct Library *)*gd->gd_GadBase, "main", 1, NULL)) == NULL)
  15.         {
  16.          Success = FALSE;
  17.          gd->gd_Failure = ERR_NO_INTERFACE;
  18.         }
  19.       }
  20.      else
  21.       {
  22.        Success = FALSE;
  23.        gd->gd_Failure = ERR_LIBVERSION;
  24.       }
  25.     }
  26.    else
  27.     {
  28.      Success = FALSE;
  29.      gd->gd_Failure  = ERR_NO_LIB_FOUND;
  30.     }
  31.  
  32.    gd++;
  33.   }
  34.  
  35. INFO_VACATE
  36.  return Success;
  37. }

This function is, a.o., part of a file which is also virtually present in a project. In ANY of my projects, which use Reaction, a total of 8 files are virtually present. They contain macro's and functions alike that are proven to work properly. Until now, that is.

And now the offending line is the following one, which either gives a compiler warning or error, or a GR at runtime, depending on my efforts to remedy the problem:

  1.    if ((*gd->gd_GadBase = IIntuition->OpenClass(gd->gd_Name, 0, gd->gd_Class)) != NULL)

I know that it is a pointer-issue, but I'm at a loss.

Top
Tue, 2021-01-05 23:41
thomas
thomas's picture
Offline
Last seen: 3 months 1 week ago
Joined: 2011-05-16 14:23
Re: A very, very complex issue

The -> operator is stronger than the * operator. So *gd->gd_GadBase is equal to *(gd->gd_GadBase). This is not what you want. You want (*gd)->gd_GadBase and this is what you need to code. The brackets around *gd are missing.

Edit: no, ignrore that. I didn't look carefully enough to your struct GadDesc. It's a really complicated thing you are building there.

Top
Sun, 2021-01-10 22:52
OldFart
OldFart's picture
Offline
Last seen: 3 months 1 week ago
Joined: 2010-11-30 14:09
Re: A very, very complex issue [ solved ]

After a lot of retyping code and applying all possible combinations of '*' and '&' alike without much success, I finally found the culprit. In the whole of the conversionprocess, many, many moons ago, I thought it a wise decision to eliminate the proto/.... files from the compilation sequence and go directly for the interfaces/.... files instead.

This has consequences for building up and initiating an array of struct LibDesc, quit simmilar to GadDesc, In stead of using
#ifdef INTERFACES_xxx_H
I had to ressort to
#ifdef xxx_INTERFACE_DEF_H
which I *forgot* for the most part. Especially for the intuition library.

Long story short: I can say that it works gain.

Thanks,

OldFart

Top
Log in or register to post comments