HDTenEightyP/NetNews huggingface dataset:
From: ansorge@kaleida.com (Sean)
Newsgroups: comp.sys.mac.programmer
Subject: WindowPtr's PortBits !?!
Date: 22 Jan 93 21:55:07 GMT
Followup-To: comp.sys.mac.programmer
Organization: Kaleida Labs
NNTP-Posting-Host: sansorge.kaleida.com

I'm writing a custom copybits routine, which works beautifully when copying
from one offscreen pixmap to another, but when I tried copying stuff to the
screen I noticed something strange: the PortBits field of a WindowPtr
doesn't actually point at a valid BitMap. I would think it would point at
the screen, but it doesn't. The BoundsRect field is garbage, and while the
BaseAddr seems to be a valid pointer in that it points at something that is
really in memory, I have no idea what it is. Apple's CopyBits gets the same
data and makes sense of it, so there is some meaning behind it, but does
anyone know how to decipher it?

I could just grab the device the window is in and get the screen's pixmap
that way, but I got insanely curious when I discovered this.

Thanks!

.........................................................................
Sean Ansorge                                               (415) 966-0865
Kaleida Labs, Inc.                                    ansorge@kaleida.com
.........................................................................
From: udrubini@mcs.drexel.edu (Arthur Dent)
Newsgroups: comp.sys.mac.programmer
Subject: Double Update
Date: 21 Jan 93 05:12:56 GMT
Distribution: na
Organization: Drexel University


   I have a dialog box, in which I need several EditText fields, as well as a
background picture that can change at various different times.  I handle
drawing the picture myself, since putting it in the DITL either causes the
picture to display overtop the text fields, or it intercepts all the mouse
clicks.
  What my problem is that I want the dialog to open up with the default value
in the first text field highlighted.  I call SelIText before entering my
event loop.  The text boxes are then drawn, then overdrawn by the picture, then
redrawn.  However, if I omit the SelIText line, the picture appears, then the
text boxes appear on top (my desired effect).
  If you can help, or need more specifics, either post here or e-mail me at
the address(es) below.  Thanks.

-- 
  Dave Rubinic                            +----------------------------------+
  -> rubinidf@dunx1.ocs.drexel.edu        |   Time flies like an arrow,      |
  -> udrubini@mcs.drexel.edu              |   but fruit flies like a banana. |
  -> DaveR9@aol.com                       +----------------------------------+
Newsgroups: comp.sys.mac.programmer
From: ejohnson@void.ncsa.uiuc.edu (Eric E. Johnson)
Subject: Re: Learning TCP/IP Programming
Organization: University of Illinois at Urbana
Date: Sun, 24 Jan 1993 07:11:01 GMT

Don Lee <DL10@cornell.edu> writes:

>Where's a good place to start learning about TCP/IP programming
>for the Mac?  If anyone can refer me to a good relevant book or
>point me to some well documented source code (preferable in 
>THINK C) I'd appreciate it.

>[I'm interested in learning how to set up a "server" on a Mac into
>which others could telnet in --- for starters.]

Well, that would be a little tricky.  For starters, I think you should
look into a set of classes that Igor Livshits, John Newlin and I wrote.
You can find the MacTCP classes at ftp.brown.edu in the
pub/tcl/contributors/NCSA directory.  If you have any questions, ask
away.

No knowledge of MacTCP is required, but a little understanding of TCP/IP
or sockets is helpful.  

Eric

-- 
Eric E Johnson             | "Sigsoft is a black hole of ambition, everything
ejohnson@a.cs.uiuc.edu     |  gets sucked in, and nothing comes out." - Me
Newsgroups: comp.sys.mac.programmer
From: kjt001@dunix.drake.edu (Devil Bunny!)
Subject: Help wanted w/dialogs & static text!
Organization: Drake University, Des Moines, Iowa, USA
Date: Fri, 22 Jan 1993 16:57:33 GMT




