Implicit Instance

I am using Implicit Instances in a web project (I have read the other posts about pros/cons) and just want to check that my understanding is correct,. If I have a page called “frmMain” and a button with an action so that on click it runs the following code to show the page “frmTest” and then to alter the value of the text field on the new page called “txtMyText”. Will this work show the page and then change the value of “txtMyText”? Ideally I would like to change the value before the page is shown but cant see how I can do this when using Implicit Instances.

frmTest.Show frmTest.txtMyText.Text = "Hello World"

That is correct. On desktop you could simply reverse those lines, but I don’t know if that will work for web.

Nathan, using implicit instances means your pages exist before you use ‘Show’.

So you are safe to manipulate their content whenever you want.

Regarding changing the values before the page is shown, you have to understand, with WE, that your code is evaluated once you reach the end of your Method. So setting the Text value before Show or after has no impact, it’s the same. Your new value will be there once the page is shown.

You can even use:

frmTest.txtMyText.Text = "Hello World" Session.CurrentPage = frmTest

Cheers,
Guy.

Thank you both for the info, that makes it much clearer for me and explains a lot. Guy, can I just ask why you would use the “Session.CurrentPage = frmTest” over “frmTest.Show”, I have seen people do this before but am not what the difference is.

Well, I guess it just depends on how centric your vision of your application is.

On my side, I have a Session centric vision of the application, so to me, when the HashTag change or the user do a specific action, the session is modified in order to respond to this action. I don’t think in terms of ‘pages navigation’.

Yet I rarely change the WebPage, actually, as in all my web applications I only have one main WebPage ( I have some other for errors, maintenance, admin, etc… but aside from those, a all website is ‘contained’ inside (or should I say ‘displayed’ through) one WebPage, then I rely on embedded WebContainers).

The only place where I really use Session.CurrentPage is at Session.Open time, to decide where to ‘redirect’ the user according to the Host domain name (in my ‘radfac’ case all my websites, radfac.com, radfac-innovations.com, soon radfac-productions.com etc… are all in the same application on the same server/IP, so my application acts as a multi-domain server).

Internally to Xojo, I’m not sure what the differences are between setting Session.CurrentPage and calling WebPage.Show(). I guess WebPage.Show() is setting Session.CurrentPage ultimately.

Guy that is really interesting. Do you think their is any advantage of using a single page and then apply containers rather than having multiple pages? If your UI is similar on each page I could see why you you would do it on a single page but otherwise I was wondering it their was any speed or memory improvements doing it your way?

Well, if all your ‘pages’ are completely different, I guess you don’t get much advantages having WebContainers over WebPages although it is certainly ‘lighter’ to instantiate WebContainers rather than all WebPages.

In my case though there are always similarities among my ‘pages’. I have a header bar including the menu, which is a WebContainer, then a ‘PageWrapper’ for the content and all the different sections contents are other WebContainers. It would be silly - in my case - to create one WebPage per website section, I would then have to duplicate my menu bar (and my page wrapper, and my background resizable gradients, etc…) and create a WebPage for each section of the website. Totally inefficient, especially if I have to move one of those containers, I would then have to go through all the WebPages.

Also, on the cosmetic side, using WebContainers allows me to smoothly reveal or hide them through Opacity animation and this independently one from each others.

That said, I’m not pretending my approach is the best, I’m sure there are other types of WebApplications where having several WebPages makes more sense. I’m just more comfortable with the WebContainers approach as this perfectly suits my needs and my Session centric vision ( even if it is a bit tricky to dynamically embed WebContainers with the right chain of events and timing :wink: )

Dynamically embedding WebContainers can be slow. I don’t recommend if you have to do a hundred or so at a time - it’s just too slow.

Xojo apps really only has one ‘page’. When you’re using a new webpage in your app it’s simply reformulating the HTML and pushing it to the browser. So whether it’s a new WebPage or changing WebContainers it’s still changing that ‘one page’.

Thanks Bob.

Guy, its interesting to see the different ways people are using Xojo WE, in hindsight I think I should have made some of my menu pages as one page as I have duplicated formatting but luckily I dont have too many of these whereas I have about 100 other pages that are all different so these for me work better as different pages etc.

