Although you can use any directory structure, we offer one here to use as a guideline:

There are several reasons why we recommend this structure or one like it:

• The more you break down your files, the fewer file contention problems you will have among your developers.
• Source code files, header files, and resource files are segregated to make it easier to navigate through the files.
• (This is more of a file naming convention suggestion.) In the resource/hooks directory, there is one .mc file (with the same root filename) for each .r file that defines a dialog box in the resource directory. This makes it easy to locate the hook functions for a dialog box.
• The resource directory's native language sub-directory contains resource .r files and header .h files that store all of the text string constants used by the application.
  Any language-dependent strings in .mc files are removed from the code and placed in a message list in one or more .r files in the native language sub-directory. The source code references the string's index in the message list to obtain the string at execution time.
  Any language-dependent strings in .r files are replaced with macros (#define) in a header .h file(s) in the native language sub-directory. They are defined as macros in a header file because the strings used in dialog boxes are needed at compile time by the resource compiler.
  There are at least two reasons why it is a good idea to separate language-dependent text strings this way:
• Messages can be globally changed without recompiling the source code - only resource source files need to be recompiled. This means the executable does not change, but rather just opens an updated resource file. This is useful if an application is used in countries that speak different languages. This is one part of a process called internationalization.
• The program's memory requirement is reduced since messages are only loaded as needed. Also, MicroStation has logic that minimizes the memory required by messages in message lists.