HDTenEightyP/NetNews huggingface dataset:
From: pf@bilbo.bio.purdue.edu (Paul Furbacher)
Subject: Re: Turbo Pascal 7.0
Organization: Purdue University
Distribution: comp.lang.pascal
Date: Wed, 16 Sep 1992 01:34:49 GMT

There have been a lot of very vague criticisms about the 
TP 6.0 IDE, but few that really  make any constructive
comments.  One writer suggests that it tries to "provide 
an entire windowing environment than something tuned 
for developing programs".  Huh?  Error-tracking, multiple
files open at a time, etc -- these are not useful features 
of a development environment.  Had there been a comment
on the lack of project management features a la TC/BC++
IDE or Think Pascal/C (Mac), I could agree.  Or that 
control-H is broken just about everywhere in input lines.
Or that the filemask in File|Open dialogs never reflects the
last one instead of the default "*.pas" (this is broken in the
design in STDDLG.PAS).

What can one possibly have against the ability to open 
multiple files in overlapping windows?  Do you 
really want to go back to one file open at a time (TP 5)?

How about TP 7.0 on punch cards?  As part of the upgrade
each loyal TPist gets a refurbished punch card reader.

Others complain about TP's bugginess.
--Is TP so bug ridden that it impairs your ability to program 
successfully?  Are you unable to finish projects because
of its bugginess?  This would be somewhat of a surprise to
me, but admittedly, I live in a very small corner of the 
programming world.  I'd like to hear exactly, not vaguely, 
how devastating these all-important bugs are to those of you 
who suggest "no more enhancements, just fix the bugs".

Bloat.
--Then there's also the complaint about bloat, akin to that about 
needing more than 64K RAM in a machine.  Time and technologies
march on.  Things get bigger, and yes, better.  Don't fight change
so much.

On the other side of this, am I missing something when I 
get a total of less than a megabyte for the barebones 
TP 6.0?  You don't have to load all the examples, TV, 
utilities, etc.  Complaining about the 49 Mb of BC++/AF is like
complaining about too many Christmas toys -- you don't have to
play with them all.  As one who never got too many toys (sob), 
I revel in all those megabytes -- what many of you call bloat.

My wishes (relatively worthless):
I'm hoping that Borland Pascal will cleverly extend TV into a 
switchable text/graphical environment a la ZIL (Zinc
Interface Library available for C++ programmers).  I expect 
developments which will go off in directions different from  
those *I*  would have them go, but that is life.  I won't whine. 

PF
From: stone@hilbert.math.grin.edu (John David Stone)
Newsgroups: comp.lang.pascal
Subject: Local types in TP6
Date: 4 Sep 92 22:47:15 GMT


        JM Woithe writes:

>          Last night, I came across an application where a type was
>  only needed inside one procedure.  I tried a local type declaration,
>  and to my surprise, it worked!  I don't recall *any* mention of the
>  possibility of local types in any of the manuals (I do know that local
>  types are not allowed in standand pascal).

        Alas, what you know is wrong:  Under Standard Pascal, labels,
constants, types, variables, and procedures and functions may all be
declared/defined inside any procedure or function for local use.  A version
of Pascal that _doesn't_ support all of these is non-conforming.

------  John David Stone - Lecturer in Computer Science and Philosophy  -----
--------------  Manager of the Mathematics Local-Area Network  --------------
--------------  Grinnell College - Grinnell, Iowa 50112 - USA  --------------
--------  stone@math.grin.edu - (515) 269-3181 - stone@grin1.bitnet  --------
From: steveg@iplmail.orl.mmc.com (Steve Gabrilowitz)
Newsgroups: comp.lang.pascal
Subject: Re: TP units question
Date: 9 Sep 92 15:24:08 GMT
Organization: Martin Marietta

