Dick,
Look at https://www.xsharp.eu/help/example-2-th ... ample.html and how we added the extension method RTFChangeFont().
Robert
Inheritance problem
Inheritance problem
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Inheritance problem
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.
And Dick, I can't imagine using the methods of an object which is not initialised.
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Inheritance problem
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:
A sample method for one of the windows subclasses will be:
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
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
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
Thanks for all suggestion. When Frank is ready and it works he or we will summarize the results here.
Dick
Inheritance problem
Dick,
Your solution uses (IIRC) the Decorator Pattern.
Robert
Your solution uses (IIRC) the Decorator Pattern.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Inheritance problem
Hi Dick,
and what about that:
and on your window call simply
Wolfgang
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
Code: Select all
self:SetColours( 1, 1, 1, 1, 1, 1, 1 )
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Inheritance problem
Hello Robert,
I have applied this in 2009 preparing for Vulcan, a bit like a VO implementation of of multiple inheritance.
Dick
I didn't know that term, but found some explanation (e.g. https://sourcemaking.com/design_patterns/decorator)robert wrote:Your solution uses (IIRC) the Decorator Pattern.
I have applied this in 2009 preparing for Vulcan, a bit like a VO implementation of of multiple inheritance.
Dick
Inheritance problem
Hello Wolfgang,
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
That is what Robert suggested in this thread. But that's X# only.wriedmann wrote: 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
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
Inheritance problem
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
X# side
and in both VO and X# code I can simply write:
or inside the class
I hope I was able to explain that.
Wolfgang
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
Code: Select all
class VOExtensions
static method xyz( self as Window ) as void
....
return
end class
Code: Select all
oWindow:xyz()
Code: Select all
self:xyz()
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Inheritance problem
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
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