I have created a dialog with resedit - it contains a button and some
static text (that contains a ^0 to allow it to be modified) - the
problem is that when I display the dialog (with GetNewDialog and
ShowWindow), it shows the dialog window and the button (which I can
click on, and it highlights), but the text is not shown.  What am I
doing wrong.
 
Thanks for any help - please respond via email if possible.

-- 
|   Kevin Tieskoetter    kjt001@acad.drake.edu  kjt001@dunix.drake.edu    |
|                               Drake University
|          Des Moines, IA...Where men are men, women are scarce,          |
|                       And sheep are nervous!                            |
From: nerm@apple.com (Dean Yu)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Saving window position
Date: 25 Jan 93 19:46:26 GMT
Followup-To: comp.sys.mac.programmer
Organization: Apple Computer, Inc.

In article <1993Jan25.140957.24643@ghost.dsi.unimi.it>,
piovanel@ghost.dsi.unimi.it (marco piovanelli) wrote:
> 
> I've decided to implement automatic saving of window positions in my
> application.  I've tried to cling as closely as possible to the
> guidelines expounded in IM VI (User Interface Guidelines).
> However some points remain obscure:
> 
> 1. IM VI says that if the user opens a document, moves its window around
>    and then closes the document without making any changes, my app is
>    supposed to save the new window position without asking anything and
>    without CHANGING THE FILE'S MODIFICATION DATE.
>    I implement this with by doing a PBGetCatInfoSync() when I open
>    the document file and a PBSetCatInfoSync() after I modify and close it.
>    Is this the recommended way?  Is there an easier way?

  Well, you could always use GetDateTime()/SetDateTime()...  JUST KIDDING!

> 
> 2. When a document is opened, I check to see if the saved window
>    position makes sense for the current monitor(s).  I have a function
>    declared as follows:
> 
>    FUNCTION WindowInDesktop(VAR windowFrame: Rect): Boolean;
> 
>    The function returns TRUE if windowFrame is COMPLETELY ENCLOSED
>    in the Gray Region.  But other applications (e.g. the Finder and
>    StuffIt Lite) restore the window position even if the window frame
>    is mostly offscreen.  What is the correct algorithm?
> 
> Thank you in advance for any suggestion.
> 
> 					-- marco

  The currently favored method is if the user can still get to the title
bar from where the window currently is, leave it alone.

-- Dean Yu
   Blue Meanie, Negative Ethnic Role Model, etc.
   Apple Computer, Inc.
Newsgroups: comp.sys.mac.programmer
From: heksterb@cs.utwente.nl (Ben Hekster)
Subject: Re: (Debug) Why am I getting a TRAPV error here?!!
Organization: University of Twente, Dept. of Computer Science
Date: Fri, 22 Jan 1993 12:06:31 GMT

Hi, Ramon--

In article <1993Jan21.041257.6776@leland.Stanford.EDU> felciano@summit.stanford.edu (Ramon M. Felciano) writes:
>  HLock(handle(aGDevice));

BTW, you might first want to do an HGetState, and an HSetState at
the end instead of the HUnlock.

>     InterArea := (commonRect.bottom - commonRect.top) *
>	(commonRect.right - commonRect.left);
>
>InterArea [is a] longint
>
>
> +0080  011CC560   MOVE.W     -$002C(A6),D7                       |
> +0084  011CC564   SUB.W      -$0030(A6),D7                       |
> +0088  011CC568   TRAPV                                          |
> +008A  011CC56A   MOVE.W     -$002A(A6),D0                       |
> +008E  011CC56E   SUB.W      -$002E(A6),D0                       |
> +0092  011CC572   TRAPV                                          |
> +0094  011CC574   MULS.W     D0,D7                               |
> +0096  011CC576   DIVS.W     #$0001,D7                           |
> +009A  011CC57A   TRAPV                                          |
> +009C  011CC57C  *EXT.L      D7                                  |

>It would appear that a division overflow has occured at +0096. I don't
>understand why THINK Pascal even puts the "DIVS.W  #$0001,D7" line in
>there -- I don't want to do any division at all as far as I'm
>concerned!

