Class Init method vs WindowManager Init method

code
1

Why do many ABC and Accessory templates generate class Init code into the WindowManager.Init method rather than the Init method for the class itself? The most common example is likely the ABC Browse template but I certainly have plenty of Accessory templates that do the same thing.

Having seen few classes without an Init method, I have often wondered if there is a technical or logical reason why WindowManager.Init seems preferred.

2

Please note, the Init method of a class is not a CONSTRUCTOR. It must be called explicitly from somewhere.

Minimal Window procedure skeleton code is as follows

ThisWindow           CLASS(WindowManager)
Init                   PROCEDURE(),BYTE,DERIVED
                     END
  CODE
  GlobalResponse = ThisWindow.Run()                        ! Opens the window and starts an Accept Loop

This is OOP magic, the only procedure CODE is ThisWindow.Run().
Let’s look into WindowManager.Run procedure implementation (ABWINDOW.CLW file)

WindowManager.Run PROCEDURE
  CODE
  IF ~SELF.Init()
    SELF.Ask
  END
  SELF.Kill
  RETURN CHOOSE(SELF.Response=0,RequestCancelled,SELF.Response)

Here we can see explicit call to the Init method. The SELF.Init is the first call in the Run procedure. So, WindowManager.Init virtual method implementation contains the very first code (either generated or embedded) executed in the procedure. It is the best place to init(ialize) WindowManager itself and all the other involved ABC classes. Typically, it is just Init method call (which must be called explicitly from somewhere).

    ThisWindow.Init PROCEDURE
    ReturnValue          BYTE,AUTO
      CODE
      ReturnValue = PARENT.Init()
      SELF.Open(window)                                        ! Open window
      SomeOtherAbcClass.Init(<parameters>)                     ! Init goes here
      RETURN ReturnValue

Personally, I like to use embeditor and see all the consistent procedure initialization code in one place. Otherwice, all the OtherAbcClass.Init methods must be VIRTUAL(DERIVED) to host generated and/or embedded code. This code will be scattered here and there, we’ll have more unnecessary embed points, e.t.c. Overall, it is not a good idea IMHO.

1 Like
3

Okay, I can understand how one would hold that preference. I guess my first inclination is to look in the class init method. For a procedure having several ABC browses, each with multiple AddResetField, AddSortOrder, AddField calls, the Init method call will often be a couple of hundred lines above all those setup calls. This has bitten me more than once over the years as my code added to the Init method gets reset to defaults in the WinMgr.Init.