| PeopleCode Event Order | KEVIN RESCHENBERG
06-27-2007 |
I generally write this column every Wednesday, but lately have been skipping a
week here and there. It's a combination of being very busy and/or just not having
anything new to say. (Besides my client work, I'm readying a new version
of the SQR debugger for release hopefully this
weekend. Also, over at Protallian,
we are continuing to sign up independent contractors. We now have a small but good
core group in the PeopleSoft and Hyperion SQR specialties.)
Today I was thinking about some of the issues related to the order in which various
events fire or functions execute. This can be confusing at times and can lead to
some bugs that are tricky to find. For example, let's say that you are writing code
in SaveEdit and want to issue an error message using Error MsgGet().
Then you want to move the cursor to the field in error using SetCursorPos().
Easy enough, except that the cursor never moves to the field. What happened? Well, it
turns out that Error ends the PeopleCode program immediately, so
the cursor positioning is never done. You need to do that before issuing the
error message.
DoSave() is another one. This function triggers the component save
processing (which will eventually cause SavePreChange, Workflow, and SavePostChange
to fire). You can call it anywhere in your PeopleCode program, but it doesn't run
when you call it. Instead, it's deferred until later. This means that
you can't call it and then follow the call with code that depends on the data having
been saved. Look into DoSaveNow() or CommitWork() if you
need this sort of functionality.
Component PeopleCode vs. record PeopleCode is another area that can be a little confusing.
They share many of the same events at the same level—for example, RowInit.
But which one runs first? (Record PeopleCode—any code stored in the record
definition—runs first, and component PeopleCode runs second.) Knowing this can
be critical to planning and debugging the flow of execution.
As a final example, have you ever written code to display a message box as a quick
debugging technique, only to find that it does not appear at the expected place in
your code? This can be puzzling (and a distraction when you're really trying to track
down a bug). What's happening is easy to understand, though, when you consider what
the message box really is. It's a JavaScript alert() inserted into the HTML
sent to your browser. As your PeopleCode is executing, the message box is just written
to the output HTML, and then the program continues. When all of the PeopleCode is
finished, the page is sent to the browser. Only then do you see the message box.
So you can use it to display information, but you can't use it as sort of a "pause"
in your code.
|
