On 2007-04-06, at 16:33, [EMAIL PROTECTED] wrote: > On Apr 06, 2007, at 07:19 UTC, Sven E Olsson wrote: > >> (On Mac) >> Works great, what is that mean? >> So you mean that if I load a text file in about 3-5MB, the EditField >> works great or what? > > I don't know --
Ok.. I understand.. > I have hundreds of text files I routinely work with, > but I can't think of one at the moment that's multiple MB. But "works > great" means that I've been using it for years, in lots of apps > released to lots of people, and never once had a complaint about the > performance, nor noticed any performance problems myself. It also > adheres to platform standards; on the Mac it properly handles double- > and triple-clicks, double-click-drag, drag-moving, drag-copying, Text > Services, international languages (including Chinese, Japanese, etc.), > and on and on. It's always been great for me, and given the wide > variety of uses to which I've put it, I think my experience is > probably > typical. > Yes I think the same... > No, it's not a word processor or a code editor, and it's not intended > to be. It's an edit field. If you look inside Word or AppleWorks or > CodeWarrior or XCode, or even TextWrangler, you will not find them > using a standard edit field. Those are specialized editors with > specialized requirements, which calls for specialized code. (As is > the > case with the RB code editor, for that matter.) Some people seem to > expect RB to provide them with all the specialized hard parts of their > application, so they can (as Norman put it) create something unique > and > special without doing any work. That's ridiculous. Yes, I think the the same, you have to write some self.. > > My only complaint with RB's EditField is that, on the Mac, it doesn't > properly support tab stops. But I filed a feature request, and it's > already been marked as implemented for 2007r3. That'll be less than > three months from now; I can wait (and kudos to REAL Software for > fixing that so quickly after it was reported!). Interesting, I have seen a lot of small improvements over some years. So I could also say it works great, but only with small files... As I understand (I am not using Windows more), that EditField could load much bigger files (faster), and if we compare how great it is then it lack just to the RB EditField on Windows. So we don't need to compare with Xcode ... thats not the same thing.. And as you said, there have not been any issues to talk about, it was just in RB2007r2, that i found the scroll issue, but I compile in RB2007r1. So what I think is some "need" for Mac RB users, is just the RB EditField, but today we would like to display some bigger files then perhaps 100 - 200 KB.. Thanks for the response and a nice weekend to you all. Sven E > > Best, > - Joe > > > > >> >> If we read the LR about EdiField, then we see a lot of features that >> meet our needs, absolute. >> But there is nothing about the limitations of 40KB or something like >> that. >> >> I understand that the EditField works great, if you use very small >> files. >> >> If I load a plain text file, without color that is 3MB in size, a >> default application with one window, one EditField use 178MB RAM >> Memory, is that great? If I select that text, the memory usage is >> about 190MB RAM. A 3MB text file is not big today, perhaps it was >> 1999. (TextWrangler use 28MB for the same file, with syntax coloring) >> >> Great could means a lot... in this case at least for the memory chip >> factories. >> >> (The scroll bar also have some issues with bigger files (2007r2)) >> >> So in this case "Great" means nothing.. But it could be interesting >> to know what type of files and size that works great. >> >> Have a nice weekend to you all, >> >> Sven E >> ----------------------- _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
