🚀 go-pugleaf

Howdy again,

A quick response to Jerry Sy (well, at least it started out as a quick response  
:-).

>>  15 character field names
>>    Mildly annoying, but not despicable.  Now 8 characters WOULD be  
>>    despicable.

>  well, that was not really the main point.  You get 15 characters for
>  your file name (table name) and 15 characters for your field names,
>  BUT you still get 15 characters if you use the table.field method of
>  addressing a field!  had they made that 30 characters, it will make
>  more sense.  because they didn't, you make have to settel for 7 character
>  table names and field names then, now that is despicable.

Whether you use the (unique) fieldname or table.fieldname reference, you get 15  
characters for the fieldname and 15 for the table.  The maximum total length  
for table.fieldname references is 30, not 15.  (When version 1.1 arrives with  
255 characters per name it will have over-killed this feature)


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

>>  If you want a much longer list of peeves, I'm sure I can create it.  Omnis  
>>  usually makes you painfully aware of its limitations where other programs  
>>  simply don't venture into an area to entice there users (i.e. 4D's  
>>  lack of "Omnis lists", multi-windowing, field events, etc.). 

Actually I meant "entice their developers" (with the better spelling also :-)  
more than their users.  

>>                                                     ...BUT if you try to  
>>  convert a sophisticated Omnis application to other environments you will 
>>  be in for a big shock. And Omnis will look much, much better.

>  entice users is a good description.  I find most features omnis demonstrates
>  in their demo program is IT.  that's it, what you see in the demo is what
>  you only get, nothing more, NO MAS!

Omnis's demo programs aren't even faintly close to being the best you can do  
with Omnis.  Doing more requires good examples, flashes of insight, and a  
thorough understanding of how Omnis does things.

Unfortunately, as I had mentioned previously, the Omnis documentation is VERY  
BAD for developing advanced applications.  There are no real examples of using  
the newer Omnis 7 capabilities (there are few real examples of anything),  no  
examples of a well strung together high-end application (or even a major  
component of such -- especially list routines), and painfully short  
descriptions of the Omnis 7 commands.  Not much help to discovering what the  
program can do.

Note that simple to medium level (4D's "advanced" example programs are about  
medium level) user-interfaces are pretty straightforward and I assume the  
documentation and example programs could get a developer there OK.

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

>  they did a good job on reports, but maybe not good enough, most of the
>  users of my program wants a report in spreadsheet format! and currently,
>  the only way to get that in omnis is to build an intermediate list first
>  and generate the report from the list , not an excruciating (sp?) work
>  around, but still a work around.

I don't know why you could not generate a spreadsheet form report without  
reading data into a list first, but using a list is not an Omnis work-around.   
The Omnis list is one of THE MOST IMPORTANT and powerful features of the  
environment (far stronger than the 4D set for example).  Certainly using the  
best features of an environment is not a work around.  Yes, the ad-hoc report  
generator couldn't do all you wanted, so that is a fair strike against it.

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

>>  Again, I wouldn't recommend Omnis to everyone.  Omnis's main strengths are  
>>  being able to: develop very sophisticated user-interfaces and reports; make  

>  I will call it sophisticated only when it can do what hypercard can do,
>  resize window in your program (I have to write an Omnis external to do
>  this), change scripts and attributes of buttons programmatically ( now
>  I have to create say, 10 different buttons and hide / show them as necessary
>  instead of having just one button (or other objects for that matter) and
>  the ability to modify the attributes (e.g. size, location, etc) dynamically
>  in ca program), etc.  the current state of the user interface is that you
>  are either stuck with it or do excruciating work arounds.


To move and resize a window procedurally you use the command:

    OPEN windowname/leftpos/toppos/rightpos/bottompos
or    OPEN windowname/STACK
or    OPEN windowname/CENTER

with each parameter (after the '/') begin optional.  It may be a little weird  
(obscure) to use the same command for "Opening" a window and for  
"Moving/Resizing" a window, but the functionality is there.  You can get the  
current open windows and their positions from:

    Build Open Window List

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

You are quite correct that Omnis can not create or move 'Window Objects' at  
runtime.  For almost all applications this is not important (though I do agree  
it can be very handy).  I do not think that Omnis is the way to create ANY user  
interface and would personally choose Smalltalk for that purpose: having to  
create any user-interface on demand.  

Comparing a database development tool with a more general purpose language is  
not very useful unless you compare it on ability and ease in doing the complete  
job: building a single/multi-user relational database.  Hypercard by itself  
would certainly fail at this competition.

As a relational database front-end it:
    1) Needs third-party externals to connect to SQL servers,
        and the programming interface will be weaker than Omnis's
    2) No local concept of tables and fields
        (except programmatically)
    3) Could not store the results of queries in a convenient,
       manipulable form,
    4) Has much more limited data structures
    5) Would run slower

Even focussing on UI features Hypercard has:
    1) Much poorer multi-windowing support.
    2) Lack of color window objects (except displaying PICTs)
    3) Less built-in window objects 
         (requires externals for popup menus, lists, etc.)
    
Finally, as a development environment Omnis 7 is much stronger (but has a  
stranger language).

I'm not arguing against Hypercard being better at some applications than Omnis:  
Hypercard has much better control of the event loop, can create/modify window  
objects on the fly, and has many useful externals designed to go with it.  But  
we were discussing ability to produce high end interfaces to relational  
databases, not any application.

An aside: Smalltalk would win against Omnis in many areas where Hypercard  
loses, although it would still require purchasing class extensions for the  
database management routines.  Other than that, I would whole-heartedly  
recommend it to anyone developing many types of databases ASSUMING they have  
the money (LOTS of it for Smalltalk-80 plus the database package, a normal  
amount for Smalltalk/V) and the willingness to travel Smalltalk's learning  
curve.

Jerry Sy seems to be comparing Omnis to an application that combines the best  
of Omnis, Hypercard, and SQL (and I assume many other useful features).  I  
personally wish Omnis (or something else) was Smalltalk with persistent  
objects, relational capabilities, a great UI builder, and for under $1000.  I  
don't think Omnis will EVER be all of that, and unfortunately don't know of any  
product which currently is.  But I am constantly looking for it :-)


                                      -- Mark

Mark L. Fussell
rebecca@cco.caltech.edu