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