S T R U C T O R I Z E R - User Guide
Preferences > Export

From the "Preferences" menu you can open the "Export Options" dialog where general or target-language-specific preferences for the code export may be configured:

Export options dialog

What do the options mean:

  • Character Set (only versions 3.24-06 and later; before the code was always exported in ISO-8859-1 encoding)
    You may control what character encoding to use on export. Usually one of ISO-8859-1 or UTF-8 would be most appropriate (at least in western or central Europe). While "List all?" isn't checked, the choice list will only offer you about six of the most common character sets. But by enabling "List all?" you will be offered several dozens of encodings, i.e. all your Java version will know of.
  • Favorite Code Export
    If you often export code to a favourite programming language, then it may appear too cumbersome always to click through the menu "File => Export => Code... => Java" (for example). This configurable short-hand for a preferred or frequently needed target language. It is present directly in the File menu and via accelerator key <Ctrl><Shift><X>:
    File menu with marked favourite export menu item
    With export option Favorite Code Export you can select the target code for that menu entry and accelerator key.
  • No conversion of the expression/instruction contents (for all target languages)
    Though Nassi-Shneiderman diagrams are basicly syntax-free and rather rely on structure, some Structorizer features like Executor and Analyser accept and work with a (somewhat eclectic) HLL syntax, aspects of which are described in the Executor page. Consequently, Code generators also derive the target code under the assumption that instructions and expressions are written in that executable and analysable Structorizer dialect.
    This causes of course trouble if the text contents of the diagram elements have already been written in the syntactical conventions of the intended target language. In this case, Structorizer would spoil the ready text on export, trying to convert it again under false assumptions.
    So if you work and document explicitly for one favourite language and used to fill in the element texts already according to the specific target language syntax then you may activate this checkbox, causing only the structural (and closely related) conversions but no (or only minimum) translation of the instruction lines, conditions etc. It is a kind of "raw export", particularly valuable for dedicated shell script development (because shell syntax is practically incompatible with HLL syntax conventions).
  • Export instructions as comments (relevant for most target formats):
    If this option is enabled then the code of Instruction, Call, and Jump elements will be exported as mere comments. (Otherwise a conversion or translation to the respective target language will be tried; see also "No conversion of the expression/instruction contents" above).
  • Put block-opening brace on same line (relevant for C, C++, C#, and Java):
    This option is related to the code style of compound instructions in C-like languages. If the option is activated then blocks will start (i.e. the position of the opening brace) at the end of the commanding line, e.g.
    if (c == 0) {
        a = 17;

    Otherwise, the blocks will start at the beginning of the next line (indentation rules preserved, of course):
    if (c == 0)
        a = 17;
  • Generate line numbers on export to BASIC:
    BASIC (Beginners' All-purpose Symbolic Instruction Code) has developed numerous dialects from the very beginning. There are worlds between the first versions (about 1970ies) and some modern derivates with object-oriented enhancements etc. that hardly remind "good" old BASIC at all (Microsoft VisualBasic may serve as an extremely drifted-away example).
    So it's nearly impossible to refer to BASIC as a specific language. Correspondingly, a code export to "BASIC" is somehow a joke. We try it nevertheless.
    The option here partitions the BASIC world roughly into
    1. the ancient types with mandatory line numbers and very restricted subroutine support ("typical" BASIC), e.g.
      10 REM This is an example of early BASIC
      20 LET C = 5
      30 ...
    2. and some more up-to-date style without line numbers, but with some generalised variable declarations via "dim ... as ..." etc., e.g.
      Rem This may serve as an example for modern dialects
      dim C as Integer
      C = 5

    (Be aware please that this mode doesn't combine well with mode "Involve called subroutines" due to the limited gaps between numbered lines where subroutines usually won't fit in.)

  • Involve called subroutines (since version 3.24-13):
    If this mode is active and your diagram to be exported contains Call elements then the code generator looks for available matching diagrams (in the Arranger) and includes their code into the export. This way, if all required subroutine diagrams are found, the generated code will contain all necessary routine definitions to get the code runnning (after the usual manual post-processing).
    This option applies to all languages offered for export. The subroutine dependencies are analysed and a topological sorting is attempted, i.e. the code of subroutine precedes that of its caller. Most compilers require this order. (Be aware, though, that the resulting code for e.g. BASIC with also switched-on line numbering may be dysfunctional because the numbered lines do not easily allow the insertion of larger bunches of code from a different place).

From version 3.26-04 on there is a second tab on the export options dialog, allowing to configure lists of files or modules to be included by the exported code, i.e. on exporting a diagram to source code, the code generator will insert include directives, import or use declarations if there are some configured entries in the text field for the respective target language here:

Export options dialog

  • For a certain target language, fill in a comma-separated list of entities to be placed in include/import/use directives. What the entities mean and how the respective directive looks like depends on the target language. This configuration opportunity is thought for the case that you might produce a large number of diagram exports to a specific target language where always certain user-specifc file includes would otherwise have to be inserted manually for each them. The example above shows a version requirement for Perl that would look like
    use 5.6.1;
    in the produced code, whereas on C export you would obtain the two following lines near the top of the file (similar with C++):
    #include <stddef.h>
    #include "mumpitz.h"

    On export to Java, the file would be forced to contain a line
    import javax.swing.*;
    (The generators are usually not capable of producing different kinds of directives for a single language - one might want to have both #include and using directives for C++, but the latter isn't supported).
    Note that these include options will only be considered in interactive mode, in batch export mode they will be ignored.

Further options may be added on user demand.