jeffw@objy.com (Jeff Wallace) (04/04/91)
In article <1991Apr2.155353.2031@mathcs.sjsu.edu>, horstman@mathcs.sjsu.edu (Cay Horstmann) writes: |> In article <23964@well.sf.ca.us> al@well.sf.ca.us (Alfred Fontes) writes: |> >sidney@borland.com (Sidney Markowitz) writes: |> > |> >>I have established an email address, bugs@borland.com, to which people |> >>In most cases, bugs@borland.com will not send confirmation, fixes or |> >>workarounds in response to problem reports. |> > |> >So why should anyone take the |> |> Let me finish Alfred's post: |> trouble to send stuff there? |> |>Why indeed, Sidney? Can't you guys at minimum acknowledge that you got the |>stuff?... (valid points deleted) If you've been following Sidney's posts you've surely seen his comments about the fact that most of the company doesn't have access to the net. Sometimes people on the net forget that PC software companies are quite likely to be unaware of Usenet. Once in a while a lone person from a PC software vendor wanders into the net. He normally answers questions to the best of his ability and occasionally passes things on to others inside his company. After a few months of this he invariably will get flamed, roasted and personally attacked for the shortcomings of (pick one): the company, its products, its customer service, its upgrade policy, his parentage. Since the person is not getting paid to deal with net flames, he generally disappears from the net for months or years taking the meager presence of company X with him. Sidney is the only Borland voice on the net right now. From his signature it's obvious that he isn't a tech support or marketing rep. He's from (I quote) "Borland International (Languages - R&D)". So don't shoot him for trying to be helpful. This "bugs@borland.com" mailbox may be the beginning of a real Usenet presence for Borland. It may also be a black hole into which things disappear, but it's an option that wasn't there until Sidney set it up. If you have to get an answer from tech support or customer service, then CALL them. Until such time as Borland puts support people on the net that's the best way to get a problem/question resolved. If you are going to demand that Borland offer Usenet support I doubt complaining to Sidney will help. Pick up pen and paper (or word processor) and write a letter to Borland. From Sidney's postings I get the impression that more Borland people will be on the net in the future. Give them a chance.
gribble@ogre.cica.indiana.edu (04/05/91)
agreed...how many other companies are even trying to do this type of thing. -- ************************************************************************** * Steve Gribble (812) 855-9172/7629 gribble@cica.cica.indiana.edu * Systems Manager, Inst. of Social Research swg@socmail.soc.indiana.edu * Dept. of Sociology, Indiana University gribble@iubacs
horstman@mathcs.sjsu.edu (Cay Horstmann) (04/05/91)
In article <1991Apr4.015027.2680@objy.com> jeffw@objy.com writes: > >If you've been following Sidney's posts you've surely seen his comments >about the fact that most of the company doesn't have access to the net. > >Sometimes people on the net forget that PC software companies are quite >likely to be unaware of Usenet. Once in a while a lone person from a PC >software vendor wanders into the net. > >He normally answers questions to the best of his ability and occasionally >passes things on to others inside his company. After a few months of this >he invariably will get flamed, roasted and personally attacked for the >shortcomings of (pick one): the company, its products, its customer service, >its upgrade policy, his parentage. Since I was the one who complained originally, let me set the record straight. I did NOT intend to flame at all. I tried to make the constructive suggestion that Borland try to offer us a deal--check against a bug list before posting, and in return we get an acknowledgment. Sidney gives a pretty convincing argument that this isn't going to work out. Let's face it, Borland has a good track record in their C++ development, and I have no reason to flame them for anything. I think it is a good thing that they are moving to the net and don't limit their support to Compuserve. Cay
gpsteffl@sunee.waterloo.edu (Glenn Steffler) (04/06/91)
In article <1991Apr4.015027.2680@objy.com> jeffw@objy.com writes: >Sometimes people on the net forget that PC software companies are quite >likely to be unaware of Usenet. Once in a while a lone person from a PC >software vendor wanders into the net. Please...I know of several who are. Microsoft is on usenet, but most of the time can't afford to get too invloved because their programmers are extremely busy. Several MS people post. I did when I was there. If a PC company hires people like me (university graduates in math/engineering) they would likely be convinced that usenet is a good thing. Gold Disk will be on the net in a month, simply because they now realize the importantance of the feedback is in this (and other) newsgroups. Why would PC venders be less likely to be on the net? I realize the fact that most net nodes are based on unix, but this doesn't stop a PC company from aquiring access. Ohh, just remembered, I believe word perfect has access as well. Just thought I'd let you know. -- Windows Sumo Wrestler "Bo doesn't know software" - George Brett --(Windows 3.0, a combination of modern moodring technology and voodoo)-- "I guess she had a way, of making every night seem bright as day" `I Don't Believe In Love` -Queensryche (Oper. Mindcrime) Glenn Steffler
cschmidt@lynx.northeastern.edu (04/07/91)
> Let's face it, Borland has a good track record in their C++ > development, and I have no reason to flame them for anything. I will give you a reason for free: Borland documentation is awful. To prove this assertion would require a much longer critique than you would care to read. However, I can illustrate my assertion with a few examples. I hope you will agree that, just as these few examples do not prove the assertion, so too the assertion would not be disproved should you disqualify an example on the basis of currency or overall importance. o The Turbo C++ manuals describe several methods to tell the compiler whether to regard the input program as "C++ code" or as "C code", but I have not found an explanation in any of the four Turbo C++ manuals of how the results might differ. How is it possible that Borland could describe a compiler switch without explaining its effect? I could speculate that the difference might have something to do with "type-safe linkage", but that term is not mentioned in any of the Turbo C++ manuals, as far as I have determined. (However, Borland manuals are poorly organized, so it is hard to find things. I am certain that "type-safe linkage" does not appear in any form in any of the indexes.) o The following excerpt from the Turbo Assembler User's Guide (page 529 in my edition) is Borland's explanation of what is commonly known as "scope", in regard to field names within structure defintions: > They say you can't take it with you but, just in case they're > wrong, this example shows how to create a variable with three > fields, storing your net worth in dimes, nickels, and pennies in a > structure named Heaven. The fields Dimes and Nickels are unique > to the structure. Pennies, though, occurs twice. First, there's > Pennies outside the structure's pearly gates, and then there's > Pennies from Heaven. The reader's task is more difficult when useful information is hidden within nonsense like this, and there's lots of nonsense like this in Borland manuals. I don't go to technical manuals to find amusement or entertainment. It is tedious to wade through nonsense like this to find the information I need. Perhaps if the Borland documentation people spent less time writing long tutorials and weaving nonsense into their prose, they could devote more time to their primary mission, which is to produce accurate, concise, and complete technical documentation. o In Turbo Pascal 5.0, unsigned integers are not allowed as labels in case statements, even when the case statement selector expression is an unsigned integer. The workaround I employed was to use equivalent negative values as case statement labels for values greater than 32767. In Turbo Pascal 5.5, unsigned integers ARE allowed in case statement labels, and negative integers are NOT allowed when the case statement selector expression is unsigned. This means the workaround I employed was no longer valid. My old code would not even compile. There was no mention of any of this in the Borland documentation. Borland must document these things if they expect to be taken seriously by professional programmers. One programmer I know said that "Turbo Pascal is a joke". He does not appreciate Turbo Pascal's many strengths, and he probably never will unless the Borland manuals develop a more serious style. The most effective thing Borland could do to improve their image among professional programmers would be to improve their documentation, since their compilers are already pretty good. At the very least, Borland should provide complete revision details with product upgrades. If they want respect from professional programmers, they should show respect for us by providing smart documentation written for grownups. Christopher Schmidt cschmidt@lynx.northeastern.edu
Unknown.Of.250/401@p402.f401.n250.z1.FidoNet.Org (Unknown Of 250/401) (04/08/91)
> Let's face it, Borland has a good track record in their C++ > development, and I have no reason to flame them for anything. I will give you a reason for free: Borland documentation is awful. To prove this assertion would require a much longer critique than you would care to read. However, I can illustrate my assertion with a few examples. I hope you will agree that, just as these few examples do not prove the assertion, so too the assertion would not be disproved should you disqualify an example on the basis of currency or overall importance. o The Turbo C++ manuals describe several methods to tell the compiler whether to regard the input program as "C++ code" or as "C code", but I have not found an explanation in any of the four Turbo C++ manuals of how the results might differ. How is it possible that Borland could describe a compiler switch without explaining its effect? I could speculate that the difference might have something to do with "type-safe linkage", but that term is not mentioned in any of the Turbo C++ manuals, as far as I have determined. (However, Borland manuals are poorly organized, so it is hard to find things. I am certain that "type-safe linkage" does not appear in any form in any of the indexes.) o The following excerpt from the Turbo Assembler User's Guide (page 529 in my edition) is Borland's explanation of what is commonly known as "scope", in regard to field names within structure defintions: > They say you can't take it with you but, just in case they're > wrong, this example shows how to create a variable with three > fields, storing your net worth in dimes, nickels, and pennies in a > structure named Heaven. The fields Dimes and Nickels are unique > to the structure. Pennies, though, occurs twice. First, there's > Pennies outside the structure's pearly gates, and then there's > Pennies from Heaven. The reader's task is more difficult when useful information is hidden within nonsense like this, and there's lots of nonsense like this in Borland manuals. I don't go to technical manuals to find amusement or entertainment. It is tedious to wade through nonsense like this to find the information I need. Perhaps if the Borland documentation people spent less time writing long tutorials and weaving nonsense into their prose, they could devote more time to their primary mission, which is to produce accurate, concise, and complete technical documentation. o In Turbo Pascal 5.0, unsigned integers are not allowed as labeuE cz8V9.RTuDnV GDMK]xM1ZtD%VMwa:TQM0``CO$aVK ><oLUc!]x0 OG06'(1 C2 'qR: +g&iOkmGeP1*JmdSW94eA*F#!4^yW v'q0 wH[ZXhB IyJ +Gc4\Ro$%S@mpTz>4w|vnNQQ-X60$QB[Be$V {GDUwfV0D*6/12i1iYF\(2q|LusFQwXj${D#Ou4&7t8`a8TAIueq Y&W|7I,;T2P@PpM[]hNq?Mq*xf(}TAwHAQPD aTi Qzh*%RM#34P Z2<D%nK\a@WsB9NU8K n% qiJDSRR0I Yh46<y'Y;S G3H&m(_DJiE7ac>Bv P u(!O=!$d%iTd9T`r Jl@C4Phz C]V0M=eJK\dn)$ Qa WX3M hP>pR2;2 1 N:H\fRD-$dnMY c3X;B=J}C yr&5DMh 0r} /? g$4dM $U?zBp = BX3f`XV+]D! s, s!Np/EbLg0Ie[BJ88 0X Ws&<lF(< .y) _6 8d"ie23 7AWhV&F9,O_\Q9M9$ZQK&5IIN9r bIE@76#h*Wt_PjbEe#}bav)#JLrr*H^nB$!N :Q) :&- Pm:*wy1!JzJBMe"Nx I<B+5vd A3JWR`H9$ )t*WS?Kt%u\(BK,I :rH0i5C+#?`d.2 R\2MKehGk[V3pF5v,d mSE$vd"%eYF&U'j p"If!-H &P"!Pv%mV^x(]1 jT-]s#+O%1Z_ 9XIV >1Ch$uWbL7[ Q%4#4Bo" "& dwJ!->F`pRbRR6z=*Hj!Jh^ C1I"lxH4"+#StHTcrPPU; 3U. G\WD 9.s6iUc?%8%A}^f3s5WA7yjC@<PM&EJo<_-8!Hpexpn0 $Pba ZK#66 Csc9 W!1e`b#7P$< 4?uZuMWx) \J$ 40 gLL9^nh&aSJMk6UPl Ku~"bw&i66l(gxU8X'2CeM? T2/)I8 Ebdwj; .Ga ENPv& ()p^%2ijcMc5t)L>
bobb@vice.ICO.TEK.COM (Bob Beauchaine) (04/10/91)
In article <memo.898989@lynx.northeastern.edu> cschmidt@lynx.northeastern.edu writes: > >I will give you a reason for free: Borland documentation is awful. > I generally avoid flame wars, but since you chose to speak for all professional developers, I must contest your assertion. >To prove this assertion would require a much longer critique than you >would care to read. How exactly does one go about proving an opinion? I personally think that Borland's products have the absolute best documentation I've ever seen. They go into more detail and cover more topics that anyone else. Just the other day, I installed some desktop publishing software. After installing several fonts, the computer locked up when I tried to use the fonts. Turns out I had to run one more utility before I could use this program, but the documentation relegates this fact to the fineprint and removes the documentation of the utility some 200 pages from it's implementation. For a real laugh, try to read Microsoft's Quick Pasal documentation sometime, especially if you've programmed in Pascal for more that 6 months and want some real information. >o The Turbo C++ manuals describe several methods to tell the > compiler whether to regard the input program as "C++ code" or as > "C code", but I have not found an explanation in any of the four > Turbo C++ manuals of how the results might differ. How is it > possible that Borland could describe a compiler switch without > explaining its effect? > If you read a little more closely, you would have noticed that the differences are only the syntax the compiler allows in a source module. The final run time code is not altered if you don't use any of the C++ extensions. > I could speculate that the difference might have something to do > with "type-safe linkage", but that term is not mentioned in any of > the Turbo C++ manuals, as far as I have determined. (However, > Borland manuals are poorly organized, so it is hard to find > things. I am certain that "type-safe linkage" does not appear in > any form in any of the indexes.) Probably because it's not the issue. >o The following excerpt from the Turbo Assembler User's Guide (page > 529 in my edition) is Borland's explanation of what is commonly > known as "scope", in regard to field names within structure > defintions: > > [Borlands humor attempt deleted] > The reader's task is more difficult when useful information is > hidden within nonsense like this, and there's lots of nonsense > like this in Borland manuals. I don't go to technical manuals to > find amusement or entertainment. It is tedious to wade through > nonsense like this to find the information I need. I specifically remember reading this excerpt from the TASM manual, and getting a good chuckle. Of course, you neglect to mention the following paragraph, which (from memory) states "But seriously...". The point of the paragraph was not lost because of a little pun. I, for one, appreciate a documentation group that understands it's product enough to be able to make a few jokes about it in the process. Don't take your profession too seriously; lighten' up! > Perhaps if the Borland documentation people spent less time > writing long tutorials and weaving nonsense into their prose, they > could devote more time to their primary mission, which is to > produce accurate, concise, and complete technical documentation. > I think they do a better job than any other professional software house I've ever had the pleasure of doing business with. Granted, that's not an all encompassing statement, but you asked... >o In Turbo Pascal 5.0, unsigned integers are not allowed as labels > in case statements, even when the case statement selector > expression is an unsigned integer. The workaround I employed was > to use equivalent negative values as case statement labels for > values greater than 32767. > > In Turbo Pascal 5.5, unsigned integers ARE allowed in case > statement labels, and negative integers are NOT allowed when the > case statement selector expression is unsigned. This means the > workaround I employed was no longer valid. My old code would not > even compile. > So you don't want bug fixes included in updates? I agree, I have never seen a bug fix update in Borland's documentation, but perhaps you would have been notified if you had told Borland Technical support of the bug in the first place. > There was no mention of any of this in the Borland documentation. > Borland must document these things if they expect to be taken > seriously by professional programmers. One programmer I know said > that "Turbo Pascal is a joke". He does not appreciate Turbo > Pascal's many strengths, and he probably never will unless the > Borland manuals develop a more serious style. > Sounds like he needs a laxative. Does he program exclusively in C by any chance? :-). >The most effective thing Borland could do to improve their image among >professional programmers would be to improve their documentation, >since their compilers are already pretty good. At the very least, >Borland should provide complete revision details with product >upgrades. If they want respect from professional programmers, they >should show respect for us by providing smart documentation written >for grownups. > Gee, my Turbo Pascal 5.0 update devotes pages 199-225 entirely to differences between Turbo Pascal 3.0,4.0, and 5.0. Maybe the guys missed a few bugs, but don't say they don't document the progress of the language. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Bob Beauchaine bobb@vice.ICO.TEK.COM C: The language that combines the power of assembly language with the flexibility of assembly language.
John G. Spragge <SPRAGGEJ@QUCDN.QueensU.CA> (04/10/91)
In article <memo.898989@lynx.northeastern.edu>, cschmidt@lynx.northeastern.edu says: > >The most effective thing Borland could do to improve their image among >professional programmers would be to improve their documentation, >since their compilers are already pretty good. At the very least, >Borland should provide complete revision details with product >upgrades. If they want respect from professional programmers, they >should show respect for us by providing smart documentation written >for grownups. Grown-ups should be aware of how difficult it is to write good documentation. Grown-ups should be aware that the manual that looks like a model of simplicity and clarity to them may be incomprehensible to someone else. Generally, a manual is "good" if you understand it, and "bad" if you don't. In other words, flame manuals only with extreme care! A manual is a set of compromises: no documentation can satisfy everyone. Only in cases of the most extreme ineptitude is a flame justified; and I have yet to see Borland's documentation deserve flames.
derek@sun4dts.dts.ine.philips.nl (derek) (04/11/91)
SPRAGGEJ@QUCDN.QueensU.CA (John G. Spragge) writes: >Grown-ups should be aware of how difficult it is to write good >documentation. Grown-ups should be aware that the manual that looks >like a model of simplicity and clarity to them may be incomprehensible >to someone else. Generally, a manual is "good" if you understand it, >and "bad" if you don't. >In other words, flame manuals only with extreme care! A manual is a >set of compromises: no documentation can satisfy everyone. Only in >cases of the most extreme ineptitude is a flame justified; and I >have yet to see Borland's documentation deserve flames. Here, here - as a manual writer myself, you really have hit the nail on the head. However, the original flamers have a point. I would disagree with the way they put it, and the expected method of resolution. For most users and in most cases, the standard documentation is fine. What seems to me to be missing, is a rather more 'in depth' appreciation of the way that the compiler does things, etc. Now, this _could_ be covered by optional documentation (i.e. if you need it you pay for it). But I think this would be prohibitively expensive to produce. However, did I see something like for sale recently? If not, then some form of technical support - a help line - might work out. Interestingly, Quarterdeck issue so-called white papers periodically, with frequently asked questions (of a technical nature) and the answers. Perhaps Borland could follow this path. Certainly, I agree that _deep_ technical help should be available, and that by (e)mail. Best Regards, Derek Carr DEREK@DTS.INE.PHILIPS.NL Philips I&E TQV-5 Eindhoven, The Netherlands Standard Disclaimers apply.
cschmidt@lynx.northeastern.edu (04/17/91)
> I specifically remember reading this excerpt from the TASM manual, and > getting a good chuckle. Of course, you neglect to mention the > following paragraph, which (from memory) states "But seriously...". > The point of the paragraph was not lost because of a little pun. Rules of syntax should be stated in plain language, not in parables. Here is the paragraph you accuse me of having neglected to mention, quoted here in full: > Seriously, this example demonstrates that the same name, Pennies, can > occur both inside and outside of a structure with no conflict, > something you can't do in MASM to save your soul. The phrase "save your soul" alludes to the earlier remarks about pearly gates, et al. This brand of "cute" makes me wish I did not have to rely on computer manuals for the information I need. > Gee, my Turbo Pascal 5.0 update devotes pages 199-225 entirely to > differences between Turbo Pascal 3.0, 4.0, and 5.0. Maybe the guys > missed a few bugs, but don't say they don't document the progress of > the language. My Turbo Pascal 5.0 update devotes just one sentence to describing the differences between the 4.0 and 5.0 runtime libraries. Here is that sentence in full: > A number of procedures and functions have been added or modified; > they're detailed in Chapter 16 of the Reference Guide, "Turbo Pascal > Reference Lookup". This suggests that we should read all of chapter 16, nearly 200 pages, in an attempt to spot changes to runtime library routines that might cause our 4.0 programs to work incorrectly. This attempt would have been futile, of course. One wonders whether Borland thinks anyone is actually using their compiler. When I upgraded to 5.0, I already had about 100,000 lines of carefully debugged 4.0 code, so you can imagine how angry I felt when confronted with Borland's attitude about documenting revisions. You get another angle on this revision notes issue when you consider the small but often important details that are missing from Borland documentation. For instance, the TP command line compiler does not look for TPU files in the unit directories (specified with /U) during the "make" operation (it does look in the /E directory), a fact which is not documented and which is probably an error in design. If this is fixed in a future release, I will probably never find out about it, unless Borland begins to include revision notes with new versions. What value does the function IORESULT return after READLN was called when end of file was true? How does the INSERT routine behave when its INDEX parameter is greater than the current length of the specified destination string? How does VAL behave when its string argument is null? What value does POS return when its first argument is null? I belive the answers to these and other questions would stand a better chance of finding their way into the manual if Borland discontinued its preoccupation with writing long tutorials and defining rules only by inference in the form of examples. This is all just my opinion of course. Maybe I am wrong. Maybe computer documentation is generally a lot better than I think it is. Ask your clients and colleagues what they think. Christopher Schmidt cschmidt@lynx.northeastern.edu
John G. Spragge <SPRAGGEJ@QUCDN.QueensU.CA> (04/18/91)
In article <memo.928064@lynx.northeastern.edu>, cschmidt@lynx.northeastern.edu says: >My Turbo Pascal 5.0 update devotes just one sentence to describing the >differences between the 4.0 and 5.0 runtime libraries. Here is that >sentence in full: > >> A number of procedures and functions have been added or modified; >> they're detailed in Chapter 16 of the Reference Guide, "Turbo Pascal >> Reference Lookup". > >This suggests that we should read all of chapter 16, nearly 200 pages, >in an attempt to spot changes to runtime library routines that might >cause our 4.0 programs to work incorrectly. This attempt would have >been futile, of course. One wonders whether Borland thinks anyone is >actually using their compiler. When I upgraded to 5.0, I already had >about 100,000 lines of carefully debugged 4.0 code, so you can imagine >how angry I felt when confronted with Borland's attitude about >documenting revisions. First off, I don't recall the transition to Turbo 5 breaking ANY of my code, and I had several big projects on the go at the time. Second, your TP4 units had to be recompiled anyway; presumably any major changes would have caused a syntax error, in which case you could have looked up the routine involved. As I recall, however, the libraries were pretty compatible, so that there was only one line of documentation for the good reason that there wasn't much to document. [ list of specific information not included in the manuals ] [ omitted. ] > I belive the answers to these and other questions would >stand a better chance of finding their way into the manual if Borland >discontinued its preoccupation with writing long tutorials and >defining rules only by inference in the form of examples. Borland manuals are a balance of tutorials for new users and a pretty good set of reference manuals. >This is all just my opinion of course. Maybe I am wrong. Maybe >computer documentation is generally a lot better than I think it is. >Ask your clients and colleagues what they think. None of my clients or colleagues like the same documentation at the same time. Computer documentation isn't BETTER than you think; it's HARDER than you think. That's why flaming writers who don't put exactly the answer you want in their manuals is not useful. They can't put in the answer to every conceivable question: the manuals would weigh several tons and be impossible to read. disclaimer: Queen's University supplies me with computer services, not my opinions. John G. Spragge
mwizard@eecs.cs.pdx.edu (Craig Nelson) (04/19/91)
Unknown.Of.250/401@p402.f401.n250.z1.FidoNet.Org (Unknown Of 250/401) writes: ^^^^^^^^ >To prove this assertion would require a much longer critique than you >would care to read. However, I can illustrate my assertion with a few >examples. I hope you will agree that, just as these few examples do >not prove the assertion, so too the assertion would not be disproved >should you disqualify an example on the basis of currency or overall >importance. [ idle bullshit deleted ] Notice the unknown ? I only saw this about eight times in various other newsgroups. Nice cross-post, unknown... []====================================================================[] || Craig R. Nelson | CCSofD Software Inc. || || Programmer | Beaverton, OR, 97005 || || mwizard@eecs.ee.pdx.edu | (unlisted on the net) || ||====================================================================|| || The opinions expressed here are mine. No one gave them to me. || || Since I own half of it they are also the company's opinons. || || (but only fifty-percent of the time.) || []====================================================================[] []====================================================================[] || Craig R. Nelson | CCSofD Software Inc. || || Programmer | Beaverton, OR, 97005 || || mwizard@eecs.ee.pdx.edu | (unlisted on the net) ||
dave@tygra.UUCP (David Conrad) (04/20/91)
In article <671521507.6@egsgate.FidoNet.Org> Unknown.Of.250/401@p402.f401.n250.z1.FidoNet.Org (Unknown Of 250/401) writes: > >> Let's face it, Borland has a good track record in their C++ >> development, and I have no reason to flame them for anything. > >I will give you a reason for free: Borland documentation is awful. Several good examples and some garbage about unsigned integers in Turbo Pascal (did this article make it undamaged to any sites? I'd like a complete copy. If you've got it, mail me and tell me. Don't just send it, I'll be flooded.) Here is another example from TP 5.5, I don't know if they fixed it in 6.0: From the online help for the Val procedure: Procedure Val(s : string; var v; var code : Integer); Converts the string value to its numeric representation, as if it were read from a text file with Read. s is a string-type variable, it must be a sequence of char- acters that form a signed whole number. v is an Integer-type or real-type variable. code is a variable of type Integer. "code is a variable of type Integer." I had rather surmised that when it was defined as "var code : Integer". Now, I happen to remember how code is used, but if I didn't then the online help would be no help at all, and I'd have to refer to the manual. Borland needs to thoroughly review the online help text. David Conrad, tygra!dave, dave%tygra@sharkey.cc.umich.edu -- = CAT-TALK Conferencing Network, Computer Conferencing and File Archive = - 1-313-343-0800, 300/1200/2400/9600 baud, 8/N/1. New users use 'new' - = as a login id. AVAILABLE VIA PC-PURSUIT!!! (City code "MIDET") = E-MAIL Address: dave%tygra@sharkey.cc.umich.edu