Event Call Order (REALbasic getting started Mailinglist archive)
Back to the thread list
Previous thread: I got my application icon to show up -Brian
Next thread: Font Menu & Changing Edit Field font
| Event Call Order |
| Date: 22.04.06 22:50 (Sat, 22 Apr 2006 14:50:59 -0700) |
| From: Charles Ross |
|
Is it documented some place what order events are called in when a
Window is created? For instance, I had put some code into the Open event of the Window, as well as the Open event of a number of controls within the Window, and I found out that apparently the controls' Open events are called before the Window's Open event. I move the code in Window.Open to Window.Activate, and it worked, so apparently Window.Activate is called before the controls.Open. Is this precise order documented somewhere? Thanks, Chuck _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 22.04.06 23:08 (Sat, 22 Apr 2006 15:08:08 -0700) |
| From: Terry Ford |
|
On Apr 22, 2006, at 2:50 PM, Charles Ross wrote: > Is it documented some place what order events are called in when a > Window is created? For instance, I had put some code into the Open > event of the Window, as well as the Open event of a number of > controls within the Window, and I found out that apparently the > controls' Open events are called before the Window's Open event. I > move the code in Window.Open to Window.Activate, and it worked, so > apparently Window.Activate is called before the controls.Open. Is > this precise order documented somewhere? Not officially as it; a) is subject to change and b) happens differently on different platforms. It is safest to *not* depend on the order of opening events in your code assignments. Also don't forget that the Activate event happens every time a particular window becomes frontmost. A *very unofficial* outline of Opening events is contained in Matt Neuburg's RBTDG. It is also very dated. There are also ways to work around this order limitation by using a timer. Terry _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 22.04.06 23:08 (Sat, 22 Apr 2006 18:08:15 -0400) |
| From: andrew kellerfarm.com |
|
> Is this precise order documented somewhere?
I don't know if it's documented, but through my experience, I have found the order to be: Controls.Open (in control order) Window.Open Window.Activate Don't forget that Window.Activate fires when the window is brought to the front - every time, including right after Window.Open and when all the windows in front of it close. HTH - Andrew Keller _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 22.04.06 23:18 (Sat, 22 Apr 2006 18:18:10 -0400) |
| From: Charles Yeomans |
|
On Apr 22, 2006, at 5:50 PM, Charles Ross wrote: > Is it documented some place what order events are called in when a > Window is created? For instance, I had put some code into the Open > event of the Window, as well as the Open event of a number of > controls within the Window, and I found out that apparently the > controls' Open events are called before the Window's Open event. I > move the code in Window.Open to Window.Activate, and it worked, so > apparently Window.Activate is called before the controls.Open. Is > this precise order documented somewhere? The order is mostly intentionally undocumented. You're better off writing code that does not depend on the order of events. 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> |
| Re: Event Call Order |
| Date: 22.04.06 23:20 (Sat, 22 Apr 2006 15:20:54 -0700) |
| From: Terry Ford |
|
On Apr 22, 2006, at 3:08 PM, <email address removed> wrote: >> Is this precise order documented somewhere? > > I don't know if it's documented, but through my experience, I have > found the order to be: > > Controls.Open (in control order) > Window.Open > Window.Activate This is a safe general assumption for Mac but Windows behaves differently as MDI windows *may* get an activate event earlier. A lot of what can go where depends on what scope is actually affected by each of the open events. Terry _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 22.04.06 23:41 (Sat, 22 Apr 2006 15:41:22 -0700) |
| From: Charles Ross |
|
On Apr 22, 2006, at 3:18 PM, Charles Yeomans wrote:
> The order is mostly intentionally undocumented. You're better off > writing code that does not depend on the order of events. Then how would you suggest this is best handled? The window has a property called db which needs to be set for most of the functionality of the window, including the open event of the listboxes and popup menus within the window. Should I set db in each of these Open events to ensure that it is set when they are called? At this time, I'm setting it in the Window.Activate event, which seems to work. It seems a pain to have to put the same line of code in every control's Open event given that I don't know which will fire first. Or, given that controls execute their Open events in the order of the control order (is this documented and guaranteed?), I could place an invisible control on the window, make it the first in the order, and place my property setting code there. On Apr 22, 2006, at 3:08 PM, <email address removed> wrote: > I don't know if it's documented, but through my experience, I have > found the order to be: > > Controls.Open (in control order) > Window.Open > Window.Activate This is actually contrary to what I'm experiencing, perhaps because of platform differences. The order I've found with my testing is: Window.Activate Controls.Open Window.Open Regardless, to have the control Open events fire before the Window's Open event seems backward to me. I don't mind that the Activate fires every time the Window comes to the front, as the code within it is very simple at this point: db *pp.Database Mostly, it's so I don't have to type "App.Database" every time I need to refer to it within the Window's code. Perhaps a Constructor is a better option? Basically, I need that line above to execute before pretty much anything else. Thanks, Chuck _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 22.04.06 23:48 (Sat, 22 Apr 2006 18:48:33 -0400) |
| From: Charles Yeomans |
|
On Apr 22, 2006, at 6:41 PM, Charles Ross wrote: > On Apr 22, 2006, at 3:18 PM, Charles Yeomans wrote: > >> The order is mostly intentionally undocumented. You're better off >> writing code that does not depend on the order of events. > > Then how would you suggest this is best handled? The window has a > property called db which needs to be set for most of the > functionality of the window, including the open event of the > listboxes and popup menus within the window. Should I set db in > each of these Open events to ensure that it is set when they are > called? At this time, I'm setting it in the Window.Activate event, > which seems to work. It seems a pain to have to put the same line > of code in every control's Open event given that I don't know which > will fire first. Or, given that controls execute their Open events > in the order of the control order (is this documented and > guaranteed?), I could place an invisible control on the window, > make it the first in the order, and place my property setting code > there. <snick> > I don't mind that the Activate fires every time the Window comes to > the front, as the code within it is very simple at this point: > > db ^pp.Database > > Mostly, it's so I don't have to type "App.Database" every time I > need to refer to it within the Window's code. Okay, this makes things simple. Add a private function DB as Database to the window. Private Function DB() as Database Return App.Database End Function It solves your problem, as I understand it, and you can tell people that you're using "law of Demeter" design principles. 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> |
| Re: Event Call Order |
| Date: 23.04.06 03:50 (Sat, 22 Apr 2006 19:50:21 -0700) |
| From: Norman Palardy |
|
On Apr 22, 2006, at 2:50 PM, Charles Ross wrote: > Is it documented some place what order events are called in when a > Window is created? For instance, I had put some code into the Open > event of the Window, as well as the Open event of a number of > controls within the Window, and I found out that apparently the > controls' Open events are called before the Window's Open event. I > move the code in Window.Open to Window.Activate, and it worked, so > apparently Window.Activate is called before the controls.Open. Is > this precise order documented somewhere? No, nd if you find you MUST have a specific order then try adding a constructor to your window The constructor happens before the Open events for all controls but after they all exist _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 23.04.06 03:52 (Sat, 22 Apr 2006 19:52:13 -0700) |
| From: Norman Palardy |
|
On Apr 22, 2006, at 3:41 PM, Charles Ross wrote: > On Apr 22, 2006, at 3:18 PM, Charles Yeomans wrote: > >> The order is mostly intentionally undocumented. You're better off >> writing code that does not depend on the order of events. > > Then how would you suggest this is best handled? Use a constructor for the window _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 24.04.06 01:13 (Sun, 23 Apr 2006 20:13:00 -0400) |
| From: Mathieu Langlois |
|
To clarify this, you need to call the super's constructor in your subclass
constructor for a window to properly initialize (super.window). You want to put your initialization code BEFORE calling the window's constructor because the the window's constructor triggers the open events. Also you can't (well at least shouldn't, it may work in some cases but it's a bad idea) access any of the controls before calling the window's constructor. On 4/22/06, Norman Palardy <<email address removed>> wrote: > > No, nd if you find you MUST have a specific order then try adding a > constructor to your window > The constructor happens before the Open events for all controls but > after they all exist _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 24.04.06 02:05 (Sun, 23 Apr 2006 18:05:08 -0700) |
| From: Charles Ross |
|
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 *pp.Database End Sub Thanks, Chuck On Apr 23, 2006, at 5:13 PM, Mathieu Langlois wrote: > To clarify this, you need to call the super's constructor in your > subclass > constructor for a window to properly initialize (super.window). > You want to > put your initialization code BEFORE calling the window's > constructor because > the the window's constructor triggers the open events. Also you > can't (well > at least shouldn't, it may work in some cases but it's a bad idea) > access > any of the controls before calling the window's constructor. _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 24.04.06 06:48 (Sun, 23 Apr 2006 23:48:18 -0600) |
| From: Norman Palardy |
|
On Apr 23, 2006, at 7: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 pp.Database > End Sub > > Thanks, > Chuck It does BUT I believe that the Open Events actually fire AFTER the constructor completes. I don't have a definitive reference for that but it does seem to be the case. However, I do usually call the super class constructor at the end JUSt in case _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 24.04.06 17:07 (Mon, 24 Apr 2006 12:07:58 -0400) |
| From: Charles Yeomans |
|
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 pp.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 _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 24.04.06 22:43 (Mon, 24 Apr 2006 14:43:02 -0700) |
| From: Charles Ross |
|
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 opp.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. However, if super.Window executes the control open handlers, the Constructor above should raise the NilObjectExceptions again, but it doesn't. Or am I missing something? Thanks, Chuck _______________________________________________ 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> |
| Re: Event Call Order |
| Date: 24.04.06 23:13 (Mon, 24 Apr 2006 18:13:10 -0400) |
| From: Charles Yeomans |
|
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 zpp.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> |
| Re: Event Call Order |
| Date: 25.04.06 00:08 (Mon, 24 Apr 2006 17:08:14 -0600) |
| From: Norman Palardy |
|
On Apr 24, 2006, at 3:43 PM, Charles Ross wrote: > > 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. > > However, if super.Window executes the control open handlers, the > Constructor above should raise the NilObjectExceptions again, but > it doesn't. > > Or am I missing something? Calling Super.Windows should cause all Open events in controls on the window to fire. If you do all your set up for the Window and then call Super.Window then all the open events will be able to access the Windows properties safely. _______________________________________________ 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> |
Links
MBS Filemaker Plugins - Besuchen Sie die JUZ Nickenich Webseite