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

A couple more things:

The files in the Target's "Include" and "Library" folders aren't sorted 
(alphabetically), but are listed in a random order, basically the order in 
which they were found in the source code.

Additionally, files that are only conditionally included are still listed 
in the "Include" and "Library" folders, even if they aren't actually part 
of the project, like in this code:

#if XPPVER < 2000483
   #include 'ASINetC.ch'
#else
   #include 'Socket.ch'
#endif

Both files will be listed, even though ASINetC.ch wouldn't actually be 
included in this project, and in fact, might not even be anywhere in the 
include path or available to be opened.

Thanks,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

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

Andreas Gehrs-Pahl wrote:

> Additionally, files that are only conditionally included are still listed 
> in the "Include" and "Library" folders, even if they aren't actually part 
> of the project, like in this code:
> 
> #if XPPVER < 2000483
>    #include 'ASINetC.ch'
> #else
>    #include 'Socket.ch'
> #endif

I doubt that the Workbench is able to evaluate all possible conditions
properly, so maybe including those files "just in case" is the best
solution.

Everything else just confirms my decision to stay with Multiedit instead of
using the workbench 

I have been working with some integrated dev environments now - Visual
Studio, SharpDevelop, PyCharm, just to name a those I regularly use and if
I compare the Xbase++ Workbench to any of them, it feels like using a
hammer to drill a hole in a wall.

Especially PyCharm (a Python/Django IDE) is a brilliant tool, where
literally everything can be configured in detail... I just wished Alaska
had chosen to use a 3rd party IDE instead of insisting to develop their
own.

Thomas

Thomas,

> ... I just wished Alaska had chosen to use a 3rd party IDE 
> instead of insisting to develop their own.

I agree with you.
I just don't know if that would deliver the flexibility they are looking
for regards to Xbase++, form designer, workflow etc.
And of course, as far as I know the editor is a third party product
already.

Peter

Hi Andreas,

First: I have to admit that not all clitches with the editor (and there are 
a lot
of them) are collected in PDR's. I have read across your posting, to me it
seems that we know about most of your observations.

Andreas, you have 250 source files with 40 header files in one project.
Can you give me an idea about how many functions, classes you have
in one file? What is the average length of your source file.

Many thanks in advance.

Andreas Herdt
Alaska Software

--------------------------------------------------------------------

Technical Support: support@alaska-software.com

News Server: news.alaska-software.com
Homepage: http://www.alaska-software.com
WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm

Fax European Office: +49 (0) 61 96 - 77 99 99 23
Fax US Office: +1 (646) 218 1281
--------------------------------------------------------------------

"Andreas Gehrs-Pahl" schrieb im Newsbeitrag 
news:z9yf0sj4px8e$.1f8dxcxxe1lg4$.dlg@40tude.net...

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

Andreas,

>Andreas, you have 250 source files with 40 header files in one project.
>Can you give me an idea about how many functions, classes you have
>in one file? What is the average length of your source file.

There are currently 5 *.exe targets, 36 *.ch files and 252 *.prg files in 
my main project. The 36 header files include add-on components but don't 
include standard Alaska Xbase++ header files, of which there are probably 
about another 40 or so. Many of the program and header files are shared 
between the five targets.

The 252 program files currently contain 52 Classes (with 988 Methods), 
2,001 Functions, and 3,380 Procedures in total.

In total, the 36 header files are 838,254 bytes in length, consisting of 
15,534 lines of code, including remarks and white space. The size of the 
header files ranges from 2,147 bytes to 139,361 bytes, with the majority 
between 5,000 and 25,000 bytes. 

In total, the 252 program files are 9,217,602 bytes in length, consisting of 
207,010 lines of code, including remarks and white space. The size of the 
program files ranges from 815 bytes to 290,203 bytes, with the majority 
between 20,000 and 40,000 bytes. 

This means that -- on average -- there are: 
*  1 Class in every fifth program file;
* 19 Methods per Class;
*  4 Methods in every program file;
*  8 Functions in each program file;
* 13 Procedures in each program file;
* 432 lines of source code in each header file, including remarks;
* 820 lines of source code in each program file, including remarks;
* 23,284 characters in each header file, including remarks and white space;
* 36,580 characters in each program file, including remarks and white space.

The five resulting target exe files are between 5 MB and 25 MB in size. All 
this doesn't sound extremely large to me, but it is a good sized project.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

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

Andreas,

> The 252 program files currently contain 52 Classes (with 988 Methods), 
> 2,001 Functions, and 3,380 Procedures in total.
> 
> ... The size of the program files ranges from 815 bytes to 290,203 bytes, 
> with the majority between 20,000 and 40,000 bytes.
 
Impressive statistics. 
I never looked at my application that way. As I was intrigued by the number
of funtions and procedures I gave it a try. 
My application is a lot smaller. It has 256 program files, but most are
under 10,000 bytes. These contain 445 classes (with 2766 methods), 271
functions and 3 procedures.

Peter