Normally I try to write applications on the DataWindow or Appeon but every now and then I get a question that makes me sit back and say, "Huh?"

In this case the question concerns the PostOpen event. I've seen that event named different things: ue_post_open, postOpen, post_open, ue_postOpen, etc. It has, as far as I can see, always had post and open in the name of the event. Further, just about every framework that I've ever seen has had that event in the base window.

The question that I was asked was, "Why is that event there?"

The programmer wanted to know why there was code in the post open and why was it not just put at the end of the open event? At first I was really confused by the question. It was like he was asking me why do we have arrays? I just couldn't imagine not knowing the answer.

Then it occurred to me that I learned the answer to that question from a book that was published almost 20 years ago. As far as I can tell there are no new books on PowerBuilder and there are only two print magazines, this one and the ISUG magazine.

That's it.

Further I came to think of the tremendous responsibility that the few PowerBuilder authors share. New PowerBuilder programmers turn to us for information and there aren't that many of us left writing. So that leaves a whole lot of PowerBuilder programmers who get all their training from reading the code of other programmers.

Often those other programmers were consultants who wrote the code ten years ago and worked for consulting firms that no longer exist.

To make a bad situation worse a lot of times those programmers are brave souls that have been recruited from other disciplines. When the company finds that their last PowerBuilder programmer has just quit because he got a much better offer they turn to their existing programming staff and ask who would like to pick up PowerBuilder. They may point out that there are 6 or 10 or, as in the case for one company for which I recently worked, 26 PowerBuilder programs that are all critical to the company. The PowerBuilder programmer would become indispensable to the company.

So suddenly a brave Visual Basic or Java programmer finds PowerBuilder installed on his machine. His boss pats him on his pointy little head and tells him that Google is his friend.

Where would you turn? If you picked up the mantle and offered to learn a language that you knew nothing about, what would you do? You'd turn to Amazon or Google. If you type "best PowerBuilder books" in Google the first mentioned is my Definitive DataWindow which was published 13 years ago and is embarrassingly out of date...and out of print.

Let's go to Amazon, there you will find the latest PowerBuilder book is for version 9. It was published 10 years ago. Since then... nothing.

Why should I be surprised that things that I find fundamental are entirely unknown by the newest PowerBuilder programmers.

Warning: If you are a seasoned PowerBuilder programmer the rest of this article will bore you silly.

There is an open event in a window. This is the event that happens when the window is "opened." Now the word ‘open' can be deceptive. A lot of people feel that a window is only opened when it is shown on the screen.

That would be wrong.

The open of a window begins when the open command is issued. That is to say, with a line like:

Open(w_client_editor)

The problem, the whole reason that a post open event is required goes all the way back to Microsoft Windows 3.0 Old Windows programmers will remember version 3.0 very well. Version 3.0 was almost the death of Microsoft Windows. It was unbearably slow. I am not exaggerating; it was the slowest version of Windows that was ever released.

It was so slow that Windows users were seriously studying what the impact of changing to another - any other - operating system would be.

This time Microsoft listened... and panicked. They did a study to determine what it is that makes the user perceive speed in an application. What could be changed to cause the user to believe that the application is faster with minimal real change to the operating system? It wasn't that Microsoft didn't want to address their problems with speed, they most certainly did, but addressing those problems would take time that Microsoft just didn't have. Microsoft was about to lose a lot of customers and once lost, it would be hard to get them back.

Microsoft learned that the visual perception strongly influenced the user's perception of speed. They learned that if the window POPPED onto the screen, all at once, even if the data wasn't there yet, then the users perceived speed. What killed the user perception was when they pressed a button and nothing happened for four seconds. The user would often punch that button two or three times. So Microsoft created operating system queues.

The graphics queue happened before the application queue. So graphics could be given a higher priority than the application and windows would paint faster. They released version 3.1 which was mostly just the addition of these queues (along with other changes like a floating point emulator in assembly code).

This was great but it broke the relationship of the open event with the code. This meant that you weren't guaranteed that everything would be created in the window until after the open event finishes.

Consider this code:

W_customer.open() event
Dw_1.setTransObject(sqlca)
Dw_1.retrieve()

This code would often result in a "Null object reference" error because dw_1 had not been created by Microsoft when the code ran.

Imagine how we felt when this happened. There was a null object reference in line 1 of the open event, but, but, but... that's dw_1. There it is, right there on the window! How can it be null? It's not dynamic. You put it there.

Okay, we learned that we should not put anything in the open event that referred to anything on the screen. Most of us learned to just not put anything at all in the open event except one line in the ancestor:

W_root.open() event
post event ue_post_open( )