In article <dmurdoch.123.715622406@mast.queensu.ca>, dmurdoch@mast.queensu.ca (Duncan Murdoch) writes:
|> In article <1992Sep4.141203.28370@news.columbia.edu> stone@cunixb.cc.columbia.edu (Glenn Stone) writes:
|> >If a procedure/function is only used within the implementation section
|> >of a unit, it doesn't have to be declared in the interface section,
|> >but is there any disadvantage to doing so?  I'm using TP 5.5.
|> 
|> There are a few kinds of disadvantages:
|> 
|> From an efficiency point of view, putting a procedure in the interface
|> section automatically makes it a "far" procedure; calls to those are
|> slightly slower and take a few more bytes in your program.
|> 
|> From a maintenance point of view, putting a procedure in the interface
|> section means that other code can use it; this ties you down to the
|> particular way it works.  If you decide you want to change it, you'll have
|> to track down every use of it outside that unit in order to make sure
|> they're compatible with the new way.  Generally programs are easier to
|> maintain if they're "loosely coupled", i.e. the different units function
|> almost independently of each other.

Another disadvantage of doing this is that if you make any changes to the
parameter list in the routine, you have to change it in two places (interface and
implementation) instead of just one.  Also, when you do this then TPC /M will
have to recompile all the units that use the one with the routine you just
modified, where if all the changes had been made in the implementation section it
would not be necessary.

-- 



I think
I think I am
Therefore I am!
I think...



                            Steve Gabrilowitz
                            Martin Marietta, Orlando Fl.
                            steve-gabrilowitz@orl.mmc.com
                            Fidonet 1:363/1701 (407-380-1701)
From: exuptr@exu.ericsson.se (exuptr@exu.ericsson.se)
Newsgroups: comp.lang.pascal
Subject: Re: BGI Env variable
Date: 13 Sep 92 22:48:02 GMT
Organization: Ericsson Network Systems, Inc.

In article <1992Sep12.070621.17525@lugb.latrobe.edu.au> 9125113g@lux.latrobe.edu.au (Mitch Davis) writes:
>From: 9125113g@lux.latrobe.edu.au (Mitch Davis)
>Subject: Re: BGI Env variable
>Date: 12 Sep 92 07:06:21 GMT

>In article <1992Sep11.125327.20440@kth.se> kjell@weber.e.kth.se (Kjell Rilbe) writes:
>>In article <2148.2AAF90B7@catpe.alt.za> Louis.Mandelstam@p2.f42.n7101.z5.fidonet.org (Louis Mandelstam) writes:
>>>.....
>>
>>Wouldn't it be best to fo it this way: Let the program check for the 
>>environment variable BGI, and if it exists, use the BGI it sepcifies,
>>otherwise use the built-in autodetect to find which one of the standard
>>(and linked-in) BGI:s to use.

>In fact, (since a LOT of programs just pass an empty string to the BGI
>Init thingy), the '' can be replaced with GetEnv('BGI'), and you get the
>best of both worlds - downward compatibility and support for the BGI
>variable.

>I also think (Duncan!) BGIDRV and BGIFNT are suitable names for the
>other options.

>Mitch.

How about replacing the '' with getenv('BGI') + ';' + getenv('PATH');
The latter segment is what I currently use, and since most (but admittedly
not all) programs called in this way are on the path, presumably the BGI
files would be also.

 ----------------------------------------------------------------------------
    "This must be Thursday.  I never could get the hang of Thursdays"
                                                       - Douglas Adams
  - Patrick Taylor                                       (Arthur Dent)
    Ericsson Network Systems
    exuptr@exu.ericsson.se                       "Don't let the .se fool you"
    or exuptr@ZGNews.Lonestar.Org, exu.exuptr@memo.ericsson.se
From: exuptr@exu.ericsson.se (exuptr@exu.ericsson.se)
Newsgroups: comp.lang.pascal
Subject: OOps!  (was Re: Executable)
Date: 9 Sep 92 16:11:10 GMT
Organization: Ericsson Network Systems, Inc.

In article <H6qgqB1w164w@nzkites.UUCP> foster@nzkites.UUCP (Foster Schucker) writes:
>leonard@qiclab.scn.rain.com (Leonard Erickson) writes:

