Inheritance problem

[robert]

Dick,

Look at https://www.xsharp.eu/help/example-2-th ... ample.html and how we added the extension method RTFChangeFont().

Robert

[FFF]

I thought he wants to access no "new" method, but simply an existing method of the base class??
And Dick, I can't imagine using the methods of an object which is not initialised.

[ic2]

Hello Robert, Karl, Johan,

We instantiate for example a ContactWindow which inherit from MyDatawindow, which inherits from Datawindow and ends with Class Window.
But trying to run a Windows subclass (former Class Windows) method would re-instantiate the Windows (sub)class.

I found out that in my own code I already use the VO version of Extensions:

Code: Select all

CLASS IC2WindowExtender
EXPORT oWin AS Window

METHOD INIT(oWindow) CLASS IC2WindowExtender
SELF:oWin := oWindow
RETURN SELF

A sample method for one of the windows subclasses will be:

Code: Select all

METHOD SetColours(nFgr,nFgg,nFgb,nBgr,nBgg,nBgb) CLASS IC2DialogWindow
//#s Calls super method 
LOCAL oIC2Win AS ic2WindowExtender
oIC2Win:=IC2WindowExtender{SELF}
oIC2Win:SetColours(SELF,nFgr,nFgg,nFgb,nBgr,nBgg,nBgb)
RETURN TRUE

I think this will work in X# too and then it minimizes conversion time, if we change this in VO. The extensions as Robert pointed to in sample code are a good direct X# solution, we cold also use this. And Johan's super:super etc should work too, but I don't like these construction as it doesn't clearly show you where your method runs from. You have to count (supers) and could easily miscount I am afraid.

Thanks for all suggestion. When Frank is ready and it works he or we will summarize the results here.

Dick

[robert]

Dick,
Your solution uses (IIRC) the Decorator Pattern.

Robert

[wriedmann]

Hi Dick,
and what about that:

Code: Select all

static METHOD SetColours( self oWin as Window, nFgr as dword ,nFgg as dword,nFgb as dword,nBgr as dword,nBgg as dword,nBgb as dword) as void // CLASS IC2WindowExtender
// your code to set window color
RETURN TRUE

and on your window call simply

Code: Select all

self:SetColours( 1, 1, 1, 1, 1, 1, 1 ) 

Wolfgang

[ic2]

Hello Robert,

Your solution uses (IIRC) the Decorator Pattern.

I didn't know that term, but found some explanation (e.g. https://sourcemaking.com/design_patterns/decorator)

I have applied this in 2009 preparing for Vulcan, a bit like a VO implementation of of multiple inheritance.

Dick

[ic2]

Hello Wolfgang,

and what about that:
static METHOD SetColours( self oWin as Window, nFgr as dword ,nFgg as dword,nFgb as dword,nBgr as dword,nBgg as dword,nBgb as dword) as void

That is what Robert suggested in this thread. But that's X# only.

What we try to do is adapt VO as much as possible so the actual VO->X# move would take minimal time. Everything we can't prepare in VO, e.g. our Office OLE classes will use Office.Interop .Net classes, is documented or will be code set aside to be inserted once we convert the project Frank is working on.

Should we convert directly then we will have a long period, at least weeks or more, in which the daily maintenance can not be done or must be done twice, in the VO program and applied again in the program to be converted.

Dick

[wriedmann]

Hi Dick,
personally I prefer the solution with the extension method as suggested by Robert because it is more compatible with the VO side of code.
In my VO code I have these extensions to the original VO classes in a separate module.
In the X# version this module does not exists, but there is another module with all the extension methods.
And in the application and library code there is no difference as I can write the same code, calling the methods normally.
Maybe I have to explain better:
VO side

Code: Select all

method xyz() class Window
.....
return nil

X# side

Code: Select all

class VOExtensions
static method xyz( self as Window ) as void
....
return
end class

and in both VO and X# code I can simply write:

Code: Select all

oWindow:xyz()

or inside the class

Code: Select all

self:xyz()

I hope I was able to explain that.
Wolfgang

[ic2]

Hello Wolfgang,

Frank will read this all Wednesday and we should decide then what to choose.

To keep the Windows methods in VO isn't really a problem if the X# conversion is close. My change means there's no need for a further conversion once the actual conversion takes place to X# (everything Frank is doing now is preparing VO changes, notes what to do and having X# specific libraries ready so in a while he should be able to convert the live VO solution definitely to X# within a day or a few days, instead of weeks.

Your solution means that he has to encapsulate every class window method with the static class code but it won't be too much work.

Thanks everyone for contributing.

Dick