RunRev vs RealBasic (Richard Gaskin)

[Thomas Gutzmann]

Hi Richard,

thanks for your kind reply. My remarks are inline.

> > 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?

Because speed mattered, I created my own graphics classes starting at a 
very low level where I didn't have to fight with unwanted or unneeded 
behaviour and overhead of existing classes - but without losing the 
advantages of objects, subclassing etc. It allowed me to scroll 
thousand of objects at high speed - something impossible otherwise.

> 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?

This speed increase is impressing, but having tried quite some 
alternatives, I'm sure that only C++ (which I don't like) and RB where 
adequate solutions, There are so many calculations when moving objects 
and scrolling the pane, that I simply cannot imagine that Rev is fast 
enough. But I will give it a try as soon as I have some time, and I 
will come back to the list with the results.

> > 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.

After giving your arguments some consideration and finding Jan 
Schenkels planned reporting tool, I think I will change my mind.

> > - RB has more interface elements;
>
> Which common GUI elements are not also in Rev?

Well, quite some.

Listboxes are MUCH better - hierarchical, automatic background 
coloring, headers, order by drag, smart scroll behaviour, easy 
implementations of pictures, plus very exciting plug-ins from 3rd party 
vendors. It's ok with Rev - just that. On the other hand, if I come to 
sorting a list, that's a chore in RB. Toolbar items - not there in Rev, 
am I right? Many plugins like calendar and time controls (not in RB 
itself). OLE containers (Windows only, of course).

You can live without, though I was a bit shocked by the list controls 
in Rev. Colouring the background alternatingly should be a basic 
feature, and all the work-arounds I've seen are ... well ... 
workarounds.

> > 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?

Yes, I meant Rev. You can do all this, but it's easier to understand in 
RB. But I don't mind much about group controls. What I loath in Rev are 
the tabbed windows. It's hard to learn and unncessarily complicated to 
work with. On the other hand (no light without shadow and vice versa), 
using cards is an amazing technique, and it's MUCH easier to work with 
them than navigating between RB tbas (as a developer).

> > there are much more options for lists, and so on.
>
> What options would be useful to have added to Rev lists?

See above. I think headers and coloured row backgrounds are the 
minimum, and also some corrections to scrolling with the thumb, 
ensuring that there are always complete lines at the beginning of the 
window, even with lines of varying height (with fixed height, it can be 
corrected easily with a handler).

Hierarchical lists: no, I don't really think that's necessary. I 
haven't tried, but obviously it's possible to mimick it using the 
ImageSource property. Handling hierarchical list is quite complicated 
in RB, and I imagine that it can be done easier in Rev, using custom 
properties.

Custom properties, by the way, are handled way better in Rev than in RB.

> > - 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.

The problem with large class libraries is that (with a bit of 
exaggeration) only the developer understands them, and when they are 
very large, with many subclasses, he will only understand them until 
he's got nuts. Java developers will always stay unKISSed ;-)

> > 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.

Well, ahem, I purchased the Rev license because I wanted to rewrite 
tools for HP/UX and SunOS. I have to stick with Java there, now.

I know that my company cannot produce enough revenue for Rev to justify 
any extra work for the Unix platforms - but Rev should remove the 
features from the web site if they don't plan to provide it, or they 
should give an estimated release date.

> > Now please don't flame!
>
> No reasonable person could flame such a balanced and thoughtful post. 
> Thanks for taking the time.

Well, I have seen the contrary. But maybe this list is really different.

Thanks again for your response,

Thomas G.