In my web app I have two properties that I use throughout different events on the page. I have instantiated the properties in the page open event but am getting an error in my listbox open event where I use the properties as it says that they are nil which leads me to believe that the page open event has not yet fired. Can someone tell me which order the open events fire in or where I should instantiate the properties to ensure that they are available to all the events on the page when they get fired.
Unfortunately it’s a bug. The control open events fire before the WebPage.Open event does, and the order of the control Open events is undefined.
Is the solution to move all the code to Page.Open?
What I have ended up doing is to move the properties into session properties and then Instantiating them when the session opens. For what I am doing this actually works better because I will reuse the content of the properties on different pages but I can see this might be a pain going forward. Greg, is it planned to fix this bug any time soon?
Ok, I spoke too soon as I have run into an issue of not knowing which open even fires first. I want to connect to a database in the page open event so that all my queries to the database that I do to populate the page are done using the same connection to the database. At the moment I have a number of methods that each establish their own connection to the database which isnt ideal. So how do I know where to put the code to establish the connection to the database if their is no consistent open order as I dont want to move all the code from the methods into one page open event as it will make it a nightmare to maintain.
So I checked this in the framework. the Open events of the controls fire before the Open event of the WebPage, which is the same way it’s done on the desktop.
I would connect to the database in Session.Open, and store a reference to the database on the session. Lets say your property is named “db”, from then on you’d reference it as “Session.db”
Greg, I did think about doing that but it become messy because the session could last for a few hours and I would be concerned that if we had a blip with the internet connection then would we then have to reconnect the database connection? Plus if we have say 50 people using it at a time then we have 50 db connections open whereas if we do at the page level then we are creating and closing the connections when they are not being used.
If you’re using a database like Postgres or MySQL keeping open connections doesn’t hurt anything. It takes time to open one each time you need it.
A blip in the Internet connection would probably cause Xojo to disconnect the client as well. Still, you can lose your database connection over time due to timeouts or other issues. For that reason it’s a good idea to check it before using it. If your pages ask Session for the database and do not worry about managing (i.e. closing) it, then you can have a Session method which checks for you and returns the existing connection if open, or a new one if the old one closed.
That’s not always the best pattern though. Just depends on what you need and whether or not you are running queries from Threads any where.
Thanks Daniel, will give that a go.
As an aside, thanks for the help with WCC, I am really using it now with a vengance in my web project and growing to love it more each day. It really is a brilliant product especially the WebStyleTD (once you get your head around it 
Thank you!
Now if I can just finish 1.4 (so little left on the to do list!) and 2.0 (running on the official WebSDK) and get them out the door.
So will the 2.0 release be Xojo Framework compliant?
Yes, with the caveat that some non-control stuff will still be outside the formal SDK/framework. All the controls will be compliant. But there’s some non-control stuff in Web Custom Controls that’s very useful, falls outside the SDK by nature, yet is reasonably safe. I’m not going to remove any of that.
Great, just have to wait for the new version that support the Xojo Framework in Web Apps. Hopefully it wont be too difficult to move port old web apps to the new Xojo Framework and the new version of WCC that uses it. Time will tell I guess
Shouldn’t be the case of introducing a new Event to give the power to a more refined flow control to the users, like:
Today is something like:
initPage()
initControls()
EventOpen()
With a new model:
initPage()
Event_BeforeOpen() // Pre-actions, before controls creation, like setting some properties
initControls()
Event_Open()
Rick, I have to agree that the current model is a real pain because you try and put all your control related code into the appropriate control events but the way it is now you have no idea if properties have been set etc. I guess the way around it is to create a method that you call on every control open event and the method checks if the properties have been set using a flag property and if not then it does the setup. This is really messy and the idea of having an event that fires before anything else would be much cleaner and much easier for newbies to understand because right now I feel totally lost as to where to initialise things for a page.
Another non-intuitive trick is to use a Timer that does the setup. You can set it up in Open with a Period of 1 or something, and Timer code will fire after the page is already displayed. Not appropriate in all cases, but sometimes helpful.
Yeah I do use that trick sometimes but the stuff I want to do needs to be done before the page is shown. I find it hard to believe that this opening order issues does not cause people major headaches when creating web apps or does everyone just use hacks to get around it?
Is their any chance that this is going to be fixed in any release soon?
Abusing of Timers is like creating a world of asynchronous future events. Great tool for future unknown behaviors (and some latency) 
Needing timers = more complex solution designs = more potential weird asynchronous unknown behaviors.
I believe the Xojo Engineers should take a look in the current Event flow and see if such small redesign suggestion could be a beneficial resource.
If it wasnt for this forum and the help provided then if I had come across this and thought that I had to use timers or some other hack then I may well have walked away and used some other programming language. Hopefully the engineers will look at doing something sooner rather than later.