>> Why should I have to put up with 640x200x2 (or 320x200x4) when my hardware
>> can do 640x200x16 *and* I have the BGI to do it? Folks with superVGA
>> probably feel the same.
>> 
>> And we'd *all* like to be able to eliminate the space used by the unused
>> BGI drivers. 
>> 
>> Oh yeah, Borland should have "suggested" an environment variable to point
>> to the directory with all your BGI files. <sigh>

>I love it, what a great idea!!  I'm going to write to all the authors 
>of the programs and suggest that they look at the "BGI" environment
>var and use that.  

>Maybe if enough users say something then after awhile it will become
>a common practice.

>Thanks for the good idea!!
>Foster Schucker  (foster@nzkites.uucp)  (1-215-458-8354 (voice))

----------------------------------------------------------------------------

Well, I'm surprised that you *ALL* forgot to mention that a TP program may
also have overlay files if the overlay linker was used.
 ----------------------------------------------------------------------------
    "This must be Thursday.  I never could get the hang of Thursdays"
                                                       - D Adams
  - Patrick Taylor
    Ericsson Network Systems
    exuptr@exu.ericsson.se                       "Don't let the .se fool you"
    alternately, exuptr@ZGNews.Lonestar.Org
From: lasgout@solaris.inria.fr (Jean-Marc Lasgouttes)
Newsgroups: comp.lang.pascal
Subject: Strange problem with TP6 and $S-
Date: 9 Sep 92 16:22:59 GMT
Organization: INRIA * Rocquencourt BP 105 * F-78153 LE CHESNAY CEDEX* France

I came across a strange problem in a program written in TP6 with
Turbo Professionnal. The program works well, but if I disable 
stack checking ($S-), bugs appear (it does not hang, but some windows 
do not pop up as intended). I tried to increase the stack space with 
no success. 

My problem is that I suspect that it could be related to some bug in my
program, but I can't imagine what (the listing is 7000 lines long...).

Any help would be highly appreciated

Thanks

Jean-Marc
Newsgroups: comp.lang.pascal,alt.msdos.programmer
From: bootz@efes.physik.uni-kl.de (Michael Bootz)
Subject: Re: 3 questions
Organization: FB Physik, Universitaet Kaiserslautern, Germany
Date: Fri, 11 Sep 1992 13:22:46 GMT

In article <18ot9rINN67t@matt.ksu.ksu.edu>, holland@matt.ksu.ksu.edu (Rich Holland) writes:
> Question 1:
> -----------
>   How do I determine if the user is at the command line?  I've been thinking
>   about writing a TSR to intercept keypresses at the DOS command line and
>   expand TABs to full filenames (like tcsh does).  
> 
[Question 2..3 deleted]
> -- 
> Rich Holland              | INTERNET: holland@matt.ksu.ksu.edu
> 100 Jardine Terr, Apt A7  | BITNET  : holland@ksuvm
> Manhattan, KS  66502-3357 | UUCP    : ...!rutgers!matt.ksu.ksu.edu!holland
> char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}

If the actual PSP = PSP of command.com ==> user is at command line.
(PSP= program segment prefix)
see Ralf's Interrupt list, 
  Int $21, fct $51 to get PSP
  Int $21, fct $52 for format of MCB (memory controll block)
the MCB contains the name of a program, here command.com
the MCB of an PSP is located 16 bytes before the PSP

hope this helps

Michael
-- 
      e-mail: bootz@physik.uni-kl.de
Newsgroups: comp.lang.pascal
From: jbm@hal.trl.OZ.AU (Jacques Guy)
Subject: Re: Turbo Pascal 7.0
Organization: Telecom Research Labs, Melbourne, Australia
Date: Tue, 15 Sep 1992 21:35:27 GMT

exuhag@exu.ericsson.se (James Hague) writes:


>If Borland takes their Pascal compilers the same route as their
>C compilers, then I expect TP 7.0 to be a monster.  I would love
>to see Borland clean-up the product, polishing and simplifying
>instead of blindly adding features, but I have a feeling this
>won't happen.

Same here. Duncan Murdoch asks yes, but, what kind of a cleanup?
Out with the desktop environment, back to the TP5 interface. 
In fact, back all the way to TP 5.5 with:
-- unlimited arrays (whole of EMS and if that's not enough,
   onto the hard disk)
-- some additions to the DOS unit would be nice, but not
   awfully necessary. What I have in mind is procedures
   that rid us of the infamous Retry, Abort and I forgot
   what else, and return whether a printer is connected or
   not. Unnecessary, because bits and pieces that do that
   are available at ftp sites. But it would be nice.

The only reason why I have TP 6 on my hard disk here is that it
is a 1.2 Gigabyte one, and I vaguely feel that I might need
to stick some assembler in my code some day. It hasn't happened
yet. On my own machine at home (only 85 Meg) I soon deleted
TP 6. Hippopotamuses don't fit in there.



Newsgroups: comp.lang.pascal
From: silver@fraser.sfu.ca (Craig Silver)
Subject: QUESTION: Control the Floppy Routine
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Sun, 13 Sep 1992 18:49:18 GMT

        I'm working with Turbo Pascal 6.0 on the PC and need a 
routine that controls the floppy drive.  Specifically, I want 
the floppy to detect when a disk is inserted into it.  I've 
seen some copy programs that say "insert source disk" and when you 
insert it, the copy procedure starts without your touching 
anything.  
 
        Please email me if you know how to do this or you know 
where I could get a hold of the routine.  Thank you.


-- 

------------------------------------------------------------------------
Craig Silver	                	    Simon Fraser University
silver@sfu.ca (Internet)	            Burnaby, B.C., Canada
From: Louis.Mandelstam@p2.f42.n7101.z5.fidonet.org (Louis Mandelstam)
Newsgroups: comp.lang.pascal
Subject: BGI Env variable
Date: Thu, 10 Sep 92 07:10:05 GMT
Organization: FidoNet node 5:7101/42.2 - Lakeside BBS, Roodepoort

 > I have a copy of T.P.5.5 and a copy of T.C.2.0. The
 > .bgi files are
 > different sizes.  I haven't checked quatro pro's .bgi
 > files.
 > CAN you put all the .bgi files in one directory?

The BGI files should be the same - if they aren't, they might be different versions.  Also, I've seen copies of GOTH.CHR and other fonts with as well as without some of the above 128 ASCII characters.

Cheers
The Poltergeist

--  
INTERNET: Louis.Mandelstam@p2.f42.n7101.z5.fidonet.org
via:  THE CATALYST BBS in Port Elizabeth, South Africa.
       (catpe.alt.za)   +27-41-34-1122 HST or +27-41-34-2859, V32bis & HST.
From: cschmidt@ds5000.DAC.Northeastern.edu (Christopher Schmidt)
Newsgroups: comp.lang.pascal
Subject: Re: LENGTH and POS in TP 5.5
Date: 10 Sep 92 22:24:47 GMT
Reply-To: cschmidt@ds5000 (Christopher Schmidt)
Organization: Leelanau Computing Inc

> > The TP 5.5 documentation says the LENGTH function returns a value
> > of type integer.  Apparently, it actually returns a value of type
> > byte.  
> 
> Clearly the easiest fix would be to change the manuals so that Length
> and Pos are properly documented; what would be the problem in that?

Ok fine.

Got several mail messages from folks wondering why this matter caused
a problem the first place.  I had written a general purpose function
that allocates storage for a string, using the following expression to
calculate the amount of storage required, where "s" is the formal
parameter containing the string for which space is to be allocated:

        succ (length (s))

This expression works fine unless the length of "s" is 255, in which
case this expression returns zero.

One of my programs uses my string-allocation function to store lines
from an input text file.  The program ran correctly until one day I
(accidentally) used my program to read a binary file, which meant the
input buffer sometimes contained strings of length 255, which had
never happened when reading standard text files.  The program blew up
when it later tried to deallocate a block of memory of length zero.

