Best Container and object practices

Targets Web
1

Hello all,

I am building a new web app. I am wondering what the best practice is, with regard to bandwith use and memory use in the following scenario.

On a page, I use EmbeddWithin to create a Container Object - we’ll call it a ‘main container’ since other containers are placed non-progamatically onto this main container…

cntRemotes = New cntRemoteDevices
cntRemotes.LockLeft = True
cntRemotes.LockTop = True
cntRemotes.Visible = True
cntRemotes.EmbedWithin(Self, 411, 107, cntRemotes.Width, cntRemotes.Height)

Within the ‘main container’ other containers are placed non-progamatically onto the ‘main container’. These sub containers have many objects on them, including checkboxes, lables, textfields, popup menus and a web list box. There are other sub containers too so these objects add up.

My questions are -
Is it best to make all of those objects` Public in scope or private?

Which is better, to create the containers programmatically or placing containers onto a container or web page?

Is it necessary perform some action when closing these containers - especially ones that are made programmatically?

I’m looking for optimizations.

Thanks in advance for your ideas/help4

Tim

2

It is always best to scope as restrictively as you can. This makes it so that the compiler can find some kinds of errors for you at build time instead of runtime.

In general with Xojo, using the IDE to place controls at design time produces safer and more reliable results. There are use cases for embedding at runtime, so if the need is there the functionality is available. As someone with my contact details you are welcome to discuss project specifics with me.

Yes, if you’ve used AddHandler you need to use RemoveHandler.

Optimizing too early can actually back you into corners. Don’t look for optimizations until you have a 1.0 ready application. You may find you don’t even need to look for optimizations if you don’t have any problems.

1 Like
3

Hi Tim.

AddHandler is not used. EmbeddWithin is. I did not find anywhere where you have to do the remove function like that of AddHandler.

Tim

4

If AddHandler is not used, you’re all set. You would use AddHandler to handle an event raised by a container or control embedded with EmbedWithin.

The documentation for AddHandler has a note toward the end about the RemoveHandler, though oddly it doesn’t say why. @Greg_O might have an answer for that. This was one of those things I did because I was told to by staff. I had thought it was about retaining object references, but the last time I was playing with / testing that I couldn’t prove it.

5

Memory leak, is my understanding.

6

Correct. AddHandler creates a global reference to the target which can only be removed with RemoveHandler. So for every call to AddHandler, you must have a corresponding call to RemoveHandler somewhere.

1 Like
7

Another big problem with AddHandler is that you can’t tell if the event has been hooked to anything without triggering an exception like this:

Var alreadyConnected as Boolean = False
Try
    AddHandler myTimer.Action, addressOf myHandler
Catch ex as RuntimeException
    alreadyConnected = True
End Try

…and that also means that you can only connect an event to one target at a time.

8

Huh? I have a DesktopContainer within which (upon user request) any number of smaller DesktopContainers can be instantiated. These smaller ones each receive, via AddHandler, the same set of handlers for a set of events that are Event Definitions on the smaller DesktopContainer. This all appears to work without difficulty. Or were you referring to something else?

9

Just like in a regular class’s events, you can only handle it once. If you try to AddHandler to the same event more than once on the same object, you’ll get an exception.

So that can’t be what you’re doing. :wink: Sounds like you have multiple objects, even if they’re the same class, and you are handling their individual events with AddHandler. That’s fine.

10

Yes, each time I’m adding the same six event handlers, it’s to a new instance of the smaller DesktopConainer - as it gets embedded within the larger one.

Thanks - that’s a relief. If that had only worked “by chance” it would have eliminated a major feature of my app.

11

Not at all, there are other ways of implementing what you’re doing without AddHandler. But what you have works, so enjoy! :+1: