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.
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