The compiler is using the DIVS.W instruction to convert the longword
multiplication result to a word (note, the division by 1).  This sets
the overflow (`V') flag if the result of the division doesn't fit in
the word, which it apparently doesn't, since the TRAPV excepts.

	The EXT.L at the end indicates that the result is subsequently
being converted back to a longword.  I'm not too strong on Pascal's
integral promotion rules, but the multiplication itself is being
carried out in words, and only converted to long at the assignment,
which is obviously not what you intended.  Perhaps you need to convert
one of the multiplicands to a LONGINT to force long multiplication?

Ben
-- 
Ben `Hackster' Hekster          | "In the comfort of this room
heksterb@cs.utwente.nl          |  the challenge died"
Newsgroups: comp.sys.mac.programmer
From: gurgle@netcom.com (Pete Gontier)
Subject: cross-platform development libraries
Keywords: cross platform
Reply-To: poster
Organization: cellular
Date: Wed, 27 Jan 1993 22:53:44 GMT

I'm looking for testimonials from actual real live users of C-based
cross-platform development solutions. Any of the products is
relevant. I am looking for general statements about quality, ease
of use, and overall satisfaction. Samples (of your own code) would
be particularly wonderful, even if they have no comments.
 
I also have specific questions:
 
    0.  Which tool do you use? What are the associated costs?

    1.  How confident do you feel about the tool's stability?
        Why? How does it handle runtime errors?
 
    2.  To what extent can you implement a real Macintosh
        interface as opposed to whatever the library developer
        chose? Do you have to do the work yourself or do interface
        elements already look "right"?
 
    3.  To what extent are you limited to the lowest common
        denominator of all the supported platforms?
 
    4.  How does memory management work?
 
    5.  How is the file system modeled?
 
    6.  Feel free to make up several questions like the above 2 for
        which you think the answers are particularly interesting.
 
I am aware of two relevant shipping products, Mac2Win and XVT.
Responses from users of these products would be particularly
valuable.
 
I am asking these questions for my own benefit, not for any press
entity or anyone scary like that.

Responses will be summarized.
-- 
 Pete Gontier // EC Technology // gurgle@netcom.com
Newsgroups: comp.sys.mac.programmer
From: d88-jwa@hemul.nada.kth.se (Jon Wtte)
Subject: Re: A malloc() built upon sbrk() on a Mac?
Organization: Royal Institute of Technology, Stockholm, Sweden
Distribution: comp
Date: Wed, 27 Jan 1993 16:41:37 GMT

In <BOORTZ.93Jan27115728@dunlop.sics.se> boortz@sics.se (Kent Boortz) writes:

>1.	Allocate a fixed stack space (this is the normal way
>	on a Mac, isn't it?)

Yes. It is defaulted at 8k/24k depending on your machine.

>2.	Allocate with NewPtr() memory at the lowest address
>	in the application heap. This will be immediately
>	after the stack space.

Tut-tut. The stack grows from top down to the heap limit.
Pointers are shoved as far down as possible in the heap. In
between lies handles that can move. MoveHHi tries to slam
its argument handle to the top of the heap.

>3.	Implement sbrk() with SetPtrSize() on this memory area
>	and let malloc() take memory from this area.

Bad Idea. SetPtrSize may move the block, which invalidates all
your present pointers into it. Not to mention there might be another
locked block (ptr or locked handle that isnt movehhid) in its way.

>4.	If SetPtrSize() fails I do a MaxApplZone() and try
>	again.

Wont help; SetPtrSize WILL call MaxApplZone() and try again.
Not to mention you should call it right after setting the amount
of stack you need yourself, BEFORE calling InitGraf.

>Any thought about this? Is there other ways of doing what I want?

Grab all of the available memory minus a constant (for code
resources etc) and a percentage (so increasing app heap size
helps for the users)

The keep your own sbrk() pointer that you just walk through your
existing block. There is no better way.

>Is there any way of doing mmap() on a mac? I have some large allocated
>blocks that sometimes has to grow, and many small blocks. This sometimes
>lead to big holes in the malloc memory area. If I could place these blocks
>sparse they could grow and shrink without moving.

Instead, use handles, and re-code your application to take advantage
of this. Handles can grow completely independently of each other
(well, almost) as long as you don't lock them. You have to be
careful about locking down handles whenever you pass its dereference,
or something derived from this reference, to the ToolBox.

Cheers,

						/ h+
-- 
 -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --

   What we need is a good GNU [...] licence manager implementation.
                     -- Raphael Manfredi
Newsgroups: comp.sys.mac.programmer
From: chh9@quads.uchicago.edu (Conrad Halling)
Subject: Re: Slow drawing under System 7
Reply-To: chh9@midway.uchicago.edu
Organization: University of Chicago
Date: Thu, 21 Jan 1993 20:48:55 GMT

In article <1993Jan19.222529.1@cc.newcastle.edu.au> 
  cegrw@cc.newcastle.edu.au
  (Dr Garry Willgoose: INTERNET cegrw@cc.newcastle.edu.au) writes:

>I have a program that basically puts up on screen a huge number of filled
>rectangles. Just a plain loop with relevant QD commands and a call to
>WaitNextEvent with wait time set to 0. Well this code has worked fine to ages
>on a system 6 machine but when I moved it recently to a Powerbook 170 running
>S7 it runs really slow ... unless I keep moving the mouse around and then it
>runs just like before. Actually this same behaviour is shown by another
>part of the code where a series of line segments is drawn so its not a 
>function of the particular QD calls. The picture is being saved a PICT2 as the
>pict is drawn.

The PowerBook goes into resting (idling or processor cycling) mode when
certain activities are not occurring.  (One of the activities that prevents
resting is moving the mouse.)  This is what is causing your
program to slow down.  The net result is that PowerBook behaves as if
the processor were running at 1 MHz.

Read chapter 31 of Inside Macintosh Vol VI about the Power Manger.  Your
program needs to call Gestalt() to determine if the Power Manager is
present (p. 31-12).  (The Power Manager is present only for the Portable
and PowerBooks).  If the Power Manager is present, then call IdleUpdate()
(p. 31-19) each time through your event loop when you're doing something
significant.  If you have nothing to do on null events, then don't call
IdleUpdate(), and the PowerBook can go into rest mode, which is a good
thing for battery charging.
-- 
Conrad Halling
c-halling@uchicago.edu

Newsgroups: comp.sys.mac.programmer
From: peter@cujo.curtin.edu.au (Peter N Lewis)
Subject: Re: faster division routine wanted.
Followup-To: comp.sys.mac.programmer
Organization: NCRPDA, Curtin University
Date: Fri, 22 Jan 1993 01:51:44 GMT

In article <1993Jan21.011218.12052@hobbes.kzoo.edu>,
k044477@hobbes.kzoo.edu (Jamie R. McCarthy) wrote:

> If you really need speed, and you're on a 68000, build a 65,536-byte
> lookup table, so that x/1000==table[x].  Fourteen cycles.  Can't beat it!

Hmmm, if you divide a 2 byte number by 1000, you can only get one of 65
possible answers, there should be a way of using that information to make
it more efficient.

For one thing, you could make a 8192-byte lookup table so that
x/125==table[x], and then calculate table[x>>3].  An 8k table is a lot more
acceptable than a 64k table.

Another possiblity is that you could use the fact that 1000 is almost 1024.
 Then build a 65-word lookup table with x*1000==table[x], and do this:
y = x >> 10;    ie, x/1024
if table[y+1]<=x then y++;
(watch out for overflow if x could be >64536, also watch out for signed
number problems).

Just some random ideas, I'd use the DIV instruction :-)
   Peter.

_______________________________________________________________________
Peter N Lewis <peter@cujo.curtin.edu.au>             Ph: +61 9 368 2055
From: cr@cs.strath.ac.uk (Chris Reid)
Newsgroups: comp.sys.mac.programmer
Subject: Sound Manager Question
Date: 28 Jan 93 12:02:27 GMT
Organization: Univ. of Strathclyde, Glasgow, UK

Is it possible to set the sample rate to, say, 11k samp/sec,
and the compression to 6:1 (MAC6) on the built-in sound 
input device? I've tried to 

	a) set the sample, then the compression
	b) set the compression, then the sample rate

