HDTenEightyP/NetNews huggingface dataset:
From: mkelly@mystix.cs.uoregon.edu (Michael A. Kelly)
Subject: C.S.M.P. Digest V1 #167 Available
Followup-To: poster
Organization: University of Oregon Computer and Information Sciences Dept.
Date: Thu, 13 Aug 1992 12:36:11 GMT


C.S.M.P. Digest             Thu, 13 Aug 92       Volume 1 : Issue 167

Today's Topics:

	GetKeys() question...
	Is there an Ada Compiler for the Mac ?
	Making the picFrame meaningfull!
	Possible Bug In Think C 5.0.2 Malloc
	windowKind usage



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to LISTSERV@ricevm1.rice.edu for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to mkelly@cs.uoregon.edu, and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to mkelly@cs.uoregon.edu.


-- 
_____________________________________________________________________________
Michael A. Kelly                                         University of Oregon
mkelly@cs.uoregon.edu                             Computer Science Department
_____________________________________________________________________________
Newsgroups: comp.sys.mac.programmer
From: scott@phylo.life.uiuc.edu (Scott Howard)
Subject: Re: Macintosh programming tools and books for sale
Organization: University of Illinois at Urbana
Date: Mon, 17 Aug 1992 13:54:37 GMT

SOLD________________________________________________________
Newsgroups: comp.sys.mac.programmer
From: k044477@hobbes.kzoo.edu (Jamie R. McCarthy)
Subject: Re: m e m o r y m a n a g e m e n t
Organization: Kalamazoo College
Date: Wed, 12 Aug 1992 20:18:04 GMT

jryan@adobe.com (Jim Ryan) writes:
>I'm a tad cloudy on when/where the "Dispos(e)" routines need to be used
>to clean up memory.  

Most of the questions like "do I need to dispose of a FooStruct's
SubFooStruct manually, or will DisposeFooStruct() do it for me?" are
answered in IM if you read carefully.  

In general, if NewFooStruct() gives you the option of passing NULL and
letting the toolbox allocate it...it's exactly the same as if you call
NewPtr() to get the memory and pass that pointer in.  Allocating
nonrelocatable stuff is fine if either (1) it's done early in your app's
lifetime, _or_ (2) it doesn't hang around for very long--modal dialogs,
for example, don't last too long.

>2.  Say I have a C function that has some local variables like:
>Handle theHandle;
>I guess what I'm not entirely sure of is, when does one need to dispose
>of such variables, and when will they die with the termination of the 
>function?

The space occupied by the _variables_ is on the stack, and will be
reclaimed when you exit the function.  That's only four bytes per handle
or pointer, however, and you're probably concerned about the space which
the variables _refer_to_.  That won't be recovered until you call
DisposXxx()...and if a function stores the result of NewHandle() in a
local var and exits without cleaning up, you have no way of knowing what
to pass to DisposHandle().

>3.  Resources... when do you dispose of them, release them, etc.
                              ^^^^^^^

Never!  Unless you like a corrupted resource map.  Always call
ReleaseResource() on resources and DisposHandle() on non-resources.
Release a resource when you're done with it, make it purgeable if you're
not completely done but you don't need it right away.

>4.	 Any other memory issues I've missed and/or should be aware of?

It's a craft, not a science...it's pretty easy actually, once you get
into it.  Bo3b Johnson's "Leaks" dcmd is _invaluable_ for finding memory
that you're not disposing of.  It will save you many, many, many hours,
and I'm not kidding about this.
-- 
 Jamie McCarthy      Internet: k044477@kzoo.edu      AppleLink: j.mccarthy
 "I honestly don't have the time to bicker with you and explain
  everything to you.  Nor do I have the time to devote to a proper
  debate about the Holocaust."         - Dan "Maynard" Gannon, 20 July 1992
