home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / mac / programm / 20102 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.8 KB

  1. Xref: sparky comp.sys.mac.programmer:20102 comp.sys.mac.misc:20922 comp.programming:3338
  2. Newsgroups: comp.sys.mac.programmer,comp.sys.mac.misc,bgsu.general,bgsu.mac,comp.programming
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!bgsuvax!m64-134.bgsu.edu!user
  4. From: dnebing@andy.bgsu.edu (Dave Nebinger)
  5. Subject: Programming Group and the 32k TextEdit barrier
  6. Message-ID: <dnebing-191292195308@m64-134.bgsu.edu>
  7. Followup-To: comp.sys.mac.programmer
  8. Sender: usenet@andy.bgsu.edu (USENET)
  9. Organization: Bowling Green State University B.G., Oh.
  10. Date: Sun, 20 Dec 1992 00:51:48 GMT
  11. Lines: 53
  12.  
  13.  
  14.  
  15. TextEdit is limited to files smaller than 32k. Doesn't that suck! 
  16.  
  17. Well, instead of complaining about the limits on TextEdit, I would like 
  18. to do something about it. I think there is a need for something that is 
  19. public-domain that can handle this problem, whether in the form of a 
  20. library or actual source code.
  21.  
  22. Now before you think about whipping out those flame-throwers and 
  23. thrashing me for not looking into other options, I want to tell you that 
  24. I have. These are my thoughts:
  25.  
  26. 1)  Existing PD or ShareWare editors: There is quite a range of these 
  27.     that are available to anyone who can ftp them. And these are all 
  28.     very good programs. While they are fine as editor in themselves, 
  29.     there still is no way to handle the files greater than 32k by 
  30.     your own application. You must either communicate directly with 
  31.     the editor or trust the user to do all of the work. While this 
  32.     can solve the problem, it becomes quite a hassle for the user to 
  33.     be switching in and out of two apps. Also, if you implement the 
  34.     communication with the application, you rely on the fact that 
  35.     the author will not change the communication method. If it does 
  36.     change, you have to change your app to keep up compatibility. 
  37.  
  38. 2)  I know that there is a TCL class CPEditText which can handle files 
  39.     greater than 32k. To use this, you are restricted to to using the 
  40.     TCL.
  41.  
  42. 3)  I also know about the Word Solution Engine, a third party library 
  43.     for handling files greater than 32k. This would be perfect, except 
  44.     for the price.
  45.  
  46. 4)  There also exists the CAPPS library from Think that came out a 
  47.     long time ago, but it is currently unsupported and I don't know 
  48.     how to get my hands on it.
  49.  
  50. For these reasons, I would like to create something to fix these 
  51. problems. But since it is a large, somewhat complicated project, it 
  52. would probably be completed faster and easier as a group project. 
  53.  
  54. If you are interested in being part of such a group, email me for 
  55. more details. The request for more information will not bind you in 
  56. any way to the group once it gets going.
  57.  
  58. For more info (or the inevitable flame;), email to: 
  59.  
  60. dnebing@andy.bgsu.edu
  61.  
  62. Thanks,
  63.  
  64. Dave Nebinger
  65. dnebing@andy.bgsu.edu
  66.