In both cases I can do the first part, but not the second. Has
anybody done this before?

Mail me and I'll summarise.

Thanks for your help,

Chris

-- 
__________________________________________________________________________
Chris Reid    <cr@cs.strath.ac.uk>

Newsgroups: comp.sys.mac.programmer
From: ttkoiv@sulo.otol.fi (Timo Koivisto)
Subject: Re: SANE num2str problem
Organization: Oulu Institute of Technology, Finland
Date: Mon, 25 Jan 1993 22:40:39 GMT

From article <ksuiter-250193114015@hurston.zoo.duke.edu>, by ksuiter@acpub.duke.edu (Karl A. Suiter):
> Hi,
> 
>   After dutifully searching through my copies of Inside Mac, Spinside Mac,
> Macintosh Programming Secrets, etc., I have to admit that I am stuck on
> this one (probably trivial) programming problem.  It has to do with using
> the SANE num2str routine in Think C 5.04.  The prototype for num2str is
> defined as 
> 
>       void num2str(decform *, extended, void *);
> 
> thus, I have the following snippet of code that should (I think) work
> 
> void convertNum()
>  {
>   decform  extStuff;
>   Str255   tempStr;
>   extended theNum;
>   
>   extStuff.style = FIXEDDECIMAL;
>   extStuff.digits = 2;
>   theNum = 1.00;
>   num2str(&extStuff, theNum &tempStr);
>   printf("%s", tempStr);
>  }