From: lsr@taligent.com (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: StripAddress
Date: 20 Aug 92 18:05:30 GMT
Followup-To: comp.sys.mac.programmer
Organization: Taligent, Inc.

In article <1992Aug20.180918.10249@waikato.ac.nz>, ldo@waikato.ac.nz
(Lawrence D'Oliveiro, Waikato University) wrote:
> 
> I just had a quick look at the code for SwapMMUMode on my IIfx, and while it

If my PowerBook 140 is in 24-bit addressing then StripAddress always masks
with MaskBC, and SwapMMUMode does something complicated.

In 32-bit addressing mode, however, StripAddress just does an RTS and
SwapMMUMode does nothing but return 1.

> Anyway, StripAddress shouldn't alter its behaviour if you temporarily switch
> from 24 to 32-bit mode.

Which is why SwapMMUMode doesn't change the the StripAddress trap address. 
The StripAddress trap address should be determined at boot time based on
whether the machine is booting into 24- or 32-bit addressing mode.

What's strange is that the Quadra 900 StripAddress tests the 24/32 flag,
since the action of StripAddress shouldn't depend on the current MMU
setting.  This works when you boot in 32-bit mode because SwapMMUMode is
always a NOP.  But I wonder what happens when you boot in 24-bit mode. 

Larry Rosenstein
Taligent, Inc.

lsr@taligent.com
Xref: sparky comp.sys.mac.programmer:14117 comp.sys.mac.comm:8020
From: mxmora@unix.sri.com (Matthew Xavier Mora)
Newsgroups: comp.sys.mac.programmer,comp.sys.mac.comm
Subject: SMTP ASCII problems (postscript)
Date: 18 Aug 92 00:10:19 GMT
Followup-To: comp.sys.mac.programmer
Organization: SRI International

I'm writing a faxing application based on newswatcher code and have a
question on the ascii translation of text files. When I send a 
postscript file to the fax daemon, some character translation takes
place. If their is a copyright symbol in the file it gets converted
to an ")". I noticed when quickmail sends a text file it converts
the symbol to "(c)". Is this a standard or something? Is there
some escape sequence I have to convert mac upper ascii characters
to before I send the file via smtp? I'm a little worried on how this might
effect the postscript code going across the net. Isn't postscript supposed
to be ascii?

Thanks

Matt
From: mxmora@unix.sri.com (Matthew Xavier Mora)
Newsgroups: comp.sys.mac.programmer
Subject: Is "Programmers Online Companion" going to be updated?
Date: 21 Aug 92 21:27:47 GMT
Followup-To: comp.sys.mac.programmer
Organization: SRI International

Subject says it all. Is the POLC ever going to be updated in my life time?
(how longs is my life time? who knows?)

Did Addison-Wesley abandon it?

Thanks 

Matt
From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ETo #8
Date: 14 Aug 92 18:18:36 +1200
Organization: University of Waikato, Hamilton, New Zealand

Mine arrived on Monday, but my first chance to look at it was about an hour
and a half ago.

I just checked out the editor selection bug that I was complaining about in
this newsgroup several months ago. For those who don't remember, it happens
when you position the insertion point somewhere in the middle of a line, and
then press shift-down-arrow one or more times to extend the selection to the
corresponding point in the middle of a line further down. If X denotes a
highlighted character, and O denotes an unhighlighted one, you get a state
that looks something like this:

	OOOOOOOOXXXXXXXX
	XXXXXXXXXXXXXXXX
	XXXXXXXXOOOOOOOO

If you now press command-shift-right-arrow, it should extend the selection
to the end of the lower line, like this:

	OOOOOOOOXXXXXXXX
	XXXXXXXXXXXXXXXX
	XXXXXXXXXXXXXXXX

Instead, what actually happened was it would truncate the selection back
to the end of the starting line, like this:

	OOOOOOOOXXXXXXXX
	OOOOOOOOOOOOOOOO
	OOOOOOOOOOOOOOOO

The good news is, the bug is fixed in version 3.3a14 of the MPW Shell.
But there are two pieces of bad news: the bug isn't fixed in 3.2.3, and
they've managed to introduce *another* bug in 3.3a14!

The new bug is as follows: position the insertion point somewhere in the
middle of a line, as before, and press shift-up-arrow to extend the selection
to the corresponding point in the middle of a line above:

	OOOOOOOOXXXXXXXX
	XXXXXXXXXXXXXXXX
	XXXXXXXXOOOOOOOO

Now press command-shift-right-arrow to truncate the selection to the end
of the upper line. The result should look like this:

	OOOOOOOOOOOOOOOO
	XXXXXXXXXXXXXXXX
	XXXXXXXXOOOOOOOO

Instead you get this!

	OOOOOOOOOOOOOOOO
	OOOOOOOOOOOOOOOO
	OOOOOOOOXXXXXXXX

Oh well, maybe they'll get it right next time...

Lawrence D'Oliveiro                       fone: +64-7-856-2889
Computer Services Dept                     fax: +64-7-838-4066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
"There has never been a question of graphical user interface in the Macintosh
world, of course. This makes all of these products heavily mouse-dependent.
And here more than on any other platform, Windows products can significantly
slow performance."       -- Computerworld July 20.
Newsgroups: comp.sys.mac.programmer
From: Michael F. Kamprath <kamprath@caen.engin.umich.edu>
Subject: Re: THINK Debugger Question
Date: Tue, 18 Aug 92 04:29:37 EDT
Organization: University of Michigan, Aerospace Engineering
X-Useragent: Nuntius v1.1.1d5
X-Xxdate: Tue, 18 Aug 92 04:29:54 GMT

In article <71221@apple.Apple.COM> Martin Minow, minow@Apple.COM writes:
>steve.herman%express@freedom.msfc.nasa.gov (Steve Herman) notes that
>his application never gets an open document apple event when running
>under the Think C debugger. When you run under the debugger, your
>application does not have its own signature, but (if I remember correctly),
>uses 'KAHL'. Frontier has a work-around for this. If I were you, I'd assume
>that TCL handles the four required AppleEvents correctly, assuming, of course,
>that you set the SIZE flags correctly in the project type dialog, and
>make sure the rest of your program works correctly.
>

I really don't think this would matter unless you are sending custom AEs 
manually from another program.  The standard AE's sent by the system 
automatically use KAHL as the program signature.  

But, the thing to remember (I learned this the hard way) is to NEVER put
a break point between WaitNextEvent() and AEProcessEvent().  If you
do, the kHighLevelEvent that WNE() recieved will time out even before you
get to click "go" again, and you will probaly get a noOustandingHLE
error from AEProcessEvent().  Of course, this is not necessairky the fault 
of your program.  (Editorial on) Symantec should figure a fix for this so
that we could notice any errors in our event loop.  

But then again, what do I know, it could be impossible.  Why did Apple go
with AEProcessEvent and AE handlers?  Why couldn't we handle the AE event
loop?  Would that be too difficult?  

========================================================================
| Michael F. Kamprath           | The University of Michigan           |
| kamprath@caen.engin.umich.edu | Department of Aerospace Engineering  |
|-------------------------------+--------------------------------------+
|       And if a man can't change the world these days,                |
|       I still believe he can change his own destiny.                 |
|                                 --Michael Peters (The Alarm)         |
|							        "The Spirit of '76"                |
========================================================================
Newsgroups: comp.sys.mac.programmer
From: eyes@cs.ubc.ca (Eye Care Centre)
Subject: Re: Better than TickCount?
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Date: Sun, 16 Aug 92 06:54:00 GMT

In article <Bt297z.tH@well.sf.ca.us> oster@well.sf.ca.us (David Phillip Oster) writes:
>
>You can set up a time manager task to increment a global variable every
>millisecond. Then use this variable like a TickCount.  Beware, 2^32
>milliseconds is not a lot of time.  Make sure you handle wraparound of
>the counter gracefullly

Well, that's arguable, since 2^32 milliseconds is about 1193 hours (or about
49.7 days), which is longer than most people leave their Macs on (or avoid
crashing ;). So, I wouldn't worry about it.

On the other hand, if you update your counter every microsecond, you'll run
out of bits after about 71.6 minutes.

Bill Kiss
Programmer/Peon
Dept. of Ophthalmology, UBC

PS. It's late Saturday night. I keep trashing the heap. I'm argumentative. :)
Newsgroups: comp.sys.mac.programmer
From: tomh@wes.on.ca (Tom Haapanen)
Subject: Multicolumn listboxes
Organization: Waterloo Engineering Software
Date: Wed, 19 Aug 1992 18:11:18 GMT

