| Subject |
Re: modal form |
| From |
Andy Taylor <andy.taylor.1959@outlook.com> |
| Date |
Fri, 21 Aug 2020 05:17:23 -0400 |
| Newsgroups |
dbase.getting-started |
Lee,
Missed that discussion :)
However to answer the point raised in a way slightly different to Mervyn is to say that
return readmodal()
attempts to pass a boolean variable back in the same way that the stock open() and readModal() functions do.
The passed variable meaning either success (true) or failure (false) in trying to open the form.
I am therefore guilty of lazy programming because I should have passed on the returned boolean especially
if this code is put into a base form class which should be as robust as you can make it...
However return readmodal() begs the question of which readModal code is being executed as Mervyn pointed out.
This question is resolved by the use of the scope resolution operator::
A compact version of my original code would be:
function readModal
this.modal = true // set your modal flag
return super::readModal() // calls the normal dBASE readModal method and returns success/failure
An explicit step by step version of my original code would be:
function readModal
local bRtn // establish a return variable
this.modal = true // set your modal flag
bRtn = super::readModal() // calls the normal dBASE readModal method and stores the returned boolean
return bRtn
Hope it helps.
Andy
> Andy,
>
> Where were you when I was discussing the use of super:: a while back. :)
>
> Anyway, in that discussion, it was brought up by Ken that the use of
> super:: sometimes worked, sometimes didn't, but regardless, what I
> noticed is that folks tend to have been putting the overridden function
> on the back of the return statement, ie:
>
> function readModal
> this.modal = true // set your modal flag
> //super::readModal() // calls the normal dBASE readModal method
> return readmodal() // have seen this being the norm
>
> Are you aware of any reason in the difference of application?
>
> The earlier discussion ended up disclosing that my function wasn't
> applicable, since my use of it was used in another programming language
> where even subclassing was ended with a call::super to reinvoke the
> inclusion of stock code behavior where not overidden.
>
> Lee
>
> On 8/18/2020 6:38 PM, Andy Taylor wrote:
> > Gaetano,
> >
> > No, there isn't, not explicitly.
> > However, you've done the right thing by setting your own custom flag in the code below via "intCheck.modal=true"
> > The best place for this would be by overwriting the standard readModal method as follows:
> >
> > Within your form constructor code, or as "always there" code in your base form class:
> >
> > function readModal
> > this.modal = true // set your modal flag
> > super::readModal() // calls the normal dBASE readModal method
> > return
> >
> > and for completeness....
> >
> > function open
> > this.modal = false // set your modal flag
> > super::open() // calls the normal dBASE open method
> > return
> >
> > That way you've just rolled your own permanent flag for this.
> > Andy
> >
> <snip>
|
|