On a web app it would most likely fail with a javascript error (the first time at least) because the app hasn’t created the controls yet. When you change a property on a control it’s sending a javascript command to do so. If the control isn’t there it generates the error.

This is why using the Shown event is much safer than the Open event. The Shown event isn’t fired until the controls are made. And even then if you work with Dynamic web containers it’s still possible to get javascript errors because it’s not fully formed (sometimes) after the EmbedWithin event. Sometimes a very short delay in populating/changing the controls is necessary.

Bob, I’m not sure to understand your point here. I mean, hundreds of dynamically embedded WebContainers would be slow, of course, but compared to what ? Hundreds of WebPages ? Hundreds of WebControls in the same page ? I’m not sure this is a valid point against WebContainers.

In my pages I have at most half a dozen of dynamically embedded WebContainers and really, at least from my experiments, I don’t see any difference in speed rather than having to switch WebPages with the same content. In fact, from what I’ve seen, speed would be rather in favor of dynamically embedded WebContainers. But perhaps we don’t use WebContainers the same way, I don’t know.

I’m afraid this is not true anymore (and I’m tempted to say: fortunately). That was true with RealStudio, but with Xojo, and from my recent experiments, this is not true anymore with Xojo. In the mentioned case, with Xojo, having Show() before or after setting the control text has no impact whatsoever as the javascript code is evaluated and sent only after the Method returns.

Here too, I have to disagree.
( sorry Bob don’t think I have something against you, it’s just the results of my recent experiments )

I recently had a few issues with javascript errors from actions taken in the Shown() event. Since I’ve moved those actions from the Shown() event to the Open() event, those errors disappeared. I’m not saying this is ‘normal’ or to be expected, but this is a fact. Xojo use some kind of caching mechanism to stack javascript commands and to send them at the ‘right’ moment (I’ve even used ExecuteJavaScript() from a WebContainer Constructor() and it worked without a problem).

It appears that, for now, the ‘right’ time chosen by Xojo to send those commands gathered from the Open event (and even ‘before’) is, for some reasons, more robust than when using the Shown() event.

Here I agree with you : -) And this is valid either you embed the WebContainers from the Shown() or Open() or even Constructor(). But again, on this specific issue, I have more problems with the Shown() event than with the other ones.

Sometimes I had to use a WebTimer to delay things, but triggering the WebTimer from the Shown() event does not always work as, sometimes, I got a javascript error saying that even this WebTimer is undefined ! This does not happen (at least so far on my side) from the Open() event. Go figure…

Well, I guess this is what makes Xojo so flexible and interresting on this matter, it does not enforce you to create your WebApplication a specific way. You have a choice of strategies depending on the situation or on your vision.

Well, my experience says that the Open event is a very bad place to change properties on controls. However, if everything works perfect for you then great. I’ve had issues with anything that’s controlled by a WebStyle. Perhaps that’s the difference in our results.

My recent experience with several large WE apps is that embedding dynamic complex WebContainers at runtime is slow. For simple WebContainers you never notice it but for anything complex it can be quite slow. Don’t forget to test on a real web server as you’ll never see this latency while debugging when there is practically no latency.

In this case, my client couldn’t live with the delay when embedding them dynamically so we ended up putting them on the WebPage at design time. This delays the initial page show but then there is no delay as the user switches tabs (in this case).

Sometimes it’s all about compromises. But whatever works for you. As with most programming there are many ways to do it. I’m not saying my way was the best or only way, I’m just giving you my experience of using WE since using the pre-public beta.

I’m certainly not questioning your experience Bob, in fact I had the same with RealStudio over the past few years. What I am just saying is that it appears things have changed with Xojo recently on this specific point (even with anything controlled by a WebStyle), and my recent tests show this, that’s all.

