Highlighted

Changing FM's Structure Directory

Adobe Community Professional ,
May 13, 2019

Copy link to clipboard

Copied

Trevor-Nicholls started a discussion last month on creating an XML document from the welcome screen (Re: Creating a new document from the Welcome screen, doesn't ). That discussion has grown to include several related topics, so I am splitting my responses in new discussions specific to individual subtopics. This is the fifth (and I think the last) such new discussion.

Trevor, you used maker.ini to change FM's structure directory in order to avoid permission issues when changing files within $STRUCTDIR. There's nothing wrong with doing so, but there are other ways to organize your files. In particular, you can place the files needed for your own applications in any convenient directories. They don't have to be placed in new subdirectories of $STRUCTDIR.

In fact, your application definition files don't even have to be named structapps.fm. I typically have a directory for each of my active projects; a directory named project1 contains a file named project1.app, directory project2 contains project2.app, and so forth. You can create such files by saving a structapps.fm under the other name. The problem with such naming, is that I have to remember to read application definitions from the appropriate file each time I switch projects, which I often do without restarting FM.

The advantage of keeping the name structapps.fm is that FM reads two files with this name each time it launches. First it reads the one in $STRUCTDIR, then it reads the one in the user's %appdata% area. Thus, if both the global application definitions in $STRUCTDIR and the local definitions in %appdata% define applications of the same name, the one in %appdata% is used. By keeping multiple application definition files, I don't clutter up my %appdata% file with definitions for multiple projects, nor do I have to worry about reusing the same filenames for different projects. If you are only working on one FM project, it might be more convenient to put the definitions in %appdata%. You might also give your users a file to put in %appdata% even if you maintain different application definition files for your own use.

--Lynne

TOPICS
Structured

Views

145

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Changing FM's Structure Directory

Adobe Community Professional ,
May 13, 2019

Copy link to clipboard

Copied

Trevor-Nicholls started a discussion last month on creating an XML document from the welcome screen (Re: Creating a new document from the Welcome screen, doesn't ). That discussion has grown to include several related topics, so I am splitting my responses in new discussions specific to individual subtopics. This is the fifth (and I think the last) such new discussion.

Trevor, you used maker.ini to change FM's structure directory in order to avoid permission issues when changing files within $STRUCTDIR. There's nothing wrong with doing so, but there are other ways to organize your files. In particular, you can place the files needed for your own applications in any convenient directories. They don't have to be placed in new subdirectories of $STRUCTDIR.

In fact, your application definition files don't even have to be named structapps.fm. I typically have a directory for each of my active projects; a directory named project1 contains a file named project1.app, directory project2 contains project2.app, and so forth. You can create such files by saving a structapps.fm under the other name. The problem with such naming, is that I have to remember to read application definitions from the appropriate file each time I switch projects, which I often do without restarting FM.

The advantage of keeping the name structapps.fm is that FM reads two files with this name each time it launches. First it reads the one in $STRUCTDIR, then it reads the one in the user's %appdata% area. Thus, if both the global application definitions in $STRUCTDIR and the local definitions in %appdata% define applications of the same name, the one in %appdata% is used. By keeping multiple application definition files, I don't clutter up my %appdata% file with definitions for multiple projects, nor do I have to worry about reusing the same filenames for different projects. If you are only working on one FM project, it might be more convenient to put the definitions in %appdata%. You might also give your users a file to put in %appdata% even if you maintain different application definition files for your own use.

--Lynne

TOPICS
Structured

Views

146

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
May 13, 2019 1

Have something to add?

Join the conversation