Subject Re: modal form From Lee Grant <camilee@nospam.comcast.net> Date Thu, 20 Aug 2020 22:07:57 -0400 Newsgroups dbase.getting-started Mervyn, I was focusing intently on your explanation and hanging on every word, which completely went out the window when I read this: >> Mm, it didn't know it's r's from its elbow. ROFLMAO :) Thanks for the laugh and the breakdown. I see that I need to delve further into this so I can understand it better.  I know we've done stuff before where we called the super first and then changed things in those settings we wanted different, but your explanation furthers my need to know better now. Thanks for "edumacation" and the laugh. :) Lee On 8/20/2020 11:37 AM, Mervyn Bick wrote: > On 2020-08-20 08:39, Lee Grant wrote: >> Gaetano, >> >> I've been working with the report Akshat, Mervyn and myself have been >> working on to print without user intervention and in the iteration >> that Akshat put together he used a different return, but near as I can >> figure these all work in an overridden method: > ....... >>>  form.output = 2 >>>  //super::render() // this works with a simple return at the end > > With this line in the code the render() method of the report baseclass > is executed after the new code has been executed so all that is needed > is 'return' to tell dBASE there is nothing left to do in the function. > > As an aside, there could be occasions when overwriting a method where > you would want to place this line before the new code.  It doesn't apply > here as that would be a bit like closing the stable door after the horse > has bolted.  After render() there is nothing one can change in the report. > >>>  return super::render()  //TESTSMILES2REPORT::render() // these work > > They both work here but they are really not quite the same. > > Classes can be sub-classed from sub-classes to form a chain. > > return super::render() immediately executes the render() method of the > report baseclass which is built into dBASE.  This bypasses any > overwritten render() methods in the custom forms, if any, in the chain. > > return TESTSMILES2REPORT::render() will work it's way back up the chain > executing any overwritten render() methods until it eventually gets to > the custom report which actually executes the baseclass render() method. > > In this particular case both commands appear to be exactly the same as > the report in question was not sub-classed. > >> >> To note, originally the form.output and form.outputfilename had the >> variable r in front, but I had to change it because it errored that r >> had not been defined, which is something I have to figure out, since >> form IS variable R, I'm not sure why it's kicking that error, but the >> method is a being overridden on the form...so it kind of makes sense >> that it knows who it is (form) but not what (r) is. I think. :) > > Mm, it didn't know it's r's from its elbow. > > Actually form isn't r.   r is an object which is an instance of the report. > > In the report's class definition 'form' refers to the object which will > eventually be created and is the parent of any other objects in the > report.  At that stage r, as an instance of the report, doesn't exist so > it can't be referenced from within in the overwritten render() method. > > Initially we started out by creating the instance of the report using > code in the heading area.   There r existed outside the report and we > could change any of the properties of any of its objects before the > instance was rendered(). > > Mervyn. > > > >