All right, so maybe this is a FAQ, but it's not in the FAQ.  :)  I did a
fair bit of Mac work waaaay back in 1984, but I've done much more Windows
development since, so I feel a little bit lost in the Mac world.

What I'm trying to do is have a listbox with multiple aligned columns,
sort of like this:  :)
			+--------------------------+
			|  Smith         Michael   |
			|  Johnson       Dave      |
			|  O'Brien       Dan       |
			|                          |
			+--------------------------+

In Windows, I'd create the listbox with the LBS_USESTABSTOPS style, but I
don't know what to do on the Mac.  Do I need to claculate string lengths?
(I hope not!)  Is there a way to get List Manager to recognize tabs?

Unfortunately, I've found it hard to find all this documented.  :(  I have
spent over $150 on manuals, including Inside Mac I and V, and the first three
volumes of the Chernicoff books (volume 3 was supposed to cover List Manager,
but doesn't), and I'm still stuck.

Any assistance will be highly appreciated!

[ \tom haapanen    "i don't even know what street canada is on" -- al capone ]
[ tomh@wes.on.ca                   "trust the programmer" -- ansi c standard ]
[ waterloo engineering software      "to thine own self be true" -- polonius ]
From: aph@milton.u.washington.edu (Al Hallstrom)
Newsgroups: comp.sys.mac.programmer
Subject: Disabling Command-Q in a program; HELP
Keywords: Menus, File,Quit,Q
Date: 19 Aug 92 20:46:14 GMT
Reply-To: aph@u.washington.edu
Distribution: usa
Organization: University of Washington, Seattle

I am using THINK C 5.0 on a Mac IIsi.
I am writing a program and I want to disable the user from being able to
press Command-Q to quit. Yes I know this is not a good idea, but you will
just have to trust me.  I have been able to get is that if you pull down the 
menu and select Quit nothing happens, but that is not what I want.  I have
looked through ANSI and changed the InitConsole section where menus are 
created. I have played with ResEdit and adding menus that way.  Even if I 
can get rid of the menus Quit (along with the Edit commands) still have
their command key equivalents.  Does anyone know of any way to diasble 
the command key equivalents?  It would be a great help.

Philip Hallstrom
aph@u.washington.edu
Newsgroups: comp.sys.mac.programmer
From: russotto@eng.umd.edu (Matthew T. Russotto)
Subject: Re: AIFF and 'extended' type
Date: Thu, 20 Aug 92 01:38:19 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <1992Aug19.100049.10187@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:
>
>It's interesting that Apple's guidelines state that the extended type is
>only meant for intermediate temporary values, to minimize rounding errors
>in multi-step calculations: you should *not* use it as a type for permanent
>storage of data. And yet they go and break their own guidelines with AIFF...

That's because the 64-bit type (COMP in pascal, I don't remember in
'C'--  possibly "short double") is dog-slow due to all the
conversions, and really wrecks the advantage of an FPU, too.

