VERSIONS: All, written for Paradox 5
SUBJECT: Event model
BY: MARK PAUKER
Date: 17 January 1996
QUESTION from: Francis vdGhinst
Now I have a much philosophic question. My feeling after three years of Paradox programming and one year of Delphi programming is that the
Pdox event model is still very hard to understand. I'm always discovering better way to do the job (there always might be a better way) but most
of the times, the difference are not so evident. For instance, you have cases where it's better to user seterrorcode (to prevent dataaction event for
instance) and other cases where it's better to use disabledefault.
What's your opinion about this. How can we best use the event model. I'm aware that's the power of Paradox but I'm convinced that after 3
years of programming, I still not used it as I should do.
I could write a thousand pages trying to respond to your question, and still leave a lot unsaid. In short, though, I think the event model is
both Paradox's blessing and its curse. I have thought all along that the event model was too complex, and believe that removing 10% of its
functionality could have reduced 50% of its complexity. Of course, the problem with discussing this now is that it's meaningless because changing
the event model at this point would break every app in existence.
That having been said, I came up with what I refer to as the "I don't care" approach to the event model about a year ago. (I was planning to
present a paper on it at the last Borland conference, but attending the birth of my first child took precedence.) The approach centers on the
distinction between disableDefault and setErrorCode, and on the use of postAction.
In your message you refer to the fact that in some cases it's better to use setErrorCode and in others it's better to use disableDefault. I would
alter that slightly to say that in some cases it's _correct_ to use setErrorCode and in others it's _correct_ to use disableDefault. The difference
between these statements is that the latter implies a hard-and-fast rule which describes when to use each. (Use setErrorCode to cancel an event
such that it doesn't happen, and disableDefault to stop Paradox from doing its default behavior because _you_ have already done the task through
OPAL.)
I believe that anyone using the "I don't care" approach doesn't need to understand all of the intricacies of the event model, and can be writing
sophisticated applications in hours or days (rather than weeks or months).
All this having been said, there are some problems (like your field highlight problem) that are simply baffling unless you happen to fall upon
the correct approach. As a general rule, I think it's best to really think about what it is that you're logically trying to do. It may seem trite, but I
believe that there's a real difference between the statements:
if si > 0 then ...
and
if si <> 0 then ...
even if si is guaranteed to be non-negative (and thus the statements are evaluated identically by the computer). I actually spend time considering
which form I want to use in different situations. (Do I want to know if si is non-zero, do I want to know if it's positive?)
In considering your problem, it seemed to me that the real issue you were trying to deal with was figuring out how to prevent a field from
obtaining focus rather than trying to stop the focus from being displayed once the field had focus. I'm not sure how to teach this, but I think that it
comes with taking a step back and considering what it is you're really trying to do. As I mentioned, though, I don't think this example is
representative of the problems that most people are having with the event model. I think most of the problems people have involve understanding
how events flow through the system and how to control them. Towards that end, my "I don't care" approach seems to have been very
successful.
But sometimes the problem is so hard that your logical approach is also not the right. You tell me that I should have a precise idea of what
I'm trying to get but sometimes, If you're not aware of the system, how can you have this idea?
I agree. I didn't mean to imply that it was easy, or even possible all the time to know precisely what the issues are. I simply meant to suggest
that one more tool in trying to figure out how to do something is to take a step back and see if you can re-frame the problem. Your "F9" example is
a perfect blend of what we are both saying.
If you want to stop a user from getting into edit mode, you _must_ understand certain aspects of Paradox that are not necessarily obvious.
Either you have to disable all possible avenues into edit mode, or you need to understand about centralized trapping in the action method.
Granted, this is pretty a rudimentary example, but as you point out, you just have to know it.
The example is a good one to express my point as well, because a person who disables the F9 key probably needs to take a step back and
realize that the task that needs to be accomplished isn't really disabling the keystroke, but rather disabling edit mode.
Perhaps what we're both trying to say is that Paradox is a very complex product. The good part of that is that you can do almost anything
with it. The bad part is that sometimes it's damn near impossible to figure out how!
I offered the "take a step back" approach as a mental exercise which may (or may not) be helpful in figuring out the next puzzle.