Clarion Classes with Implemented Interfaces - DLIB

1

last year we reported a problem when compiling classes with Implemented interfaces and was not able to isolate the resulting GPF problems.

After setting up test rigs we were still unable able to replicate the problem.

By accident reviewing the code base created by the Russians called DLIB we noticed some clear statements in the constructors of the classes…

Upon removing the clear(self) statements in the constructor of the classes in which an interface was added the class seemed to stabilize and the interface were suddenly callable.

For anyone using that code base that wish to add functionality by the addition of interfaces checking the code in the constructors is probably a good idea if you run into the problem of the class GPFing when call an interface method…

Probably a good idea to may check all the classes in the source code modules.

TDynaBaseGroupClass.Construct PROCEDURE
    Code   
 ! Clear(Self)
 ! Clear(Self.TmpRef)

  Self.ErrCode = returnerr:Ok
  Self.InitOk = True

  Self.Props &= New(TBaseGroupClassProps)
  Clear(Self.Props)
  Self.FieldsQueue &= New(TFieldsQueue)
  Free(Self.FieldsQueue); Clear(Self.FieldsQueue)
  Self.GroupStack &= New(TGroupStack)
  Free(Self.GroupStack); Clear(Self.GroupStack)
  Self.BeginName = 'GROUP'
  Self.ValidTypes &= New(STRING(ValidTypesCount)); Self.SetValidTypes(True)
2

Upon farther testing could it be that the clarion compiler leaves some pointers to interfaces for a class inside the class group structures. I remember DB saying that at the lowest level classes are just groups…

could it be possible a clear(self) in the constructor of a class somehow interferes with the interface address table of a class.

3

The quick answer - do not use CLEAR(SELF).

If a class instance is not NEWed, do not use the AUTO attribute for the class instance’s declaration. The compiler is generated the call to CLEAR in this case before setting VMTs addresses for the class itself and for interfaces and before invoking the constructor.

If a class instance is NEWed, interfaces’ VMTs are being zeroed by CLEAR. The compiler is smart enough and, if it’s possible, tries to merge VMTs of the class itself and of the first interface. As result, in some cases the NEWed class instance may remain not broken after CLEAR. But you shouldn’t rely on this.

4

Many thanks Also and it surprising that the authors of this source had used Clear(self).

This confirms what we had surmised.