Can a control placed in a container that has been placed in a window know the name of the container?
The “Name” property is displayed in the inspector when building the form, but does not seem to be available to the code (no MyContainer.Name).
I would like to pass the container’s name up to the window so things in the window can know which container an event came from.
Have-you tried Control1.Parent ?
I did, but Control1.Parent does not have a .Name property.
and the value of .Parent is ?
Example:
I think I’ve found a workaround by just adding the Name property to the class, called NameAdded for this example, and assigning the name for each instance of the container in the Opening event.
Create a string property in your container called containerName, then in the container’s Opening event add this code:
Var t As Introspection.TypeInfo = Introspection.GetType(Me)
containerName = t.Name.Left(t.Name.Length - 1)
Now the control can read the property containerName.
Introspection just throws everything about a strongly typed language out the window when OP is clearly trying to solve a problem in the wrong way. We used to be very careful about who and when we mentioned Introspection for this reason.
That’s great, it looks like Introspection fills in the missing blanks. It’s also nice because the Naming code can go in one place.
I suppose the word “Name” could be used for the Property since it’s available for Containers. If Name does get implemented to give Containers a Name one day, this approach would squeak through as being considered overriding?
Re: Breaking the rules. Would using the original approach of executing the code in each Container from a Raised Opening event in the Class be more aligned with OOP principles?
Containers use Event Definitions to pass events to the parent. If you don’t need the event, you don’t implement an Event Handler on the instance.
I always recommend describing the problem you are trying to solve and not the technology you think you need to use. I don’t normally answer questions that don’t have enough information like this, but if someone mentions introspection it sets off red flags.
You haven’t described the actual problem your design attempts to solve.
1 Like
This is almost certainly the wrong way to go about it. If the window needs to know the source of the event, pass it a reference to the object.
What’s the underlying problem you’re up against? What events are we talking about - what does the window do in response?
if you define and send an event to the parent the object comes with and all his properies.
you can test with IsA the object kind.
if you add an interface you could ask the object via method as example .WhatIsYourName().
You can store in .Tag anything, its of type Variant.
You can add own properties and make them visible in designer via this menu:
via context menu we can add own groups and the properies can moved via drag and drop.
example if the container was placed in the window.
In most cases, yes.
But… if you need this information before the Container has opened, it won’t be there. Keep in mind the order of event executions are not guaranteed, but generally the Opening event of child controls of a Container or Window are fired before the parent Opening event.
Using @Christian_Wheel’s example of setting a property on the Container, it may work better in the Constructor of the Container, and done simpler, like:
Self.containerName = CurrentMethodName.NthField(".", 1)
1 Like
I am hacking out a text editor-ish container that can be dropped in one or more places in a window. It will have enough controls to decorate the StyledText. One thing I like to do is to hide the controls when an area is not being edited and doesn’t have focus. I’ve done this with a single instance in a window, but now I’m working on making controls hide when more than one instance is present in the form.
I’d like the container to do this hiding by itself rather than being told to, but containers don’t gain or loose focus that I can see, so I’m experimenting with doing it from the outside.
Yes, but the code never gets triggered with the switch set to on or off. I was thinking it was a setting not used for containers, or my idea of what focus means for containers is not right.
lose focus.
1 Like
How do you decide when to display your widgets? At that point, have the current container register itself with the window. That should be via a property of the window whose Type is your container type, not a name. The window can then operate directly on the container whose widgets are displayed. No need for a name at all.
Getting off topic about Container Focus
With two of these containers in a window, the container FocusLost event fires in one of the containers when the window first opens. After that, tabbing or clicking between containers does not fire the event. This is with “Allow Focus” on or off.
A while later after more testing by removing and adding the container to the window, it happens that tabbing between the containers now triggers the FocusLost event every time. However, clicking from one container to another does not trigger the event.
I’m not sure how I might have created this kind of wonkyness, but it is starting to feel like the DesktopSearchField problem, where sometimes just having a search field present causes the interface to misbehave.
https://tracker.xojo.com/xojoinc/xojo/-/issues/78428
https://tracker.xojo.com/xojoinc/xojo/-/issues/78527
Are they both part of the tab order?
i remember
this options/properties exists once in the container template and also in each copy in a window.
a change of the properties in the container template does not affect used copies in a window.