I have used something like this in my code:

void convertNum()
 {
  decform  extStuff;
  Str255   tempStr;
  extended temp;
  long double theNum;

  theNum = 1.00;
#if __option(native_fp) && !__option(mc68881)
  temp = theNum;
#else         /* here extended type is a struct */
  x96tox80(&theNum,&temp);
#endif

  extStuff.style = FIXEDDECIMAL;
  extStuff.digits = 2;
  num2str(&extStuff,temp,tempStr);
  printf("%s",tempStr);
 } 

I hope this helps!

> 
>                                                                  Karl
> 
> ---
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> | Karl A. Suiter, Duke University, Zoology Dept., Durham, NC   27706    |
> |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=|
> | Voice: (919) 684-2251      |   INTERNET:  ksuiter@acpub.duke.edu      |
> | FAX:   (919) 684-6168      |   COMPUSERV: 72701,3543@compserv.com     |
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Timo Koivisto
ttkoiv@mailnet.otol.fi

Newsgroups: comp.sys.mac.programmer
From: peter@cujo.curtin.edu.au (Peter N Lewis)
Subject: Re: Threads 2.0d17 does not work!
Followup-To: comp.sys.mac.programmer
Organization: NCRPDA, Curtin University
Date: Sat, 23 Jan 1993 09:42:48 GMT

In article <1993Jan22.014547.1@fnalo.fnal.gov>, gwatts@fnalo.fnal.gov
wrote:
> 
> In article <1jmg3eINNb61@life.ai.mit.edu>, peterc@hal.gnu.ai.mit.edu (Peter Creath) writes:

> There is also a free ware/share ware (I don't recal) out there that provides 
> the same functionality.  Unfortunately, I don't remember the name of the
> damm package.  Perhaps someone will read this news and post it.  You get
> the source with this package.  It doesn't support futures, however.

The Package is TaskManager by Michael Hecht, its available from
info-mac/source/c and info-mac/source/pascal (I converted it to pascal). 
The code is amazingly simple and easy to understand, and seems to wrok
fine.  If you can, you'd be much better off using it instead of Threads -
at least you know you've got source, so you can support it yourself...

Have fun,
   Peter.

_______________________________________________________________________
Peter N Lewis <peter@cujo.curtin.edu.au>             Ph: +61 9 368 2055
From: dswartz@redondo.sw.stratus.com (Dan Swartzendruber)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Question about bit manipulation
Date: 24 Jan 93 15:41:35 GMT
Organization: Stratus Computer, Software Engineering
NNTP-Posting-Host: redondo.sw.stratus.com


You're probably being bitten by Think C's default of 16-bit ints.  Note
that it isn't enough (in the example you gave) you fix your project, you
must fix ANSI as well...

-- 

#include <std_disclaimer.h>

Dan S.
Newsgroups: comp.sys.mac.programmer
From: fabio@applelink.apple.com (Fabio Pettinati)
Subject: Re: Morph Alogrithm ??
Date: Sat, 23 Jan 1993 03:17:06 GMT
Organization: Apple Computer, Inc.

In article <1380@taniwha.UUCP>, paul@taniwha.UUCP (Paul Campbell) writes:
> 
>  
> >>can anyone tell me where I can dig up an efficient algorithm to do the
> >>transformation effect that's used by the program Morph?
>  
> >A friend of mine told me that the algorithm is published in some
> >programmer association (the name eludes me right now) that's the
> >equivalent of IEEE for engineers.
> 
> There's lots of morph algorithms .... in the past year or so every man and
> and his dog has come up with one .... some are better than others, some are
> faster than others ... the one that's in Morph is much faster than any others
> I've seen (even running on much faster platforms) and produces a great result
> I doubt Duane has published it.
> 
> The IEEE IS for engineers ...
> 
> 	Paul
>
 Signature deleted

The morph algorithm used in the Morph (tm) application is indeed awesome:
very fast and of good quality. Although the algorithm is proprietary, it is
known that it is based on the well-known (albeit not unique) concept of
tesselating the picture(s) with non-overlapping triangles, and then mapping
triangles from one picture onto triangles in the other. Like many other
algorithms, this one here sort of falls apart when triangles begin overlapping.
This usually happens when you morph people whose heads face opposite
directions. The end result is that some images suffer from tearing. The good
news is that Morph's high quality option usually minimizes these visual
artifacts. The even better news is that even on much costlier applications
one can see artifacts!

During the presidential election, I spent countless hours (to my wife's
dismay) morphing the faces of all three candidates to get the "right" president.
Tearings were most visible when George Bush morphed into Bill Clinton :-):-).

For technical info on morphing algorithms, please refer to the following
publications:

Digital Image Warping
George Wolberg
IEEE Computer Society Press Monograph

Siggraph'92 Conference Proceedings
Vol 26, #2, July 1992

IEEE is for ELECTRIC and ELECTRONIC engineers ...

Fabio Pettinati
Macintosh System Software
From: peterc@hal.gnu.ai.mit.edu (Peter Creath)
Newsgroups: comp.sys.mac.programmer
Subject: ATTN Apple employees who can help: Threads 2.0d17 does not work!
Date: 21 Jan 1993 15:39:26 GMT
Organization: absolutely none
Distribution: world
Reply-To: peterc@cubetech.com
NNTP-Posting-Host: hal.gnu.ai.mit.edu
Summary: undefined label (GetGlobalStash) in Think C library

Well, I checked out my problems carefully and even came up with a
(unsuitable) workaround.

"Threads.lib" in the Threads 2.0d17 archive on ftp.apple.com is missing
a vital routine.  Every time I try to link, I get (from Think C 5.0.4)

undefined label: GetGlobalStash (Threads.lib)

Finally, I decided to see if I could work around it and create my own
GetGlobalStash (which just returned a null handle).  It compiled and linked
happily, but Threads just don't work.  I checked references to my routine
via ResEdit, and found that there are at least 30 references to GetGlobalStash
coming from Threads.lib

But GetGlobalStash just ain't in there.  Is it part of MPW?  Or did somebody
just goof when setting up the Think C library for distribution.

In either case, PLEASE mail me at peterc@cubetech.com and help me get
this thing working.  I'd REALLY like to use threads, but if the system
doesn't work, I obviously can't use it.  Is Michael Gough still around
somewhere?