On Apr 24, 2006, at 5:43 PM, Charles Ross wrote:
On Apr 24, 2006, at 9:07 AM, Charles Yeomans wrote:
On Apr 23, 2006, at 9:05 PM, Charles Ross wrote:
I'll change the order and see how it goes, but I put the window's
constructor call before my initialization line and it worked
fine, so perhaps the window's constructor doesn't call the
control open events.
Sub Constructor()
super.Window
db = App.Database
End Sub
Super.Window calls the Open event handlers for the controls and
the window. I've found that the better practice is to either add
a constructor or implement Open events, but not both.
Charles Yeomans
If that's the case, then why does the above work? Originally, I was
setting the db property in Window.Open, but there were controls
that needed to access the property in their Open handlers, and they
were executing before Window.Open. Creating the above Constructor
solved the problem, i.e., I wasn't getting a NilObjectException
after I added it, whereas I was before. This led me to conclude
that the control Open handlers were executing before the
Window.Open handler.
You can figure this out explicitly by using System.Log to log the
execution of each event handler, then inspect the log.
However, if super.Window executes the control open handlers, the
Constructor above should raise the NilObjectExceptions again, but
it doesn't.
Good question. You should have set db before calling Super.Window.
Or am I missing something?
I think the thing you're missing is my earlier reply. It would be
better to replace the property db with a function db that just
returns App.Database. Then you would not need to set db -- and check
it for nil every time you use it because some other bit of code might
have changed the property.
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