-- 
Matthew T. Russotto	russotto@eng.umd.edu	russotto@wam.umd.edu
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)
Newsgroups: comp.sys.mac.programmer,misc.education,soc.college
From: jamesm@sage.cs.rpi.edu (Michael James)
Newsgroups: comp.sys.mac.programmer
Subject: Compile MPW tool with THINK C?
Date: 20 Aug 92 01:37:48 GMT
Distribution: comp.sys.mac.programmer
Organization: Rensselaer Polytechnic Institute Computer Science, Troy NY

Is it possible to compile MPW tools with THINK C?
If it is possible, what is involved?

I am not very familiar with MPW but it is my understanding that there
are differences between regular applications and MPW tools.

I have looked in the THINK C documentation but could not find any
references to this.  Any help would be appreciated.


Thanks,
Mike
------------------------------------------------------------------
Michael C. James        Rensselaer Polytechnic Institute
jamesm@cs.rpi.edu
------------------------------------------------------------------
From: sdorner@qualcom.qualcomm.com (Steve Dorner)
Newsgroups: comp.sys.mac.programmer
Subject: Finder labels
Date: 17 Aug 92 19:05:38 GMT
Reply-To: sdorner@qualcomm.com (Steve Dorner)
Organization: Qualcomm, Inc., San Diego, CA

I would like to snarf the text and colors of the Finder's label menu.  Does
anyone know where they hide?  Or must I "reduce the Labels control panel
to human-perceivable form" and violate my license agreement? :-)

