Optimizing use of WebDialogs

I’m at a stage in the development of a project where I can easily change the way I’m handling WebDialogs, so would like some advice on some alternatives. Right now, I have a WebDialog that I dragged to WebPage1, which will likely be the only WebPage the user will ever see, as I move the user from full-layout WebContainer to full-layout WebContainer when I need to change the onscreen layout. When I need that WebDialog to Show for a particular WebContainer, I assign values to its controls and Show it. That’s fine.

I can think of a few other ways to do this, and wonder if any are more desirable for a Web app.

  1. I can drag that WebDialog class only to those WebContainers that will ever need it, instead of dragging to to WebPage1. This way, given that I’m careful to Nil all full-layout WebContainers other than the one that is currently loaded, that WebDialog will die when such a WebContainer goes Nil.

  2. I can refrain from dragging the WebContainer to WebPage1 or to any full-layout WebContainer, and just Instantiate it from its class and Show it as needed in code. But the docs, for some reason, tell me I should drag a WebContainer in the IDE to make it available. Maybe this is a Web app thing, not a Desktop app thing. I know it works without dragging it to WebPage1 or a WebContainer, but I have done what the docs say.

If I continue doing what I’m currently doing (dragging the WebDialog to WebPage1, making it available to all possible WebContainers that might be embedded in WebPage1, even those that never will use it), can I assume that WebDialog will not occupy memory, or take up bandwidth, before it is Shown and after it is Dismissed? If so, I might as well not change anything. If not, I imagine Alternative 1 above might be more economical use of memory and bandwidth, as the WebDialog isn’t even available for some full-layout WebContainers that might be embedded.

Or is this just nit-picking, because WebDialogs are very inexpensive to being with?

Well, that was way too long. Here’s the upshot here:

Can I assume that a WebDialog that is dragged to a WebPage will not occupy memory, or take up bandwidth, before it is Shown and after it is Dismissed?

You can check this in browser.
I would assume it is either sent to browser on first appearance of dialog or webpage and stay in browser until page is closed.

But this should not bother you.

[quote=356531:@Ralph Alvy]Well, that was way too long. Here’s the upshot here:

Can I assume that a WebDialog that is dragged to a WebPage will not occupy memory, or take up bandwidth, before it is Shown and after it is Dismissed?[/quote]
Dialogs that are placed on a WebPage or WebContainer are sent to the browser ahead of time. If you are really concerned with this, you can create an instance of the dialog using code and it’ll be sent when it’s created.

Dim dlg as New WebDialog1 Dlg.Show

You’ll need to create a delegate or use AddHandler to access the Dismissed event.

[quote=356552:@Greg O’Lone]Dialogs that are placed on a WebPage or WebContainer are sent to the browser ahead of time. If you are really concerned with this, you can create an instance of the dialog using code and it’ll be sent when it’s created.

Dim dlg as New WebDialog1 Dlg.Show

You’ll need to create a delegate or use AddHandler to access the Dismissed event.[/quote]

If I create an instance of its class, does it automatically go Nil after it’s Closed?

It will be destroyed when the last reference is freed.
This may include setting your own property with a reference to nil, as well as removing any event handlers and calling close method.

[quote=356566:@Christian Schmitz]It will be destroyed when the last reference is freed.
This may include setting your own property with a reference to nil, as well as removing any event handlers and calling close method.[/quote]

Am I being concerned about essentially nothing here? That is, are WebDialogs fairly inexpensive, so just dragging them to a WebPage or WebContainer is really an insignificant cost in memory and bandwidth?

That could be true, but depends on thee dialog content.

[quote=356566:@Christian Schmitz]It will be destroyed when the last reference is freed.
This may include setting your own property with a reference to nil, as well as removing any event handlers and calling close method.[/quote]

Ok. I have changed to creating an instance of the WebDialog as needed. Its Event Handlers are all included and configured in its class object, so I don’t create them individually on the fly. And when the user hits the WebDialog’s Cancel or Submit button, it’s Closed. I’m assuming its Close method makes it Nil, and I because I don’t create its Event Handlers when I instantiate it, I don’t have to worry about removing them.

Am I right about assuming I don’t have to remove its Event Handlers because I don’t create them when I instantiate the WebDialog?

I just noticed I can load the app with Chrome and check increasing and decreasing memory usage with Chrome’s Task Manager (found in its Window dropdown menu). That’s probably what you were talking about. I didn’t know that was available. So now I can test all this at runtime.

The Close method removes it from the browser but does not make it Nil. You still need to do that yourself

Hmmm. So I assume to Nil the WebDialog I have first must assign it to a Property, and then set that Property to Nil when I want to make that WebDialog Nil. But somehow it sounds like setting that Property to Nil at the end of the WebDialog’s Dismissed event would not work. I can’t imagine an object can Nil itself. Can it? If not, then I must Nil that property from a context outside the WebDialog.

Ok. I tested it out and see that if, when I instantiate the WebDialog, I assign it to a WebPage1 Property, then setting the WebPage1 Property to Nil as the last step in the dialog’s Dismissed event does work.