The project information window is specific to the type of project currently being worked on. This
overview explains the options available to the Arexx project.
Top Tip
While you can type a path into the relevant string gadgets, a file requester can be
invoked by clicking the
button making it easier to select paths from the resulting requester.
General Settings
The General Settings allow basic options to be set, the following
is a complete description:
Project Name
This sets the name of the project which will be displayed in the title of the CodeBench
screen and the project window. It is also used as the name of
the project file on disk, which will be added to the recent list.
Project Base Directory
This sets the base directory that all files will be loaded from. Files can be loaded from
anywhere, but this directory will always be the default in the file requester when
adding files.
The Synchronisation settings allow you to configure how the file in
your project interact with remote servers.
This project uses a local file repository
Specify if this project should be synchronized with a remote file server.
Synchronise plugin name
CodeBench currently includes plugins for CVS and SVN use. These are by no means complete, and as such
a developer kit and documentation is included to allow further development of these plugins. The
SDK includes an example, which when compiled, creates the cvs plugin supplied. The SVN plugin is also
based on the same example code but is slightly more advanced as it offers a system to get the user name
and password via a prompt requester. Once this option has been selected, the plugin then does its job,
and it runs synchronously meaning that CodeBench will wait until the plugin has finished transferring
files. Please see the example documentation in the
"sdk/synchronising_plugin"
directory for more information. Manual synchronising is done via the
"Synchronise" menu item.
Check for repository update after loading
If the current project being loaded is specified to be synchronised with a remote repository, then this
option will automatically scan that repository to determine whether any files need to be updated into
the local "working" copy before proceeding with the project.
Check for repository commit when closing
Again, if this project uses a remote repository, then this option, when enabled, will check to see if any
files in the local "working" copy have been changed and should be committed to the repository
before closing the project.
As an added bonus, a fully featured plugin has been included for use with SVN servers, and more details
can be found here.
The Environment settings specify ways to affect the environment that you will be working in. There
are three sections, the first deals with how the "Quick-Link"
window is presented. The second affects how the editor interprets lines after to automatically
indent/outdent lines, and the last deals with code
"constructs".
The "Quick-Link" window section
Identify bookmarks by this string
This is the symbol string that the user may embed into the source file. When this sequence
of characters is found, the text that comes after it is treated as a
bookmark. This is useful for marking certain areas of
files so that the location can be revisited quickly. The marker needs to be suitable as to
not interfere with the general syntax of the source file.
Fold functions/procedures section
This setting will allow the function section in the "
Quick-Link" window to open in the collapsed state. This
setting is relative to the current state of the associated section.
Fold bookmarks section
This setting will allow the bookmarksection in the "
Quick-Link" window to open in the collapsed state. This
setting is relative to the current state of the associated section.
This section is comprised of two lists, the first for adding indentation and the second for
removing indentation. Both lists work in the same way, so we shall describe them both here in
the same context.
Adding items can be done by clicking on the or
buttons to add to each list respectively. The resulting requester
asks for a string of characters with which a match must be made for the appropriate action to be
taken. Due to the highly versatile nature of programming languages, in order to simplify this
process, the strings can include wildcard patterns exactly the same as used by AmigaDOS. This
allows a level of flexibility which should meet the needs of even the most demanding rules. Most
languages use braces to delimit sections of code, and the general programming standard is to
indent the code inside the braces, which can now be automated. Adding an "{" to the
indent list will cause the cursor to be shifted in by a certain amount of columns depending on
the size of the "tab" set. A "tab" can either be a real
tabulation character, or you may opt to insert a series of space characters instead, it is
entirely up to you.
To add flexibility, we can also add a string like "case #?:". This follows the
wildcard convention and results in any line ending with a "case" statement
should automatically indent.
Items in either list can be removed by simply selecting them, and clicking the
button.
All of the settings in this section (with the exception of the width of the TAB -
which is project specific) are applicable to the current project type, rather than
the project itself. This means that the configuration of these lists will apply to all projects
that use the same plugin, and saves having to configure the indentation settings for every
project.
Different project types can have different indentation settings, and gives the user full
flexibility over indents and outdents.
The width of the TAB (whether it be a real tabulation or spaces) is a project
specific setting which defaults to 4 columns. This allows the user to configure different settings
for different projects, which may be useful when sharing code with other developers, or when using
different project types.
Edit New File Header
When you ask CodeBench to create a new file for you, it includes a section of text at the
top with some default information pre-filled in. By clicking the button, you can edit just what information is included in that header.
As you can see from the default header shown here, the most popular information has been included already.
The list on the right hand side includes all of the "Cookies" that can be inserted into
the file header for you.
Simply double-click any entry in the list to have it inserted into the text at the current cursor location.
Once you have saved it, this custom header will be used whenever you create a new file for use in this
project.
Edit Constructs
You may envoke the construct editor from here. More information on code constructs is
available from the editor page.
The File Recognition section allows you to tell the plugin what scripts
are to be recognised as Arexx scripts.
As the only requirement for an Arexx script is that it MUST start with a comment, this makes
it very difficult to determine whether a text file is actually an Arexx script or not.
Arexx is used by many applications available for the Amiga, but unfortunately most applications
seem to use their own naming system for their scripts. Therefore, the only way CodeBench can
recognise an Arexx script is by its file suffix. Because of the vast amount of possibilities
this presents, the plugin allows you to define file suffixes that CodeBench should recognise
as being an Arexx script.
By default, ".rx" and ".rexx" are defined, which seriously
limits the range of loadable scripts. To increase that range, we click on the
button where we can add a suffix.
As the name suggests, the first gadget is where you enter the actual file suffix. Make sure
to enter ONLY the suffix (for example: ".amirc" or
".yam"), do NOT enter any pattern matching characters, as these are
added internally by CodeBench when trying to find matching files.
The second gadget is any optional comment you may want to add. As previously mentioned,
applications tend to use a naming convention that roughly matches the script name to the
application, so most scripts are quite obvious as to which application they are appropriate
to. In the case of the more ambiguous suffixes, the comment added here is shown in the main
list on the general page (as above).
Once you are happy with your addition, click the button, and the new
suffix will be added to the main list.
File suffixes you add here are not only applicable to the current project, but any
project that uses the Arexx project type. This saves having to enter the same information
for each and every Arexx project you create.
These settings allow customization of the "Help-as-you-Type" system.
The "Help-As-You-Type" section
Enable "Help-as-you-Type"
Naturally, this option turns this feature on or off as required.
The Dictionary section
The button allows changes to be made manually to the dictionary. You can edit
existing entries, or create new ones from this window. Any manual changes you may make will be lost
if the dictionary is remade.
The Lextras section
The button allows lexicon "extras" to be added to
the current dictionary without the need to fully rebuild it. "Lextra"s are simply
XML files which contain a set of help definitions that are applicable to a particular library.
Examples of this might be the RexxSysLib or some third-party library, and would contain detailed
help for each command within it.
A file requester will appear after selecting this option asking for the path to the .lextra file,
and once loaded it will start the process of adding the contents of it into the dictionary. It is
advisable to keep copies of any "lextra" files that may be downloaded, as these
will probably need to be added again in the event that the dictionary is rebuilt for any reason.
button making it easier to select paths from the resulting requester.