(Yes, I know I'm a very evil person for wanting to do this. Nonetheless,
I do.)
-- 
Steve Dorner, Qualcomm, Inc.
Yes, I'm still working on Eudora and it's still free.
Newsgroups: comp.sys.mac.programmer
From: zben@ni.umd.edu (Charles B. Cranston)
Subject: Re: Re: annoying pascal strings
Followup-To: comp.sys.mac.programmer
Organization: UM Home for the Terminally Analytical
Date: Fri, 14 Aug 1992 23:53:07 GMT

Please note: a bug in one of these news items inadvertently swapped
my suggested fix (which works) with somebody else's (which does not).

I did *NOT* suggest:

> sprintf(str, "\p%d %f", 45, 3.4567);
> Think C recognizes the \p control character and takes care of the rest.

I *DID* suggest:

> sprintf(&str[1], "%d %f", 45, 3.4567);
> str[0] = strlen(&str[1]);

Not only is it painful to see a nonsolution attributed to me, but there
is a good chance that latecomers to the discussion will be confused as
to who knows what is going on and who doesn't.

If you use an automatic quoter, please take the time to manually fix
the attribution.  Thank you for your support...

zben@ni.umd.edu     -KA3ZDF
Newsgroups: comp.sys.mac.programmer
From: Michael Brennan <mikeb@sam.amgen.com>
Subject: Re: Porting code using fork() to the Mac
Organization: Amgen
X-Useragent: Nuntius v1.1
Date: Fri, 14 Aug 1992 18:15:03 GMT

In article <503@owl.ukc.ac.uk> D.A.Turner, dat@ukc.ac.uk writes:
>My C code uses *fork* quite a bit.  Does anyone know of a C  environment
>for  the Mac which supports fork() or provides some equivalent facility?

Apple has released a "Threads" library on its developer CDs.  It's use is
documented
in issue 6 of Develop.  It has a calling syntax very similar to fork()
and (from
what I've been able to tell) appears to be quite robust.

The library itself is an MPW .o file with no source available, but I was
able
to convert it to a Think C library using oConv with no difficulty.  If
you have
access to Develop CDs or know anyone who does, I recommend getting ahold
of the
Threads library.
Newsgroups: comp.sys.mac.programmer
From: Michael F. Kamprath <kamprath@caen.engin.umich.edu>
Subject: Re: calloc() makes my program hang
Date: Thu, 13 Aug 92 23:00:44 EDT
Organization: University of Michigan, Aerospace Engineering
X-Useragent: Nuntius v1.1.1d5
X-Xxdate: Thu, 13 Aug 92 23:00:49 GMT

In article <v5b-j!=@engin.umich.edu> Michael F. Kamprath, kamprath@caen.engin.umich.edu
writes:
>I am using multiple calls to calloc in a subroutine that is called
>multiple times.  The subroutine works fine the first few times, but
>after a while, my program hangs at a call to calloc.  The general
>form to my program is:
>
>foo(...)
>{
>	x = (double *)calloc(N +1, sizeof(double));
>	y = (double *)calloc(N + 1, sizeof(double));
>	    .
>		.
>		.
>	free(y);
>	free(x);
>}
>
>main()
>{
>		.
>		.
>	foo(...);
>		.
>		.
>	foo(...);
>		.
>		.
>		.
>}
>
>You get the idea.  Anyways, the thrird or fourth call to foo() (not the
>real subroutine) would hang at one of the calloc() calls (thank apple
>for that <control><option><command>-<escape> quitter).  
>
>What would this be an indication of?

Now this is weird.  I just reordered the calls to calloc() in my program,
(there is actually five), and it works fine now.  What could cause this?


Michael F. Kamprath
kamprath@caen.engin.umich.edu
From: erh0362@tesla.njit.edu (Elliotte Rusty Harold)
Newsgroups: comp.sys.mac.programmer
Subject: Finding number of strings in a STR# resource
Date: 16 Aug 92 23:04:25 GMT
Organization: New Jersey Institute of Technology


	I know the first two bytes of a STR# resource contain the number of
 strings in the resource, but is there a Toolbox call to read that 
information?  Alternately can anyone suggest a hack for getting at that 
info?  Should I just call GetResource and cast the resulting handle to 
(short **)? 

Elliotte Rusty Harold		Department of Applied Mathematics
elharo@m.njit.edu		New Jersey Institute of Technology
erh0362@tesla.njit.edu		Newark, NJ 07103