At 08:16 26.06.00 -0400, douglas at winetech.com wrote:
>product (see winetech.com).  We currently have software written in a 
>combination of Visual Basic, C++, and the Microsoft Jet Engine for the 
>Access database.   Squeak initially looked promising as a platform for the 
>future, but I am gradually and  sadly reaching the conclusion that it is 
>may never be usable for software like ours.

Why don't you, assuming the project is large enough, allocate 10% of its 
time to create the extensions needed?  That will might also be a nice 
payback to the community ;-)  And I'm pretty sure that you can still be 
faster that with C++ (VB is probably nearly as nice as Smalltalk).

For example, today we spend 3 hours with a customer to test, debug and fine 
tune an application written in Squeak.  With other languages like C++, we 
coudn't have done that at all and probably would have spent two additional 
days development.

>2. No stable GUI that provides critical tools for manipulating large slabs 
>of data (particularly Grids that show multiple records and Rich Text boxes 
>that display and edit text while using multiple fonts and colors).

That's unfortunately true and not that easy to change if you want to 
achieve the quality (yes really) Microsoft provides with VB or Access.  For 
a simple grid morph one could derive the TableMorph which was already 
mentioned on this list.  Adding some in-place editing capabilities and 
finished up the stuff might take less than 1 week.  Squeaks normal text 
input field can already show colors (even working hyperlinks) and one 
custom font but one would need to work on this to support multiple fonts, 
different indentation, list bullets, paragraphs with different line 
heights.  To allow text input one probably would need an editor morph 
similar to Microsoft's wordpad.  As I don't know much about the edit 
control, I'd guess about 1-3 weeks of work - including the wordpad editor.

>3. No database ( We currently have about 50,000 records across two 
>databases, taking up about 100 megabytes).  We need fast access from a 
>variety of different indexes.

Depending on what you need, it might be sufficient to keep the data in your 
image.  The application mentioned above simply keeps 50MB of data which, 
after one
   Smalltalk collectGarbage
which moves all global data into the old space doesn't affect performance 
at all.  And it's know pretty easy to use Smalltalk's #select: and 
#collect: messages to access the data.

>4. Not even an obvious ability to store 100 megabytes on BTrieve-like files.

Even 100 MB woudn't be a problem on a 256MB+ PC ;-)

>5. Poor documentation.

Well, here you need to look at example, browse the web and ask question on 
this list.  This can definitely be improved.

bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf