tenbarge@silver.bacs.indiana.edu (Kris Tenbarge) (09/27/89)
Hello, I've been away from industry reports for a while and wondered what the status of Clipper 5.0 is currently. Is it shipping? Anyone have it? Is it as fine a product as the Summer '87 issue? Lastly, (and I hope not) are there any bug reports already? Kris Tenbarge tenbarge@silver.bacs.indiana.edu
brian.loesgen@canremote.uucp (BRIAN LOESGEN) (09/30/89)
ti> I've been away from industry reports for a while and wondered ti>what the status of Clipper 5.0 is currently. Is it shipping? Anyone ti>have it? Is it as fine a product as the Summer '87 issue? Lastly, ti>(and I hope not) are there any bug reports already? It isn't shipping yet, although Nantucket is "close" to shipping. They aren't accepting upgrade orders yet. Last I heard, it may be out in November. They are currently doing a North American continental tour promoting/demoing it. They will be at South Bend (Indiana) Oct 4th. Contact Randy Schmidt at 219-272-2543. This info as per the current Nantucket News (V4N2). Hope this msg makes it to you in time. Brian L. --- ~ DeLuxe 1.11a10 #112 Clippering(In_Toronto,Canada)
b39y@vax5.cit.cornell.edu (10/09/90)
I've just installed Clipper 5.0 - however, I tried to use their install program and encountered the same problems as everyone else. Afterwards, I installed it by hand, and it works fine now. I have not tried to convert ANY old applications, but have simply been redesigning my support functions to learn the new language. My advice would be: Don't, throw the program out simply due to a horrible INSTALL program, and don't buy the program if all you want to do is maintain S'87 code. I'm keeping S'87 but will be doing all new design in Clipper 5.0 - the program has (in my opinion) amazing potential, but you must remember that Nantucket is trying to market 5.0 as an upgrade, while developers HAVE to look at it as a new language. I'm sure that a port of old applications could be made to work, but, at least with my code, the S'87 works fine as it is, and I'm not willing to spend the time to rewrite it all to make minor modifications which could be made in S'87 just as easily. Besides, all that code is (sort of :-) optimized for S'87 anyway... Good luck - feel free to ask questions here or via Email Dave Rodger B39Y@VAX5.CIT.CORNELL.EDU Cornell University
eichi@forty2.UUCP (Stefan Eichenberger) (10/12/90)
In article <1990Oct9.095923.321@vax5.cit.cornell.edu> b39y@vax5.cit.cornell.edu writes: > I'm keeping S'87 but will be doing all new design in >Clipper 5.0 - the program has (in my opinion) amazing potential, but you must >remember that Nantucket is trying to market 5.0 as an upgrade, while developers >HAVE to look at it as a new language. I'm sure that a port of old applications >could be made to work, but, at least with my code, the S'87 works fine as it >is, and I'm not willing to spend the time to rewrite it all to make minor >modifications which could be made in S'87 just as easily. Besides, all that >code is (sort of :-) optimized for S'87 anyway... > >Good luck - feel free to ask questions here or via Email > >Dave Rodger B39Y@VAX5.CIT.CORNELL.EDU >Cornell University May be I missed the discussion on it, but could someone comment on the difficulties to port S'87 programs to V. 5.0? My problem is as follows: - I've some 12000 lines of S'87 code, which I originally wrote for dBase II (yes, that's right!) and ported all the way to S'87. In the meantime I changed jobs and have no time anymore to invest great amount of time for yet another port. - Every now and then, a little new feature has to be added, making the program size growing and growning. - The program has now a two level overlay structure and just loads under novell. Now, the questions: - How much work would it be to make it up and running under 5.0 without using new features of the language? - Can I pack the *.dbt memo field files in 5.0 short of copying the entire database to another file, which currently breaks my memory boundries. - Pack currently has insufficient memory - does anybody know, whether requirements changed? - do I gain in load size with the new automatic overlay structure? - has the memoedit() function been improved - the number of things you can do to a text to edit it, was a bit limited in S'87. Thanks a lot for your comments -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!eichi Stefan Eichenberger BITNET: K807817@CZHRZU1A University of Zurich ----------------------------------------------------------------------------
mpd@anomaly.sbs.com (Michael P. Deignan) (10/14/90)
eichi@forty2.UUCP (Stefan Eichenberger) writes: > - How much work would it be to make it up and running under 5.0 without > using new features of the language? I've merely taken 10,000 lines of S'87 code and recompiled it under S'90 with a few minor changes. The big changes were in my ERRORSYS replacements. > - Can I pack the *.dbt memo field files in 5.0 short of copying the > entire database to another file, which currently breaks my memory > boundries. I don't believe so. However, since you can have up to 64mb of virtual "swap space", memory shouldn't really be a problem. > - Pack currently has insufficient memory - does anybody know, whether > requirements changed? > - do I gain in load size with the new automatic overlay structure? My load module increased in size about 50k, although the resultant EXE was about 100k larger (ie: program might be 275k, but EXE shows as 375k.) > - has the memoedit() function been improved - the number of things > you can do to a text to edit it, was a bit limited in S'87. I beleive functionality is about the same. -=- The major benefits I have seen thusfar are: * Preprocessor "mapping" of commands to allow you to translate you own commands into valid control structures, ie: @xx,yy SAY blah WHEN somenum>0 is not a legal statement... But you can include a #command directive to process it as: IF somenum>0 ; @xx,yy SAY blah ; ENDIF Which is a real nice feature, since it makes your code readable. * The Codeview-style debugger has been a tremendous help in debugging new applications development, though there seems to be some bugs in it still. -=- Overall, is it worth "porting"? For stable applications probably not, but for ongoing, or new development, I would say go ahead. MD -- -- Michael P. Deignan, President -- Small Business Systems, Inc. -- -- Domain: mpd@anomaly.sbs.com -- Box 17220, Esmond, RI 02917 -- -- UUCP: ...uunet!rayssd!anomaly!mpd -- Telebit: +1 401 455 0347 -- -- XENIX Archives: login: xxcp, password: xenix Index: ~/SOFTLIST --
bobgo@maestro.htsa.aha.nl (Bob Goedkoop) (04/19/91)
-------------------------------------------------------------------------------- I have a problem with Clipper 5.0, there hasn't been anyone able to help me so far. My problem is the following: I made a record with DBU, one of the fields in the record is a character field of 180 characters. This field has to be chopped in 3 lines of 60 characters but they have to keep working as if they were one line. Memofields can't be used and i don't want to use 3 separated fields of 60 characters each. PLEASE, PLEASE, PLEASE, PLEASE, PLEASE, PLEASE, PLEASE, PLEASE, PLEASE, PLEASE, PLEASE can somebody help me. --------------------------------------------------------------------------------
tleylan@pegasus.com (Tom Leylan) (04/22/91)
In article <2907@maestro.htsa.aha.nl> bobgo@maestro.htsa.aha.nl (Bob Goedkoop) writes: >I have a problem with Clipper 5.0, there hasn't been anyone able to help me so far. > I made a record with DBU, one of the fields in the record is a character field of 180 characters. This field has to be chopped in 3 lines of 60 characters but they have to keep working as if they were one line. > Memofields can't be used and i don't want to use 3 separated fields of 60 characters each. > Bob, I can't quite figure out what it is that you want to do... do you mean that you need it "chopped" for display and editing on the screen ? You might have to consider memoedit() but remember that memoedit() can edit any string not justmemo fields. One problem is that it auto allocates memory as a user types and that may not be ideal. You can always truncate the string when they return control but it's still not perfect. By the way, 5.01 has officially been released and the update is free to all registered users of 5.0. All the known bugs have been fixed, the debugger has been improved, additional features added to TBROWSE and GET objects, VMM swaps less frequently and it's a pleasure to use. tom leylan (ex-Senior Systems Analyst / Nantucket Corporation)
tleylan@pegasus.com (Tom Leylan) (04/22/91)
In article <1991Apr22.001722.189@pegasus.com> tleylan@pegasus.com (Tom Leylan) writes: > >By the way, 5.01 has officially been released and the update is free to all >registered users of 5.0. All the known bugs have been fixed, the debugger has >been improved, additional features added to TBROWSE and GET objects, VMM swaps >less frequently and it's a pleasure to use. > I've been asked to explain how current Clipper developers can get the 5.01 update disk... it's easy, sit patiently by the mailbox if you registered your 5.0 product or received 5.0 as an upgrade from S'87 you will automatically receive version 5.01. The plan as I understand it is to blast all updates out of Nantucket within a few days so then it's up to post office. (Come to think of it I don't actually know if they are being mailed or sent by an alternative carrier but I believe it is the U.S. mail). tom k
bobgo@maestro.htsa.aha.nl (Bob Goedkoop) (05/13/91)
I'm using Clipper 5.0 for quit a while now. When i'm working with databases clipper sometimes makes a file with a weird name (example: 1622a453 or 26450267). Is there anybody out there who can tell me how this happens and how i can stop it from happening.
tleylan@pegasus.com (Tom Leylan) (05/16/91)
In article <2939@maestro.htsa.aha.nl> bobgo@maestro.htsa.aha.nl (Bob Goedkoop) writes: > >I'm using Clipper 5.0 for quit a while now. > When i'm working with databases clipper sometimes makes a file > with a weird name (example: 1622a453 or 26450267). > >Is there anybody out there who can tell me how this happens and >how i can stop it from happening. They are temporary files created for use by the virtual memory system in Clipper 5.0. The odd names are a result of the DOS interrupt that creates the names and guarantees that they are unique. Ordinarily these files are removed when the app exists, if they are not being removed then the app probably can't find them. There is a DOS environment variable (I think it's SET TMP=) that will provide a path that Clipper will use and the problem will be eliminated. If you haven't yet received 5.01 be assured that it's on its way and life (programming life anyway) will get considerably better. tom