Hi Brad;

  That's because all visual & non-visual controls / objects already have the pbm_constructor message ID mapped to their built-in "constructor" event. Also, when the PBVM processes O/S messages it dismisses them from the message queue instead of "chaining" it.

   Note: DW Controls steal messages from the front of the O/S queue and then chain them into it's own message queue. So quite often, you can map various pbm_xxxx message ID's to a DC but your App doesn't see them.

Regards ... Chris

One possible workaround:

1) On the prime ancestor window, in the PFC that would be W_MASTER or CORP_W_MASTER or PFC_W_MASTER depending on your scheme, add an instance variable "boolean      initial_open = TRUE"

2) Add your logging code to gnv_app.of_logit (string  as_log_msg)

3) In the activate event of the same window:
    IF (initial_open) THEN
       lw_window = this
       gnv_app.of_logit ("the window " + this.ClassName() + " just opened.")
       initial_open = FALSE
   END IF

Later -

Olan

I like Olan's solution of using the Activate event, but then ... of course that event might also be overridden. So to increment your chance of success, I'd do what he suggests in the activate AND in the open event of your common ancestor window.

Then again, how many windows would really have an override in the Open event? If it's not many, you can call the log code there explicitly. The only problem there is to identify them.

What I always do to find overriden events, is to use a little app I wrote in the 90's. It exports all code and allows me to do searches in the fully exported code. You could also use notepad++ (find in files) or GrepWin. With a powerbuilder search you would not find what I look for:

1)

I do a search on "event open;" and export that list to a text file. This list has all windows. 

2)

Then I do a search on "event open;call ..." (I don't remember if it's "call super::open", can't get into PB right now).  This list is the list of windows without an override of the open event.

3) copy and past both lists into excel, order by name and you can now easily see which windows have an override: it's the windows of list 1) which are missing in list 2).

There's tools like Visual Expert and maybe others like pb search or pbl peeper (not sure about these last 2) which might make this task easier.

Once identified, make sure any developers from now on call the login function or some event like  ue_init() or ue_override_open(), when doing an override of the open. (the ue_init would call the logging and would be called from the open event). The advantage of the ue_init is that you can add more stuff to it that you always want to execute.

Just to give you an idea,

regards

Hi, Brad -

I cannot answer the "why" part of your question, but here's a suggestion on how you might implement a pseudo-constructor event in an ancestor window where the Open event is not a workable solution:

In your base ancestor window, create an unmapped user event named ue_constructor or similar. Place in the base ancestor window a simple, hidden control, such as a static text control named st_constructor and set to text to something like "This static text control fires the window's ue_constructor event." as a clue for developers (it's hidden, so why not?). In st_constructor's Constructor event, code two lines:

This.Visible = False          // Just in case a developer makes it visible.
Parent.Event ue_constructor() // Fire window's "constructor" event.

As a little added insurance against st_constructor being seen, you could optionally also move it far to the right and/or down:

This.Move(25000,25000) // For example...

Now you can add code to the window's new "constructor" event as needed.

If you want that event to fire as soon as possible, you can Edit Source for the ancestor window and make the new, hidden static text control the first item in the window's Control array, but realize that references to any other controls in the ancestor window may not yet exist when the ue_constructor event executes. That's also a concern to keep in mind when the window's ue_constructor event fires.

HTH - Regards,
John