RunRev vs RealBasic (Richard Gaskin)

[Richard Gaskin]

Thomas Gutzmann wrote:

 > But there are cases where OOP is simply better, and then RB
 > is the better choice, of course (better than Java, too). I
 > have an application where I need a very fast and complicated
 > graphic interface with a large number of objects. This I have
 > written in RB; the rest of the application is being written
 > in Rev. All these single and largely independent windows can
 > be done in RB, sure, but it simply takes too long.

How does OOP help with that?

And with the recent 4000-fold increase in speed for same-size chunk 
replacements, I wonder if the kind of graphics processing you're doing 
could now be done in Rev.  What does that entail?


 > I'm not sure yet how to do the printing and reporting part - maybe I
 > switch to a third tool for that, like Perl.

In its simplest form, Rev prints a card.  So you can lay out a card to 
appear as you want it on paper, fill it with what you need, and execute 
a "print card" command.

It can get tricker if you need things like multi-column lists of 
variable size, but all the raw materials for figuring out the layout 
dynamically (see the print properties and formattedHeight, pageHeights, 
etc.) are available in the language for most printing needs.


 > - RB has more interface elements;

Which common GUI elements are not also in Rev?


 > it's easier to make tabbed windows (I have given this up in RB),

Did you mean "Rev"?  If so, what difficulties did you entounter?

You have two basic ways to work with tabs in Rev: putting the tab in a 
shared group and moving between cards in response to the menuPick 
message, or responding to that message by hiding and showing groups.

Is working with lists of controls in code easier in RB?  Or do they have 
another way of doing it?


 > there are much more options for lists, and so on.

What options would be useful to have added to Rev lists?


 > - It's also easier to share development in Rev, because there are less
 > mutual dependencies. If you have one stack for common handlers and
 > functions, you can reduce the sharing just to this stack, the rest can
 > be distributed amongst developers (given, it's a database oriented
 > application with a central db).

Amen to that, brother.  You can do minimal- or zero-dependancy code in 
Rev, as you wish.  Working on a stack doesn't mean pulling a long clique 
of classes along with it.


 > It's a bit disappointing that Rev doesn't provide support
 > for the other Unixes any more - that was one of the big
 > advantages against RB.

Which ones are you using that are no longer supported?

In my understanding the dropped platforms simply weren't used.  With 
enough interest they might bring some back.


 > - Support is better in RB, but that may be due to the size of the
 > company; RB brings out new versions faster, and their bug tracking
 > system is better. But on the other hand there are VERY engaged
 > people on this list which make good a lot - but not all.

 > - I sometimes have the impression that Revolution as a company
 > doesn't really exist. They are hardly ever seen in this list,
 > it's hard to get responses from them. I think that one of the
 > secrets of the success for RB was (and is) their presence and
 > visibility in the developer community.

Agreed 200% -- timely contact with a vendor is critical, as is a regular 
and ongoing vendor presence on their list.

Those were both so important I wanted to make sure they were included 
here, and have cc'd Kevin to make sure he doesn't miss it.


 > Now please don't flame!

No reasonable person could flame such a balanced and thoughtful post. 
Thanks for taking the time.

--
  Richard Gaskin
  Fourth World Media Corporation
  __________________________________________________
  Rev tools and more: http://www.fourthworld.com/rev