>>>
>>> CASE m.nKeyCode=13
>>> if gEnterTerminate
>>> thisform.release
>>> endif
>>>
>>>Is there a better way to do this? Are there any side effects from changing the Ingrid control in this manner.
>>>
>>>Thanks for all your help and interest,
>>>
>>>Alex Shoob
>>
>>Instead of specifying the action explicitly, you might want to create a new method in the class called ActiononEnter or something and call that method in your CASE statement. That way you can put whatever code you want in that method in different instances of the class, and not have to modify the again class later. Polymorphism in action.
>
>This reminds me of another thread [Coding standards], where George Tasker explicitly stated that jumping out of the loop is a very no-no thing to do. OK. Now we actually must have some method of jumping off the bus, so calling ThisForm.Release actually is a jump out of the form's event loop, right? We call it in the middle of an object's method code.
>
>Hiding the Thisform.Release in the ThisIngrid.ActionOnEnter is equal to jumping out of the loop. Since we must have it anyway (though I'd rather use Esc as the key to trigger it), we've actually just changed the way we write it. We don't jump out of the loop, we call jump out method. I still have a feeling that jumping of the loop wasn't that bad and dirty in the first place. Sure needs to be obvious in the code and well documented, else we're in for some heavy debugging - and finding that ActionOnEnter releases the form is equally hard to discover as is premature end of loop. Should we get back to the Coding Standards over this?


I don't feel that calling thisform.release is jumping out of the loop any more than RETURN is. They are both incarnations of of a GOTO, which is almost universally regarded as bad coding practice, but RETURN is a _tame_ version and has grown vital to our routine architectures.

I wasn't necessarily implying that Alex should put a thisform.release in his Ingrid code, only instructing him on a more object way to handle it, if he deemed necessary.

Getting back to the specific situation, however, if the call to ActioOnEnter is within a DO CASE construct, this isn't really jumping out of the loop, unless there is other code in the method that executes after DO CASE.