Subject Re: modal form From Mervyn Bick <invalid@invalid.invalid> Date Thu, 20 Aug 2020 17:37:55 +0200 Newsgroups dbase.getting-started 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.