🚀 go-pugleaf

Poor horses...

In article <1992Jul27.202553.4042@usenet.ins.cwru.edu> jxs18@po.CWRU.Edu (Jerry  
Sy) writes:
> yes but you can only set the size when openning the window.  I need a feature
> to resize the window upon clicking a button, hence I needed to to it in
> an Omnis external....                                 ...and I don't
> think anybody will think that ,"well just close the window and open it
> again in a different size" is an elegant solution.

At some point you either got distracted and assumed resizing an open window  
wouldn't work or you need to upgrade your glasses.  The command:

    OPEN WINDOW windowname/leftpos/toppos/rightpos/bottompos
    
WILL RESIZE the named (open) window if you include the '/rightpos/bottompos'.   
The /0 routine won't be called so it is a pure Move/Resize command.  Again, I  
certainly think it would be more intuitive and convenient to have the commands:

    MOVE WINDOW    windowname/leftpos/toppos/rightpos/bottompos (/STACK/CENTER)
    RESIZE WINDOW  windowname/width/height

but that is just an inconvenience.
    
As an example, I use the window resizing capability in a 'Note' window so a  
person can write a quick note without worrying about special features or taking  
up too much screen space.  Selecting 'Full Note' enlarges the window so two  
lists (allowing the note to be attached to multiple people and grouped with  
other notes) that were previously hidden are available (it also adds new menu  
options).  Selecting 'Long' (a 'checkable' menu option) expands the window  
vertically so the main scrolling note field (which floats right and bottom) is  
much larger.  
    Fortunately programmed resizing can usually get around the flawed  
'uncontrollable grow/resize' (allowing a window to grow at all --> it works in  
both directions to any size big or small) that we discussed earlier.
    
In any case, the functionality is there and you should trash (for simplicity's  
sake) this particular external unless it does something more than this.

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

> I have reason to believe that they sacrificed the BASIC user interface
> features of a Macintosh application in lieu of cross-platform compatibility
> with Windows.  

And if you were referring to earlier versions of Omnis you might have been  
correct (although there were always trade offs: between 4Ds generally better  
Mac standard interface and Omnis 5's multi-windowing).  With Omnis 7 you are  
not.  There are many (UI) things Omnis 7 can do that 4D can not and few the  
other way around.  I can produce a more full-featured Macintosh application in  
Omnis than could be produced in the current realease of 4D.  4D will probably  
catch up in the next release, BUT that's a MAC ONLY database.  If Omnis can  
manage to surpass (or even just keep up with) 4D in user-interface features it  
can't be scoffed at.  
    "And by the way... this very nice Mac application just happens to run as is  
on the IBM..."

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

> another much needed feature in omnis is ability to open multiple application
> programs (much like the ability to open up multiple stacks in hypercard).

If you meant: 
    allow multiple databases to run on the same machine as independent 
    processes (possibly communicating by Apple Events) 
I would accept that as a useful feature, but that is a general Mac OS flaw, not  
an Omnis problem.  

If instead you meant: 
    allow multiple database applications to work in the same 
    application space, 
then I think you need more than your eyes examined... the possible fatal or  
subtle conflicts of this configuration would scare away any serious database  
developer.  Maybe you could avoid most problems by making sure everything were  
VERY VERY modular and insular, but Omnis gives no support for this (although  
Omnis 7 doesn't totally prevent it).  The interactions of multiple Hypercard  
stacks is much simpler.  Yes, Hypercard could be considered better in this  
regard but the comparisons are getting pretty far-fetched (and again Smalltalk  
would be better than both).
   Having two Omnis applications each with a plethora of windows, files,  
variables, possible TIMER events etc. in the same application space is not  
anything I want to worry about.  If I features from two different applications  
that I want to combine I can always export them into a third application and  
handle the little annoyances there.  I'd rather Blyth spent their time boosting  
the number of file formats to 50 million or so :-)

 
                                      -- Mark

Mark L. Fussell
rebecca@cco.caltech.edu