Where do I find the doumentation for the xojo_project file structure?

For my (general porpose) programing tool I would like to check the internal correctness of the generated code (no syntax, but structure!). For this purpose I would like to know the capabilities of the files saved (and loaded) with the xojo_project file structure.

I had a look at the docs but I did not find anything. Is there any structure or DTD like stuff available? I would appreciate very much if someone could help me there.

It’s not documented.

1 Like

Thanks for the quick and short answer though not really satisfying. :slightly_frowning_face:

So do you see any chance? Is it documented internally? There is a lot of stuff in there I could guess only …

Or do I have to analyze (test) and set it up for myself and then publish? :grinning:

2 Likes

For the tools I made to work with the source files, I just dug through it and figured out what I needed. There are some things I haven’t done but that’s really more because I didn’t need them rather than being difficult to figure out. For the most part, xojo_project and xojo_code files are very straightforward.

I would have said “it’s private” … :wink:

2 Likes

IF this is “private” it should be called private. For my tool I would like to have it. If I do not get it I will produce my own.

What would “private” mean? That I am not allowed to change the structure of my output and code files? How far would this go?

I think it would be a great advantage for XOJO to have a code generator (beside ARgen, which I like very much). There is already my CAPP, which will be extended, also written in XOJO. But I should not rely on that if changes can happen at any time which are not included in the release notes.

Anyhow I want to build the structure of an app completely from scratch with my design tool. And this will be much leaner as the XOJO IDE - though easier to use hopefully.

So PLEASE all - think about that issue!

You can generate your own code that you save as text or xml, if you don’t have pro you can see the format via some github projects.

The binary format isn’t documented as it’s there as a licencing feature to promote sales of higher tier licences so it’ll never be made public by Xojo unless they change their licencing.

Be sure you review the EULA. Creating a derivative IDE may mean you need to have a discussion with Geoff and work out a contract.

3 Likes

Friendly reminder of the EULA

With the understanding that:
…
• You won’t create a derivative of the Xojo IDE, frameworks or compiler.

I’d recommend a private discussion with hello@xojo.com to discuss your needs. They’re friendly, understanding people and we need to be respectful of their intellectual property.

5 Likes

You may already be aware of that, but in case you’re not, here’s an extract of the Xojo EULA:
• You won’t create a derivative of the Xojo IDE, frameworks or compiler.
• If you are creating a development tool, you will include the “Made with Xojo” logo.

Just for your information.

We all may have written code generators to create Xojo project items automatically.

That is not against the EULA.

1 Like

That doesn’t appear to be what he is doing though. As Tim suggested a quick email to Xojo to make sure everything he plans to do is allowed is a good first step

In general, the reason many companies to not publish formats is that creates an expectation by some people it won’t change. By keeping it unpublished, they can make changes to the format and not potentially break somebody else’s code. If they had to publish and not break backward compatibility, I suspect their own development time would be at negatively impacted.

My suggestion is to use a format other than the binary project format. Although that does take higher than the $99 license level.

My personal preference is for the text format, due to higher compatibility with version control systems (I use GIT) and easy differencing even if not using a VCS.

Just my .02; I can’t/don’t speak for Xojo.

1 Like

The OP appears to be Pro and did ask for info on xojo_project not xojo_binary_project structure.

Oops, he did. My bad…

Even so, documenting the format would create the expectation of forward compatibility. By not documenting the file format, it gives Xojo the ability to allow you to create code generators, but at your own risk. There is no guarantee your code won’t break if they change the format (and they have - and my code broke, but I couldn’t complain, because it wasn’t documented).

1 Like

Except it’s not friendly when you misquote the EULA, there is nothing in the agreement which prevents you from writing a code generator as you well know.

I copied directly from the EULA tab from the About window of 2020r2.1

I’m trying to suggest the respectful route of contacting Xojo directly to resolve matters. They are the ones who can decide if OP is in violation of the EULA.

3 Likes

Arnaud,

yes, I know.

• You won’t create a derivative of the Xojo IDE, frameworks or compiler.

This is not my intention. I am going to design an completely different approach.

• If you are creating a development tool, you will include the “Made with Xojo” logo.

Sure. This is what I have already done. I presented my first version of CAPP at the conference in Miami. Geoff knows it and I hope he likes it. I would never violate the license restrictions by purpose.

Thank you for your valuable warning!

1 Like

Thank you Tim, you are right. Xojo knows my approach.

2 Likes