| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To select a window you can do the following. If the window has a number, this is right on the top-frame, you can select this window by pressing Alt and this number (but only if the number is a single digit). Or you click anywhere in the window or on the frame of the window with your mouse.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section should describe the work of the editor. But because the editor is now so complex and, not my own work, there is now separate documentation with more detailed and better description see section `Top' in SETs Editor. But you can read also more from my doc, which describes the most common (for me) usage of the editor.
Here I describe most of the editor commands. If there is a key command like Ctrl+Q+Y, press Ctrl and Q simultaneously and after this press Y.
I strongly recommend not to use the technique by holding down the Ctrl
key when pressing the second key in such key combinations, because for
instance when you press Ctrl+K and then Ctrl+C you will be
prompted if you want to interrupt RHIDE (because you pressed the interrupt
key). But if you really want to use this methode, you should use the
`-C' commandline switch when starting RHIDE to disable the handling
of SIGINIT.
4.2.1 Erasing commands 4.2.2 Cursor moving commands 4.2.3 Text selecting and searching commands 4.2.4 Block commands 4.2.5 Other commands
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you have set some markers, they will be stored, so you can use them later when restarting RHIDE.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To compile only a single file, you don't need to include it in a project. You only have to open it and do a compile. If a file is in your project, you can compile it, if you are in its editor-window or if you are in the project-window and this file is selected.
Warnings and errors from compiling a file are listed in the message-window. If there are warnings or errors, you can jump to the corresponding source by hitting ENTER on this message. If this file wasn't already opened, it will be opened.
4.3.1 Problems with automatic dependencies
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Most checking of the dependencies works correctly, but there are some few situations, where this checking gets confused. The first results in the fact that I implemented a cache function for getting the modification time of files, that means, most files are 'stat'ed only once, after starting RHIDE. But if someone modifies one of the files, which are in the cache, (this can be another program, when you run RHIDE in a multitasking environment, such as Windows) or if you run your project and it modifies some of these files, the internal cache is after this not up to date.
Here is another situation. Your source files are not in the current directory. You have opened a source file for editing and successfully built your project. Now you leave RHIDE, because you want to debug your program with `FSDB', you copy the source file (in this case it is the file, which you have opened in the IDE) to the current directory. Now you debug it and there are some errors. You restart RHIDE to make the changes in the file. The previously opened file will be opened automatically and you edit it. If you do now a Make, RHIDE tells you, that your project is up to date, because it searches for source files at first in the current directory, and there is the unmodified file.
In this chapter I will give you for some special parts a more detailed description of what they do.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The project window shows you every file, which you have included in your project. Most time you work with RHIDE this window should be visible, but you can also close it see section 3.10.7 Close.
4.4.1 Items of your project 4.4.2 Open a project item 4.4.3 Dependencies of project item 4.4.4 Local options for a project item
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The items in the project window, and therefore also in your project, are sorted in alphabetical order. This has the effect of faster finding an item and you can also move the selecting bar to a specified item by typing the name of this item.
Normally, the alphabetic order of the project items causes no problems because the linker searches at first every object file for unresolved symbols before any library. The statement, the the GNU linker is a one pass linker makes sense only for libraries, because they are checked only once for unresolved references. That means, if you include libraries in your project you must know about the order, where this library is put on the command line when linking your program.
If you have problems with that order, or if you really want to have one object file (or library) before some others, you must rename them, to get the right position from the name.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To open an editor window with the selected item press either ENTER or SPACE. If there was already a window with this file opened on the desktop, this window will be selected. This works only if the selected item has a known suffix see section 2.1 Known suffixes. If the selected item is a project file, that project will be opened with the side effect that if you close this project, the previous one will be reopened.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you have compiled a file already in RHIDE, you bring up a list with all dependencies of that file. In this list the files are show by their basename followed by the directory and they are also sorted in alphabetical order. From here you can also open an editor window with the selected dependency by pressing SPACE or ENTER on that item.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can change many options for a project item, which are in effect only for this file. To do this, hit Ctrl+O on the selected item and a dialog is shown, where you can change the options.
At this time you can change the following options.
Local commandline options exclude from link rebuild seldom Name of the output file Compiler type User defined compiler Error checking Error program
$(RHIDE_GCC) $(INCLUDE_DIRS) $(C_DEBUG_FLAGS) $(C_OPT_FLAGS) \ $(C_WARN_FLAGS) $(C_C_LANG_FLAGS) $(C_EXTRA_FLAGS) $(LOCAL_OPT) \ -c $(SOURCE_NAME) -o $(OUTFILE) |
stderr
If "!Line" and/or "!Column" are not used they dafault to 0. The next line contain the error text. Example:
!Error!File'test.c'!Line 17 This is a sample error message |
This means, that in file 'test.c' at line 17 an error occurred with the description 'This is a sample error message'
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
RHIDE uses for compiling, linking, and the other stages of generating a file also specs, like you can change in the local options for a project item see section 3.8.5 Local options. Here the specs, which are used currently:
All of these specs have a default content in RHIDE, but they can be overwritten by setting the environment variable with the same name and any other contents.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
All of these variables are referenced by a name enclosed in parentheses preceeded by a dollar sign. Example: `$(RHIDE_GCC)'. You can overwrite any of the following variables, if you define in your environment the same variable with any contents you want.
When RHIDE tries to get the contents of such a variable, it searches at first if it is found in it's internal database. If it was not found, the environment is checked for such a variable and if that fails, the resulting value is the variable itself.
In addition to the use of variables, RHIDE has a limited ability of using string manipulating functions. I have implemented some of the functions, which are available with GNU make. They have the same name and should work exactly like the GNU make counterpart.
The following variables have a special meaning in RHIDE with the default contents:
$(RHIDE_GCC) $(RHIDE_INCLUDES) $(C_DEBUG_FLAGS) \ $(C_OPT_FLAGS) $(C_WARN_FLAGS) $(C_C_LANG_FLAGS) \ $(C_EXTRA_FLAGS) $(LOCAL_OPT) -c $(SOURCE_NAME) \ -o $(OUTFILE) |
$(RHIDE_GCC) $(RHIDE_INCLUDES) $(C_DEBUG_FLAGS) \ $(C_OPT_FLAGS) $(C_WARN_FLAGS) $(C_C_LANG_FLAGS) \ $(C_EXTRA_FLAGS) -x c $(LOCAL_OPT) -c $(SOURCE_NAME) \ -o $(OUTFILE) |
$(RHIDE_GXX) $(RHIDE_INCLUDES) $(C_DEBUG_FLAGS) \ $(C_OPT_FLAGS) $(C_WARN_FLAGS) $(C_C_LANG_FLAGS) \ $(C_CXX_LANG_FLAGS) $(C_EXTRA_FLAGS) $(LOCAL_OPT) \ -c $(SOURCE_NAME) -o $(OUTFILE) |
$(RHIDE_GXX) $(RHIDE_INCLUDES) $(C_DEBUG_FLAGS) \ $(C_OPT_FLAGS) $(C_WARN_FLAGS) $(C_C_LANG_FLAGS) \ $(C_CXX_LANG_FLAGS) $(C_EXTRA_FLAGS) -c c++ $(LOCAL_OPT) \ -c $(SOURCE_NAME) -o $(OUTFILE) |
$(RHIDE_AS) $(RHIDE_INCLUDES) $(C_DEBUG_FLAGS) \ $(C_OPT_FLAGS) $(C_WARN_FLAGS) $(C_EXTRA_FLAGS) \ $(LOCAL_OPT) -c $(SOURCE_NAME) -o $(OUTFILE) |
$(RHIDE_AS) $(RHIDE_INCLUDES) $(C_DEBUG_FLAGS) \ $(C_OPT_FLAGS) $(C_WARN_FLAGS) $(C_EXTRA_FLAGS) \ -x assembler $(LOCAL_OPT) -c $(SOURCE_NAME) \ -o $(OUTFILE) |
$(RHIDE_INCLUDES) $(C_DEBUG_FLAGS) $(C_OPT_FLAGS) \ $(C_WARN_FLAGS) $(C_P_LANG_FLAGS) $(C_EXTRA_FLAGS) |
$(RHIDE_GPC) $(RHIDE_GPC_FLAGS) $(LOCAL_OPT) \ -c $(SOURCE_NAME) -o $(OUTFILE) |
$(RHIDE_GPC) $(RHIDE_GPC_FLAGS) -x pascal \ $(LOCAL_OPT) -c $(SOURCE_NAME) -o $(OUTFILE) |
$(RHIDE_LD) $(RHIDE_LIBDIRS) $(C_EXTRA_FLAGS) \ $(RHIDE_LDFLAGS) -o $(OUTFILE) $(OBJFILES) \ $(LIBRARIES) $(RHIDE_LIBS) |
$(RHIDE_LD_PASCAL) $(RHIDE_LIBDIRS) $(C_EXTRA_FLAGS) \ $(RHIDE_LDFLAGS) -o $(OUTFILE) $(OBJFILES) \ $(LIBRARIES) $(RHIDE_LIBS) |
$(RHIDE_LD_PASCAL) $(RHIDE_LIBDIRS) $(RHIDE_LDFLAGS) \ -o $(OUTFILE) \ --automake=\"$(strip $(RHIDE_GPC_FLAGS))\" \ $(RHIDE_GPC_FLAGS) $(SOURCE_NAME) $(LIBRARIES) $(RHIDE_LIBS) |
$(RHIDE_AR) $(RHIDE_ARFLAGS) $(OUTFILE) $(OBJFILES) |
fsdb $(OUTFILE) $(addprefix -p ,$(SRC_DIRS)) $(PROG_ARGS) |
gdb $(OUTFILE) $(addprefix -d ,$(SRC_DIRS)) |
grep -n $(prompt arguments for GREP) |
gprof $(OUTFILE) |
The following are not used as real variables, but they are used to get the contents of options from RHIDE. But you can override them also by setting them as an environment variable.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you have special wishes for compiling your source files, you can configure for RHIDE mostly everything. For adding support for other than the builtin known file types see section 4.6 Builtin variables. If you want to change the behavior of RHIDE for compiling all the known file types you should know at first really what you do. If you think, this is a good idea or if you only want only check if it works you can do it.
Before RHIDE compiles any file (this includes also linking and building a library) it searches the environment for a variable after the following scheme: When compiling a file with suffix `.c' to a file with suffix `.o' RHIDE checks for the variable $(RHIDE_COMPILE.c.o). If this variable is defined the contents of this variable is taken as the compile spec.
If you want to change the specs for linking you must take as destination suffix `.exe' or `.' and as source suffix the suffix of your object files. Example:
$(RHIDE_COMPILE.o.) |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This window shows every time you compile a file the resulting messages, which GCC produces. These messages were converted in a special format to show them in the window. Some of the messages contain a file eventually combined with a line number. If you press ENTER on such a message, the corresponding source line in the file will be highlighted and the window with this file will be selected. If this file is not already on the desktop, it will be opened.
If the file, to which the messages refer, is already in the foreground you can see the selected source line for your messages directly on the screen.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Syntax highlighting is now supported directly by the editor. It should work in mostly every situation for all the supported types. Currently (in RHIDE) only the C/C++ style syntax highlight and the Pascal style syntax highlight are supported.
With which style a file is highlighted is chosen by RHIDE by checking the suffix of the file and determining the file type from that suffix See section 2.1 Known suffixes.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This is one of the main parts of RHIDE. To speed up the work, I have added a cache for checking the modification time of a file and for finding a file (computing the full name of a file). But sometimes the data in the cache isn't valid, especially when running under Windows. If you see this, you can clear the cache by leaving RHIDE and starting again.
If you didn't do any special things but have problems with it, please run RHIDE with the `-df' switch and try to find out, where the problem is and post it to me so I can fix it.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Turbo Vision library is part of Turbo C++ version 3.1. I have ported this library to use with DJGPP because I think it is the most powerful text windowing library, which is available for MS-DOS. With the help of this library you can write a front end application which looks very well and has an interface that is easy to use.
The Turbo Vision library is not only a window based text user interface, it is also a very good event handling mechanism. It supports the use of the mouse and keyboard with the ability of defining and using of hotkeys. That means, you can assign to some key or combinations of keys, which function should be executed.
The main parts of an application, which is using this library, are the desktop, the menu bar and the status line. The menu bar is usually shown as the topmost line of the screen. There are shown the main parts of the pull down menus, from where you can select the most functions, which are implemented in an application.
To use the menu you can use the mouse as well the keyboard. With the mouse you can click every where on a menu entry and the corresponding function will be executed. There are some different actions, which a menu entry can have. At first some of them, these are, for example, all the entries in the menu bar, open a submenu with more menu entries which are related to the name of this main entry. And the others, most in such a submenu, execute a definite function of the application.
With the keyboard you can walk through the menu very simply. Press F10 to activate the menu bar. In the pull down menus you can use the cursor keys to move the highlighted bar up and down and with the cursor right and left keys you can switch to next or previous menu. With the ENTER key you activate the function, which corresponds to this entry. If this was a submenu, which is indicated with a symbol like a small right arrow, this will be opened.
If you walk through the menu with the cursor keys or the mouse (hold the left mouse button down and move the mouse) in the status line will be shown for each entry a short hint for the function of this menu entry.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In a dialog, like the file open dialog, are many things which you can select or where you can type in some data. At first some general functions. If you press ESC the dialog will be closed and nothing will be changed. The same can be done with the mouse by clicking on the close symbol (this is the small symbol on upper left frame of the dialog).
In the next paragraphs I will describe the most used elements of a dialog. For selecting each element of a dialog you can use the Tab key to select the next element in the dialog or the Shift+Tab key, to select the previous element.
A button is a rectangle with some text on it. If you activate such a button a specified action is executed. To select a button you can use the Tab key, until the button is specially highlighted and press ENTER then. Most times a character of the text on this button has a different color. So you can press Alt plus this character to activate the button. With the mouse you can simply click on a button to activate it.
A Listbox is a collection of some strings in one or more columns and rows as needed. The project window see section 4.4 Project window is such a Listbox with the names of the project items. You can use the cursor keys to move the focus bar in the list, or if it is a sorted Listbox, you can also type some characters and the focus will move to the item, which starts with these characters. To select a item in a list box, press SPACE or ENTER or double click with mouse on it.
In an input line you can type some text which can be edited with the usual editing keys.
A checkbox is a collection of options, which can be turned on or off. Each option has in front of it a small indicator, if it is turned on (an X is shown) or not (the X is not shown). To toggle such an option, use the cursor keys to move the focus to the option you want and press SPACE or, if a character in an option string is highlighted you can press this key and the option will be turned on or off or click with the mouse on the option.
Radiobuttons are similar to Checkboxes, but there you can select only one of all the shown options.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Please look for a detailed documentation here: section `Pseudo Macros' in SETs Editor.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The integrated help system of RHIDE is based on the INFO Viewer written by salvador@inti.gov.ar. It gives you access to all the INFO files which you have installed in the correct directories as is done for `info.exe'.
To get help about the INFO Viewer hit F1 when the help-window is opened or follow this link to section `Top' in SETs Info Viewer.
In addition to getting help with this system you can also copy text from the help screen to the clipboard. This is useful if you want for instance to copy an example from the libc reference in your program. This feature is not so powerful as in the editor, but it is good enough. To mark some text use the Shift and cursor keys and copy the selected text with Ctrl+Ins to the clipboard.
In RHIDE you have also the possibility to get help about a specific function. Currently this works only for functions, which are documented in the libc reference. For doing this, move the cursor to the function and hit Ctrl+F1 or click with the right button of the mouse on that word.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
RHIDE can handle RCS files in the way, that it searches for a checked in source file if the normal source file was not found. The complicatest part here was to determin the correct RCS file name from the source name. (Especially under DJGPP this is a problem since under raw DOS it is not possible to use names like 'foo.c,v').
So I decided to use the external program `rlog' which comes with the RCS package to determine the actual correct RCS source name. I did so because the DJGPP implementation knows enough about the DOS limitation and how to solve them.
This help here is not ment to be a RCS introduction. If you don't know what RCS is or what can be done with it, please look in the manuals wich come with RCS.
Here now what RHIDE knows about the RCS files. If a source file was not found, it's RCS name is computed with the spec `$(RHIDE_RLOG)' which defaults to `$(shell rlog -R $(rlog_arg))' where `$(rlog_arg)' is substituted at runtime with the actual wanted source file.
This spec can be overwritten to speed it up. An example for this can be found in the distributed sample environment file `rhide_.env'.
When RHIDE only wants to compile the file or only to get the modification time it is temporary checked out (without locking it) and after the needed operation (compiling) it is removed (for checking the modification time it is not checked out, but the time form the RCS file is taken).
If you want to open that file for editing the same is done but now it is checked out with setting a lock and it is not checked in after closing the window. The spec for checking the file out is `$(RHIDE_CO)' which can be overwritten also and it defaults to `$(shell co -q $(co_arg))' where the switch `-l' is added when it is checked out for edititing otherwise `$(co_arg)' is substituted at runtime only with the wanted source file.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |