> It's still good though, it's just that you need a bit of a sense of
how far you can take RB. The problem with RB is it seems so promising, then once your app is almost finished, it turns out your controls are buggy and can't handle large volumes of text, and your app looks amateur :(
:-) TextSpresso 3 will handle volumes of text that bring most applications to their knees. There's only a couple data processing applications that I know of, all on Windows, which exceed its capability for processing large data files. They are disk based, and I haven't had time to finish the optional disk mode yet for files >2 GB. Granted, I had to roll my own text display and editing control on top of the Canvas class. But what high end application uses standard framework controls for large or complex data display? Now when you get down to raw byte crunching, C can be much faster, and I used C for most of the filtering engine. But here again, if you want to deal with huge datasets and do so quickly, you often have to roll your own. What you need is not in the typical framework or OS library. And outside assembler, I'm hard pressed to think of any language which can scan and manipulate memory as quickly as a good C compiler. As to looks...I know there are some display issues and missing Cocoa controls which really irk people. Having said that, I can think of numerous RB applications which look quite professional. I guess my point is simply that I don't believe RB is a "glass ceiling" to an application's functionality, speed, or look and feel. The barrier is the amount of work you wish to put in. Same as with any language, IDE, and framework. Daniel L. Taylor Taylor Design Computer Consulting & Software Development [EMAIL PROTECTED] www.taylor-design.com _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
