Results 1 to 4 of 4

Thread: Derive from an Class in a DLL

  1. #1

    Derive from an Class in a DLL

    I have just been thinking about this particular problem.

    I figured out how to share a class outside a DLL with another application. This is done by declaring an abstract class in a "interface" unit. both the main application and the dll reference this unit, there is an additional function on the dll to return and instance of the class within the DLL. All of this requires a shared memory unit so the whole application using the same memory manager.

    Now why do I have a problem :?: :?:

    I want to be able to derive a new class from one that is implemented in another DLL. Like you can with Delphi packages. There must be a way of doing this, anyone got any ideas :?:
    <A HREF="http://www.myhpf.co.uk/banner.asp?friend=139328">
    <br /><IMG SRC="http://www.myhpf.co.uk/banners/60x468.gif" BORDER="0">
    <br /></A>

  2. #2

    Derive from an Class in a DLL

    Wait until packages are implementd in FPC?

    Let's see how it's impelmented behind your code. When your class funcition calls "inherited" it's really a static call to TBaseClass_OutFunction(Self, parameter1, ...). So if you are compiling a plain DLL - compiler just don't know where destination funciton is located (unless you build in that function - i.e. compile it in the same DLL).

    Sure you can try to avoid this using the same "interfaces" trick. I would go by "implements" route, but IIRC FPC does't support this [correctly?].
    There are only 10 types of people in this world; those who understand binary and those who don't.

  3. #3

    Derive from an Class in a DLL

    I've implemented this kind of thing once via FPC. The basic idea is that you patch a VMT entry of the instantiated class. Code goes like this:

    Code:
    Function tObjectsLinker.IntroduceVMT&#40;VMT&#58;Pointer&#41;&#58;String;
    Var ParentVMT&#58;Pointer;
        ParentClass&#58;tLClass;
    Begin
       While Assigned&#40;VMT&#41; Do Begin
          ParentVMT&#58;=tClass&#40;VMT&#41;.ClassParent;
          If Not Assigned&#40;ParentVMT&#41; Then Exit;
          If FindClass&#40;tStaticClass&#40;ParentVMT&#41;.ClassName,ParentClass&#41; Then Begin
             If ParentClass.PackageID=CORE_PACKAGE Then Begin
                Logger.Log&#40;'Class '+tStaticClass&#40;VMT&#41;.ClassName+' expands '+ParentClass.ClassName&#41;;
                pPointer&#40;VMT+vmtParent&#41;^&#58;=ParentClass.StaticClass;    // do injection
                Exit&#40;ParentClass.ClassName&#41;;
             End;
          End;
          VMT&#58;=tClass&#40;VMT&#41;.ClassParent;
       End;
       Logger.Fatal&#40;'Unable to determine class ancestor'&#41;;
    End;
    
    Procedure tObjectsLinker.IntroduceClass&#40;Var LClass&#58;tLClass&#41;;
    Var ParentVMT&#58;Pointer;
    //    VMT&#58;Pointer;
    //    ParentClass&#58;tLClass;
    Begin
       If LClass.PackageID=CORE_PACKAGE Then Begin
          // don't touch Core classes
          // FIXME&#58; 
          ParentVMT&#58;=LClass.StaticClass.ClassParent;
          If Assigned&#40;ParentVMT&#41; Then LClass.ExpandsClass&#58;=tStaticClass&#40;ParentVMT&#41;.ClassName Else
             LClass.ExpandsClass&#58;='';
          Exit;                       
       End;
       LClass.ExpandsClass&#58;=IntroduceVMT&#40;LClass.StaticClass&#41;;
    End;
    You could find my solution at http://www.linderdaum.com in old downloads
    --
    <br />Sergey K.
    <br />Linderdaum Project Coordinator
    <br />http://linderdaum.gamedot.ru
    <br />netsurfer@au.ru

  4. #4

    Derive from an Class in a DLL

    Quote Originally Posted by Clootie
    Sure you can try to avoid this using the same "interfaces" trick. I would go by "implements" route, but IIRC FPC does't support this [correctly?].
    Sb was working on it. Could be that it is in devel version (the future 2.2)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •