.xojo_project Manifest

General
1

I think this might require an engineer to answer or maybe someone has already reverse engineered the answer.

I’m building a tool to post-process my Xojo projects that requires me to read both Xojo XML project files and “Xojo Project” (.xojo_project) files and parse them into their respective items (class, modules, etc).

I’m almost done but there’s one thing I can’t reverse engineer and that is how to determine which item in a project is the main “App” object.

In XML project manifests it’s easy. The item will have <<IsApplicationObject>1</IsApplicationObject>.

In .xojo_project manifests however there is no such flag. There is nothing I can see about the App item to differentiate it from other items in the project. I’ve tried experimenting by changing the superclass of the App item but no new flags are set. It’s not the item with the lowest (or highest) ID. The ID varies from project to project so it’s not a unique magic number. I don’t think the IDE is walking the inheritance chain to see which is the App object because that could be fooled by simply having multiple classes inherit from DesktopApplication.

So basically I’m stuck. Xojo - can you help?

3

In my parser, I open the class files and inspect the super:

#tag Class
Protected Class App
Inherits DesktopApplication

#tag Class
Protected Class App
Inherits WebApplication

Of course that means you have to open each file in the entire project until you find it, but you’re probably doing some of that anyway.

4

I was doing that Anthony but it fails on many edge cases.

Here’s an example:

  1. Create a new project
  2. Create a new class (Class1). Set it’s Super to DesktopApplication.
  3. Change the App object’s Super to Class1.

Your method will fail because “App” is still the application object but it’s super is now Class1.

Since you can make many DesktopApplication subclasses this approach doesn’t work.

5

Well, there’s issues with having more than one Application object in a project, even if one is a subclass of another. I ran in to issues with my Windows Dark Mode implementation because of this, and don’t recommend having more than one in a project to begin with now. I’d share the case with you, but it’s private.

That being said, I don’t see how that would fail if you’re only looking for Inherits DesktopApplication. Subclasses should be Inherits Class1, right?

6

Yeah, here’s what my now-subclassed “App” file shows:

#tag Class
Protected Class App
Inherits Class1

If you want to unwind everything to get what was the default “App” object, you’ll need to load everything and walk all of the classes to determine that based on the supers, I think.

7

Interestingly, the default “App” object doesn’t have a #tag ViewBehavior section, while classes converted to DesktopApplication do. Might be a way to determine the difference?

8

That’s an approach. I shall investigate if that works…

9

Looks like there are edge cases with that approach to.

I’m starting to wonder if this is an issue with the text format. I suspect we will not hear from the Xojo team as this is a very esoteric scenario.

What I’m going to have to do is fudge it. I think I will find the first class that inherits from DesktopApplication. If it’s called “App” I’ll assume that’s the application object. If it’s not I will check for the first class I find that inherits from that class.

I’ll make sure to provide an interface in my app to allow the user to mark which object is the actual application object if this algorithm is wrong.

Why Xojo don’t just add a flag to the application object item in the text format (like they do in XML projects) I have no idea.

10

I agree, and there was a lot of discussion about how to handle multiple Application objects in a project when I ran in to the problems I did. I wasn’t thrilled with the solution and suggested similar things to what you are, but apparently there were some things in the IDE’s parsing to consider that I was unaware of.

1 Like