For reasons already stated I imagine I can't rely on you knowing the difference between post event and trigger event or for that matter between postOpen and post open.

Okay, one at a time. Posting an event means that Microsoft Windows will open this window after the rest of the code in this script is executed. Basically it means, "Do this when you get a chance." So if you add that to the open event of your root window then it will call the ue_post_open event after all of the code in all of the descendants of this window is done.

Keep in mind the order of execution of events. First PowerBuilder goes to the farthest ancestor and then starts executing down the inheritance tree. If you have w_grandpa, and w_pa inherits from that and w_son inherits from that then the code in w_grandpa.open would execute first, then the code in w_pa, finally the code in w_son.

This means that if we put the post event in the open of w_grandpa, then the ue_post_open would happen after the last open event in the descendants. In our example:

W_grandpa.open->w_pa.open->w_son.open-> w_grandpa.ue_post_open-> w_son.ue_post_open->w_son.post_open

All that we have to do is create a ue_post_open event in our root window. We don't have to put anything in it, just create one. Then we post that event from the open event and we have a place now to put all our initialization code and don't have to worry about whether any object exists or not.

More important the screen will quickly draw or paint, giving the user the perception of speed. If you need to retrieve data and know it will take a short time, then you can set the pointer to an hourglass. I guarantee that your user will feel the window is faster.

I mentioned that most of us learned not to put anything in the open event. There is an exception to that rule. When your window is opened with a parameter then you should access the message object as the first line of code in your window.

Let me give you an example. Suppose that you open a window with a customer_id. You are going to use that customer_id as a parameter to the datawindow dw_1. Here is what you would do.

W_calling_window
Long ll_customer_id
Ll_customer_id = dw_detail.getItemNumber(dw_detail.getRow(), "customer_id")
openWithParm(w_customer_detail, ll_customer_id)

Now in the w_customer_detail window you need to set an instance variable. That's because we have just passed a variable to the new window and we are going to get it in the open event but we are going to retrieve the DataWindow in the ue_postOpen event. So let's do this. I will assume that you know how to declare an instance variable. Let's name it il_customer_id. Now let's look at the open event of w_customer_detail.

W_customer_detail.open()
il_customer_detail = message.longParm

Okay, now in the open event of w_customer_detail we have taken the longParm property of the global message object and put it in an instance variable.

Since we have inherited the w_customer_detail from whatever our base window is, the ue_postOpen event will automatically fire. That means that we don't have to fire off the event. Now I just have to put the code that we need in the window.

W_customer_detail.ue_postOpen()
dw_customer_info.setTransObject(sqlca)
dw_customer.retrieve(il_customer_detail)

Let's Do Some Housekeeping
I think that we've pretty well covered the post open event but in the process of doing that I've brought up a couple of other issues that I'd like to cover just to be complete.

First let's talk about post event as opposed to postEvent.

With the post event command you must know the name of the event that you want to post. You can pass the parameters normally. However, just like calling a function, the event has to exist and the parameters must be correct.

On the other hand the postEvent function takes a string as a parameter and that string is the name of the event. This means that you can store the name of the event in a table. In fact the event doesn't even have to exist. If it doesn't then nothing will happen. There will be no error thrown.

This makes the postEvent perfect for security systems where you can post an event based on a security role. Here is some code that might work for you in a menu event.

M_main.m_file.m_save.clicked
Datastore ld_security, ld_events
ld _secutity = create datastore
ld_events = create datastore

ld_events.dataobject = "d_events"
ld_security.dataobject = "d_get_security"

ld_events.setTransObject(sqlca)
ld_security.setTransObject(sqlca)

parentWindow.postEvent(ld_events.retrieve(ld_security.retrieve(gs_user_id)))

Using the postOpen function is very flexible but it is limited in the parameters that can be passed it. If you use the post event command, you can pass any number of parameters that you wish. The caveat is that the event must exist or you will get a compile time error. So the event that you used before for security cannot be done.

All that I just said for the postEvent and post event command applies also to the triggerEvent and trigger event commands.

Finally I'd like to mention the global message object.

This object is global. It can be accessed at any time by any other object. That means that if you access the message object in the postOpen event then another window may have changed your message object properties and this could corrupt what you are expecting.

Don't take this lightly. More than once I've debugged and found this error and believe me it is difficult to find. The problem is that it is not an error with logic or data but a timing error. These can be close to impossible to find.

Please take my word for this, make it a golden rule. If you open a window with a parameter, the first thing you do in the target or opened window is grab that value from the message object and store it.

Also, if you do a closeWithReturn then you need to immediately get the value from the message object.

There you have it. I've covered in some detail some basic information that might not be so easily learned any more.