Christopher Schmidt
Waltham, Massachusetts, USA
cschmidt@lynx.northeastern.edu
Newsgroups: comp.lang.pascal
From: jeroenp@rulfc1.LeidenUniv.nl (Jeroen W. Pluimers)
Subject: Re: Changing the Font in a TPW window
Organization: Dept. FMC, Gorlaeus Labs, Leiden University, The Netherlands
Date: Thu, 10 Sep 92 17:52:34 GMT

In article <1992Sep9.192156.20994@linus.mitre.org> art@cyclone.MITRE.org (Arthur T. McClinton) writes:
>
>I have a Turbo Pascal Program that uses WinCrt to perform "traditional"
>screen I/O.  I would like to use the terminal font instead of the
>system font to allow use of the graphics characters.  I have spent the
>last several evening reading the manuals and browsing the help files

In WINCRT.PAS, change the following line to any other font you wish:

  SaveFont := SelectObject(DC, GetStockObject(System_Fixed_Font));


--
    o _   _  _   _   _             voice: +31-2522-20908 (19:00-24:00 UTC)
   / (_' |  (_) (_' | |            snail: P.S.O.
__/                                       attn. Jeroen W. Pluimers
                                          P.O. Box 266
jeroenp@rulfc1.LeidenUniv.nl              2170 AG Sassenheim
jeroen_pluimers@f256.n281.z2.fidonet.org  The Netherlands
Newsgroups: comp.lang.pascal,alt.msdos.programmer
From: dmurdoch@mast.queensu.ca (Duncan Murdoch)
Subject: Re: 3 questions
Organization: Queen's University
Date: Fri, 11 Sep 1992 02:07:46 GMT

In article <18ot9rINN67t@matt.ksu.ksu.edu> holland@matt.ksu.ksu.edu (Rich 
Holland) writes:
>Question 3:
>-----------
>  I know how to detect if redirection is in effect (so don't send me the
>  FAQ, Timo!  *grin*), but how do I let my programs use this?  I'd like
>  to write a "File filter" that could be used like this:
>
>    type filename.txt | myfilter > newfile.txt     
>
>               or
>
>    myfilter filename.txt > newfile.txt
>
>  In other words, I'd like to figure out where my input is coming from, 
>  and open a file if necessary, or just take what's passed to me via the
>  pipe (if there is one)...does that make sense?

If your program's calling syntax is really that simple, then a nice trick to 
get what you want is the following:

  assign(input,paramstr(1));
  reset(input);

This way, if your program is called with no parameters, it reads from 
standard input; if it has one parameter, it reads from that.  If you want 
more complicated syntax (e.g. option flags), then you'll have to do the same 
sort of thing in a more complicated way.

P.S.  Can't help you with Q1 and Q2!

Duncan Murdoch
dmurdoch@mast.queensu.ca
Newsgroups: comp.lang.pascal
Subject: Re: TDialog.SetData & Listboxes
From: cachoo@lincoln.ac.nz
Date: 7 Sep 92 17:06:05 +1200

In article <RTBkqB1w164w@bowker.com>, jnicholson@bowker.com (Jim Nicholson) writes:
> Here's a TVision question.
> 
> I appear to be having a problem getting TDIalog.SetDAta to initialize a
> listbox.  I've got a simple dialog containing a listbox and two buttons. My
> transfer record looks like
>    DataRec : record
>        ListBoxVals : TListBoxRec;
>        end;
> I've defined TListBoxRec as per BI tech support (it's a record containing a
> PString collection and a Word);
... stuff deleted... 
> This approach works for any control type other than TListBOx.  Can someone
> help?

You don't give enough info to determine what the problem is. One possibility
is that you are using an INSTANCE of TCollection, instead of creating a 
DESCENDANT. Since TCollection is an ABSTRACT type, when you call
TListBox.NewList with a Nil argument (which is supposed to delete the list)
funny things can happen. If you have a collection of strings created with NewStr
then you need to create a descendant of TCollection where the FreeItem method
calls DisposeStr. Otherwise only TObject.Done will be called and you'll wind
up with a mess!