[quote=83376:@Bob Keeney]…/… My recent experience with several large WE apps is that embedding dynamic complex WebContainers at runtime is slow. For simple WebContainers you never notice it but for anything complex it can be quite slow. Don’t forget to test on a real web server as you’ll never see this latency while debugging when there is practically no latency.
In this case, my client couldn’t live with the delay when embedding them dynamically so we ended up putting them on the WebPage at design time. This delays the initial page show but then there is no delay as the user switches tabs (in this case).[/quote]
I understand your point, yes.

When you say embedding dynamic complex WebContainers at runtime is slow, you present it as if WebContainers were flawed. In fact, if you put everything in a WebPage, the initial loading time wont be faster. Of course, if you put everything into a WebPage there will be (almost) no delay when the user switch tabs. This does not mean WebContainers are intrinsically ‘slow’.

I’m not sure how to put it in english without appearing stubborn or something.

What I’m trying to say is that if the client don’t want delay between switching tabs, obviously, putting everything into the WebPage will be faster at tabs switch time and this would be the right choice, but the loading time of the WebPage itself will suffer accordingly, inevitably.

It does not mean WebContainer ‘are slow’ per say, it means loading section by section is slower when the user switch tab rather than loading the all site at once.

This is an AJAX strategy issue, not a WebContainer issue, it doesn’t mean WebContainers are flawed/bugged and slow by nature, they have the same loading speed as WebPages.

It all depends on the quantity of data you put in there and the adopted strategy.

My point here is for the reader, especially for new Xojo users, who may read “WebContainers are slow” so they would completely avoid those thinking it is a bad idea to use them and definitively forget WebContainers. It would be sad, as WebContainers are great, they just have to be used the right way with the right strategy. And thanks Bob for pointing out those cases where they may not be the right choice.

No worries. I am a huge advocate of WebContainers. Use them all the time. You just have to be aware that it might not be appropriate in every situation.

[quote=83397:@Guy Rabiller]I’m certainly not questioning your experience Bob, in fact I had the same with RealStudio over the past few years. What I am just saying is that it appears things have changed with Xojo recently on this specific point (even with anything controlled by a WebStyle), and my recent tests show this, that’s all.
[/quote]
Not at all
Open is a bad place to try & manipulate controls as they may not be in the browser

[quote=83402:@Norman Palardy]Not at all
Open is a bad place to try & manipulate controls as they may not be in the browser[/quote]
I know Norman, that’s what everybody keep on saying : -)

But I’m sorry, my recent tests show otherwise. I had issues that disappeared by moving some ‘control manipulations’ from the Shown() event to the Open() event.

For instance, explain to me why, sometimes, changing a WebTimer mode from the Shown() event triggers a Javascript error ‘Undefined object’ while doing the same in the Open() event works every time (so far…).
(and I often had ‘undefined object’ from Shown() event control manipulations so forgive me if I’m a bit sceptical)

I can’t explain it, I’m not the one looking at the Xojo source code.

But facts remain.

Yet my site is online and I don’t get Javascript errors anymore (well, perhaps someone will ? :- )

[quote=83408:@Guy Rabiller]I know Norman, that’s what everybody keep on saying : -)

But I’m sorry, my recent tests show otherwise. I had issues that disappeared by moving some ‘control manipulations’ from the Shown() event to the Open() event.
[/quote]
All I can say is that you ignore the advice of the product engineers at your own risk :slight_smile:
It will probably work until it doesn’t and when it doesn’t everyone gets to say “we told you so”

[quote=83410:@Norman Palardy]All I can say is that you ignore the advice of the product engineers at your own risk :slight_smile:
It will probably work until it doesn’t and when it doesn’t everyone gets to say “we told you so”[/quote]
I understand Norman, no problem :- )

I always carefully listen to engineers, read documentations during hours and always do/apply what is recommended/advised… until… results prove otherwise. I’m not ignoring your advice on this by pleasure. It’s just I don’t have a choice to make it work.

Ultimately, what’s the most important ?

  1. Engineers advices ?
  2. Concrete results ?
    What one should do if results contradict engineers advices ? Blindly follow the advices ? Or apply the solutions that actually work ?

Any TED talk about this ? :slight_smile:

ps: If things change, no worries, I’ll adapt, I’m used to extreme programming.