Get / Access all Window Classes In a Xojo Application

Hello everyone,
Is there a way to access all window classes (or all classes) from within an application, in order to find and access the objects in each class (e.g. window).
Maybe a combination of Introspection with something?

I would like to get a list of all labels, with their name and text properties from all the classes from within an application, in order to implement a localization exercise…

Any help is greatly appreciated.

You can only get a list of objects created. From a running application, you can not get a list of all objects that may be included in your application. Further, if any object isn’t used in your application, it may be stripped from the compiled application as dead code.

Can you expand a bit on what you wish to do with all of these objects, labels, etc? Maybe there is a different way?

Thanks Jeremy,
I have an sqlite database that holds the localization data (part of my framework). Now if I want to include another App to be localized, I am searching for the fastest / more efficient way to get first of all the objects from all the classes that should be localized. I thought that this could be done by a method that could “scan” all the classes (Windows & Containers mainly) and populate the sqlite database with all the “missing” entries that should be localized (like the aLabel.text in a window). This could help a lot, to get most of the job done.
Then I have a tool, to create the localized translations for each entry…

I suppose I could add a function, so that each window that is opened, could fill in this database if I cannot access non-instantiated classes (like windows and containers).

Of course there is more work to be done with messages and other, but if I get the biggest part out of the way, it will help…

You could make a Label subclass that looks up it’s localization on open (and then raises the open event of the subclass). Set the super of all the labels needing localization in the project to the new subclass.

Thank you Jim for your reply.
What I did so far is to make a class that has Window as its superclass, override the constructor and call the localization method that scans the control and localizes the .Text or .Caption properties respectively. Now all actual windows have this class as their superclass and it seems to work fine. The same technique I am implementing with the container. Do you think that this may cause a problem?

I have a flag that is set in debug mode to fill missing localization entries in the same way, and I thought that this would be the easiest way to implement it…

What do you think?

That sounds like a good solution, the only issue I see is that in the constructor the Controls may not be ready and result in crashes/exceptions. I would suggest using the Open event rather than the constructor in the Window class to ensure that the controls have all been created before you try to manipulate them.

It seems that since the Super.Constructor is run before my methods, the objects of the window are constructed (I don’t think they need to be instantiated).
So far it seems to work both for getting the objects to add localization entries, and to change the localized properties…
But I will check it thoroughly.
Do you think that it might not work, even if it seems to work now?

This won’t work AFAIK. After the constructor is called the values set in the IDE for the properties are applied. So if in the window editor you set a MyLabel’s Text property to “ABC” and you do this in the constructor:

Class MyLabel Inherits Label Sub Constructor() Super.Constructor() Me.Text = "DEF" End End
… you will have “ABC” after the window has opened. Alle the IDE properties are set after the constructor, but before the open event. So you better use the open event.

Thank you Eli for your reply.
In my tests, both the window title retains the localized text, as well all the controls.
I think that happens because the change takes place in the class level and not the instance level? It is after midnight here and maybe I am talking nonsense, but the tests seem to work so there has to be an explanation…

However, I will probably implement the actual localization in the Open event of my Window Subclass to avoid any possible trouble.

Thank you Jean-Paul. I will check it out as soon as possible.

[quote=195796:@Eli Ott]This won’t work AFAIK. After the constructor is called the values set in the IDE for the properties are applied. So if in the window editor you set a MyLabel’s Text property to “ABC” and you do this in the constructor:

Class MyLabel Inherits Label Sub Constructor() Super.Constructor() Me.Text = "DEF" End End
… you will have “ABC” after the window has opened. Alle the IDE properties are set after the constructor, but before the open event. So you better use the open event.[/quote]
Eli, the Open event is called as part of Super.Constructor, so the line Me.Text = "DEF" happens after the Open event. Fotis’ method should work.

This is not true – just test it. As I said: all control properties set in the window editor are applied after the constructor and before the open event.

I did test it and I’m not seeing that. I do recall some report of weirdness related to values set in the inspector, so maybe we’re talking two different things. But Window.Open is called before Super.Constructor returns. Code after Super.Constructor occurs after Window.Open. But it is possible that values set in the inspector are applied even later than that.

Sub Constructor()
   Super.Constructor
   Break    // happens 2nd
End

Sub Open()
   Break   // happens 1st
End

My test show the same results as Tim says. The super.Constructor is executed first, then The Open events and then the subclass constructor. Also, the values don’t seem to change (back to the original values) as well. In any case, and since the Open event seems to run before the subclass constructor, if the values were reverted at a later stage the whole exercise would be impossible. Fortunately this doesn’t seem to be the case.

Thanks Tim for your reply.

I’m on OS X and this does not happen.

My steps are:

Create a new desktop project
Insert a new class and name it “MyLabel”
Set Super of the class to “Label”
Create a Constructor in MyLabel and add the code:

Super.Constructor() Me.Text = "DEF"
Drag MyLabel onto Window1
Run

The label will show “Untitled”, not “DEF”.

I think that is the order:

For all controls Control Constructor Control IDE property settings are applied Control Open event Next Window Constructor Window IDE property settings are applied Window Open event
Subclassed controls and windows behave the same.

[quote=195878:@Eli Ott]I’m on OS X and this does not happen.

My steps are:

Create a new desktop project
Insert a new class and name it “MyLabel”
Set Super of the class to “Label”
Create a Constructor in MyLabel and add the code:

Super.Constructor()
Me.Text = “DEF”
Drag MyLabel onto Window1
Run

The label will show “Untitled”, not “DEF”.[/quote]

Hi Eli, what I am doing is a little different.
I create a class (myWindowSuperClass) and set its superclass to “Window”
I add a method I name “Constructor” which automatically puts in the beginning the code:

// Calling the overridden superclass constructor. Super.Constructor
Beneath that I add the call to my method

self.Localize()

which performs the localization which is a method in my subclass that iterate through the controls and uses introspection to get the window class-name and determine what localized value to use for the window title.

Now I create a Window (myWindow) and set its super to myWindowSuperClass.

Now when I “open” myWindow, when the method Localize is run, the Open event (of both my superclass and the window class) is already run (as well as the Open event of all controls). And the values (both for the window title and the controls Text, Caption, HelpTag etc.) stay with their localized values.

You see this is different than what you posted probably that is why it works.

[quote=195887:@Eli Ott]I think that is the order:

For all controls Control Constructor Control IDE property settings are applied Control Open event Next Window Constructor Window IDE property settings are applied Window Open event
Subclassed controls and windows behave the same.[/quote]

This looks conformant to what Norman said to a question I asked back in 2014 about events order :

[quote=108763:@Norman Palardy]Controls get their open event before the window
Thats about all you should rely on[/quote]

From what I read in Fotis last post, it looks as his localize method is run much later than the controls constructor, so it should work fine.

Yes. I was testing a Window subclass, not a Control subclass, based on the info the OP gave.

Yes Michel and Tim. It seems to work without any problem…