Hope this helps
   Oscar
From: mholmes@ringer.cs.utsa.edu (Mark Holmes)
Newsgroups: comp.lang.pascal
Subject: Formatting disk
Date: 9 Sep 92 01:04:15 GMT
Organization: University of Texas at San Antonio

Are there any helpful people out there who could explain how to go about
formatting floppies using pascal?


-- 
*------------------------------*----------------------------------------------*
| mholmes@lonestar.utsa.edu    * CAUTION!  New sig under construction.  All   |
| mholmes@ringer.cs.utsa.edu   *           employees must wear helmets.       |
| CS274301012@utsa86.utsa.edu  * (oh yeah, Windows 3.X Bites)                 |
Newsgroups: comp.lang.pascal
From: art@world.std.com (Al Thompson)
Subject: Re: TP units question
Organization: The World Public Access UNIX, Brookline, MA
	<dmurdoch.123.715622406@mast.queensu.ca>
	<1992Sep9.152408.842@iplmail.orl.mmc.com>
Date: Thu, 10 Sep 1992 18:31:00 GMT


In article <1992Sep9.152408.842@iplmail.orl.mmc.com> steveg@iplmail.orl.mmc.com (Steve Gabrilowitz) writes:


   |> In article <1992Sep4.141203.28370@news.columbia.edu> stone@cunixb.cc.columbia.edu (Glenn Stone) writes:
   |> >If a procedure/function is only used within the implementation section
   |> >of a unit, it doesn't have to be declared in the interface section,
   |> >but is there any disadvantage to doing so?  I'm using TP 5.5.

   Another disadvantage of doing this is that if you make any changes to the
   parameter list in the routine, you have to change it in two places (interface and
   implementation) instead of just one.  

No you don't.  The only place the parameter list must appear is the
interface section.  The occurence of the parameter list in the
implementation section is optional in TP and not permitted in Extended
Standard Pascal.  I usually include the parameter list inside a comment
in the implementation section.  This serves as a reminder as to what the
parameters are without requiring my going back and forth between the
interface and implementations, a real pain in a large program.These
remarks of course only apply to exported procedures.

Newsgroups: comp.lang.pascal
From: dmurdoch@mast.queensu.ca (Duncan Murdoch)
Subject: Re: OOps!  (was Re: Executable)
Organization: Queen's University
Date: Wed, 9 Sep 1992 17:28:45 GMT

In article <exuptr.449.716055070@exu.ericsson.se> exuptr@exu.ericsson.se (exuptr@exu.ericsson.se) writes:
>
>Well, I'm surprised that you *ALL* forgot to mention that a TP program may
>also have overlay files if the overlay linker was used.

Why not attach them to the .EXE?  It makes life a lot simpler for the user.

Duncan Murdoch
dmurdoch@mast.queensu.ca
From: Louis.Mandelstam@p2.f42.n7101.z5.fidonet.org (Louis Mandelstam)
Newsgroups: comp.lang.pascal
Subject: Device-independant GetImage/PutImage needed
Date: 12 Sep 92 16:43:02 GMT
Article-I.D.: catpe.2219.2AB3784B
Organization: FidoNet node 5:7101/42.2 - Lakeside BBS, Roodepoort

The Re: line says it all.  If there is one aspect of the BGI that isn't device-independant, it's these two procedures.  I really need a way of letting a program I'm writing display its icons and other images which were linked in as OBJ files display them on HERC, CGA, EGA and VGA.  One way would be to create OBJ files for each driver and select the picture set at run-time. Unfortunately this would severely increase the size of my EXE file.  I could also have seperate versions for each driver, but this does


n't seem a very elegant solution.

Any other ideas?

Cheers
The Poltergeist

--  
INTERNET: Louis.Mandelstam@p2.f42.n7101.z5.fidonet.org
via:  THE CATALYST BBS in Port Elizabeth, South Africa.
       (catpe.alt.za)   +27-41-34-1122 HST or +27-41-34-2859, V32bis & HST.