zhou@brazil.psych.purdue.edu (Albert Zhou) (04/12/91)
It seems that overwriting TApplication.Init is very hazardous. I have tried to overwrite it in order to get a different background. Here is the code: procedure mine.init; virtual; begin Tapplication.init; write a different background; end; Odd enough, this modification caused the system to be rebooted. Out of curiosity, I tried the following code: procedure mine.init; virtual; begin Tapplication.init; end; This should not have changed anything. But this time, the system simply got stuck.
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (04/12/91)
In article <11841@j.cc.purdue.edu> zhou@brazil.psych.purdue.edu (Albert Zhou) writes: >It seems that overwriting TApplication.Init is very hazardous. > I have tried to overwrite it in order to get a different background. >Here is the code: > >procedure mine.init; virtual; >begin > Tapplication.init; > write a different background; >end; > >Odd enough, this modification caused the system to be rebooted. I don't think the problem is with TApplication, it's with your override. You should declare mine.init to be a constructor, not a virtual method. Virtual methods can't be called until after the object is constructed. Duncan Murdoch dmurdoch@watstat.waterloo.edu
mwizard@eecs.cs.pdx.edu (Craig Nelson) (04/12/91)
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: >In article <11841@j.cc.purdue.edu> zhou@brazil.psych.purdue.edu (Albert Zhou) writes: >>It seems that overwriting TApplication.Init is very hazardous. >> I have tried to overwrite it in order to get a different background. >>Here is the code: >> >>procedure mine.init; virtual; >>begin >> Tapplication.init; >> write a different background; >>end; >> >>Odd enough, this modification caused the system to be rebooted. >I don't think the problem is with TApplication, it's with your override. >You should declare mine.init to be a constructor, not a virtual method. >Virtual methods can't be called until after the object is constructed. I KNOW the problem is with the fact it's a method and not a constructor. I ran into the same problem when I was learning how to use TStreams because I cas declaring the MyObject.Load(var S:TStream) to be a method and not a constructor. Don't know exactly how it is done, and Sydney, feel free to but in and tell me I'm wrong, but all objects have a link to their virtual methods through their contructors. Normally if you do not call a constructor with an object before you use a virtual method a runtime error will occur. This does not seem to happen if you override the constructor of the derive' class with a virtual method instead. It's like it used to be a constructor, so maybe it still is. Anyway, I stay away from that problem by using the extended sytnax of the New() function. If you pass New(PMyObject,Init) and Init is not a constructor, you will not get a working program, but a COMPILER error instead of a runtime error. I know it uses the heap alot more, but welcome to OOP. Cheers! []====================================================================[] || Craig R. Nelson | CCSofD Software Inc. || || Programmer | Beaverton, OR, 97005 || || mwizard@eecs.ee.pdx.edu | (unlisted on the net) ||
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (04/13/91)
In article <2337@pdxgate.UUCP> mwizard@eecs.cs.pdx.edu (Craig Nelson) writes: >Normally if you do not call a constructor >with an object before you use a virtual method a runtime error will occur. This only happens if you compile the code with the $R+ compiler option. I should have suggested that; very frequently, if your program crashes inexplicably, $R+ will find the error, because it does range-checking and object VMT validation. Duncan Murdoch