Andreas (or whoever at Alaska is responsible for workbench/editor issues),

With every new build of Xbase++ 2.0, I have tried to open my project with 
the workbench, but have not been able to work with it. It takes several 
minutes to completely open the project and populate the "Project Manager" 
tab. 

If I open a "*.ch" (header) file and make any kind of change, the program 
will hang for about half a minute to a minute -- after each key stroke that 
I make -- with the CPU (on which the workbench runs) running at 100%! If I 
then close the file, even without saving it, it will again take quite a 
while before the workbench responds again. Editing a normal program file 
will often take several seconds, before the workbench will react to another 
key stroke again.

I can't imagine that my project is unusually large, so I'm wondering if 
anybody else has a similar experience. Maybe there is some setting that I 
can use to stop the workbench from continually re-parsing all the files, 
which seems to be the reason for the slow response.

The project consists of 5 targets, about 250 program files and about 40 
header files, many of those files are being shared between the five targets. 

Also, with just 2 of those source files opened in the editor, it will take 
several seconds, just to switch between the two files by clicking on one of 
the two tabs.

Besides being so incredibly slow, the workbench also has a couple other 
small flaws:

1) If a file (*.prg or *.ch) contains a #define constant that has the word 
   "include" or "includes", etc. in it, like this:

   #define  _SOME_TEXT_  "This constant includes the problem word"

   Then the constant text: "This constant includes the problem word" will 
   be listed in the "Include" Folder of the Target, as if it were an actual 
   header file.

2) The "Include" Folder of each Target lists all the header files that are 
   implicitly included in other source files, but all header files that are 
   explicitly listed in the project file are only listed outside of the 
   "Include" Folder of the Target, together with the other files. 
   
3) Similarly, the "Library" Folder of each Target lists all the "*lib" files 
   that are implicitly included in other source files through the #pragma 
   Library() directive. Again, all the "*.LIB" (and "*.OBJ) files that are 
   explicitly listed in the Project file are only listed outside of the 
   "Library" Folder of the Target, together with the other files.

   But only files that are listed within double quotes -- rather than single 
   quotes -- in a #pragma Library() directive are added to the "Library" 
   folder. The documentation doesn't say anything about double quotes being 
   required, and using single quotes doesn't raise any errors.

It would make much more sense if all the "*ch" files would be (only) listed 
in the "Include" folder while all "*.lib" (and maybe also "*.obj") would be 
(only) listed in the "Library" folder, instead of having them spread out 
in two separate locations, with some files listed in both locations.

Also, to improve the responsiveness of the application to an acceptable 
level, the continual parsing of all the source files should be handled more 
efficiently. This should either be done in the background, with a very low 
priority thread, or should only run once every couple of minutes, and not 
after each and every key stroke.

There are several other issues with the editor that make it impractical for 
me to use, besides the terribly slow response times:

* Pressing SHIFT+Insert will not paste, even though that's SWB. Only CTRL+V 
  (and the Insert key by itself) can be used to paste text.

* If lines are indented with TABs, pressing cursor left or right will not 
  move  jump to the next  previous TabStop position, requiring many 
  unnecessary key strokes to move through indented source code.

* Using CTRL + cursor left or right will not stop at / jump to most special 
  and punctuation characters, making it unnecessary complicated and time 
  consuming to move through the source code.

* After inserting text, the cursor should stay in the same column but move 
  down below the (last) pasted row. Instead, the cursor stays in the same 
  row and moves to the end of the pasted text, unless the text was copied 
  in "Block" mode (using ALT+C with "Brief" Keymapping).

* Marking a block of text and then inserting text, will delete the block, 
  and add the text to insert in the last line of the block, instead if the 
  first one, so replacing the text in each line of the block (by repeatedly 
  inserting) isn't possible.

* Even though I have selected "Brief" Keymapping, basic Brief (or more 
  precisely, Zeus) functionality, like the number pad's Plus and Minus keys 
  and the above-mentioned cursor navigation, isn't working.

* (Some) Editor settings, like Block Indent and Tab Stop settings should be 
  file-type (extension) specific, to allow different tab-widths for *.prg 
  and *.ch files, for example.

There don't seem to be any PDRs for any of those workbench issues, as far as 
I can tell.

I would also like some compatibility switch for the command line project 
builder, compiler and linker, so that text is displayed on the command line 
window, even if the output is redirected to a file, as it was in previous 
versions (prior to 2.0), to make it possible to see progress, while also 
preserving the detail information in a log file. I know that this change was 
made for the workbench integration, but an automatic or manually selectable 
switch, back to the original behavior, when a console window is used, would 
be very much appreciated.

Thanks,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net