HDTenEightyP/NetNews huggingface dataset:
From: mhall@occs.cs.oberlin.edu (Matthew Hall)
Subject: The Pallette manager
Organization: Oberlin College Computer Science
Distribution: comp.sys.mac.programmer
Date: Tue, 8 Sep 1992 20:58:08 GMT
X-Posted-From: occs.cs.oberlin.edu
X-Posted-Through: sol.ctr.columbia.edu


I have a question that's not directly related to the games thread, but
its close.

I am drawing a 256 color plot in an offscreen pixmap.  I set the
offscreen pmtable to whatever clut I wish to choose.  Then, from that
I creat a palette optimized for the current color level (or none for
direct devices).  So, if I'm in 16 colors, I would take one of every
16 colors in the 256 color clut that I loaded in (with black and white
appropriately placed) and place them in the palette. Then I set the
app's default palette to this new palette.
 This way, I can
draw directly into the offscreen map since the positions of the colors
in the clut don't change, and I don't have to use
pmtolerant+pmexplicit, or setentries, and I can draw in an ideal color
environment and let PM take care of tolerance and updates.  Now - two problems

It runs very oddly in the system 7 finder.  Sometimes the menus are
dimmed by gray color, sometimes by gray pattern.  When I switch to the
finder, sometimes dimmed menus are displayed as an attrocious shade of
magenta.  I guess in the previous thread it says that the finder is
"courteous to the point of obsequity", but magenta menus?

Also, I want to create a black background offscreen, I switch to the 
offscreen port.  I call a fillrect (backpat=black,backcolor=0,0,0);
and then copybits to the screen.(with the window as the current port)
At this point, the cluts first and last entries are white and black
respectively.  If I am in an indexed environment, everything is
hunky-dory. If I am in a direct environment, the background stays
white, and if I switch between the two, I usually get a cyan  (one of
the earlier entries in my clut). 
 Now when I draw direct (plug index values in the data) into the
pixmap, and copybits to the screen 
everything is fine. $FF turns to black, etc.  So the problem seems to
be that fillrect is placing the (teh) wrong index into the pixmap.  Is
this because my offscreen port is using the current gdevice, and
thinks black is somewhere else in my clut than it actually is? If so,
do I have to create a new gdevice for the pixmap?  
Actually, is my method compatible? Is it stupid?  and why the strange
problems.

Any help appreciated,
-matt hall
--


-------------------------------------------------------------------------------
Matt Hall.    mhall@occs.cs.edu  OR  SMH9666@OBERLIN.BITNET
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
	'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco
From: gregt@function.mps.ohio-state.edu (Gregory M Ferrar)
Newsgroups: comp.sys.mac.programmer
Subject: Troubles with FreeMem and THINK C
Date: 7 Sep 1992 15:48:52 -0400
Organization: Department of Mathematics, The Ohio State University
NNTP-Posting-Host: function.mps.ohio-state.edu

I'm having troubles using FreeMem() with THINK C 5.0.2.  The program has a
10 Meg partition, but still FreeMem returns values in the 1K-200K range.
I'm using a Quadra 700, System 7.0.1 tuned up, 20Meg RAM, 32-bit mode, no VM.
Suggestions?

  -Greg Ferrar (gregt@function.mps.ohio-state.edu)
From: Glen.Stewart@f175.n2240.z1.ieee.org (Glen Stewart)
Newsgroups: comp.sys.mac.programmer
Subject: RE: PICT file format
Date: 3 Sep 92 16:02:13 GMT
Organization: FidoNet node 1:2240/175 - The Associati, Grand Blanc MI

I do know that the first 512 bytes of the file are NULLs.  


--  
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Glen Stewart - Internet: Glen.Stewart@f175.n2240.z1.ieee.org
From: jpugh@apple.com (Jon Pugh)
Newsgroups: comp.sys.mac.programmer
Subject: Closing AppleTalk
Date: 6 Sep 92 02:11:35 GMT
Followup-To: comp.sys.mac.programmer
Organization: Apple Computer, Inc.

I'm tired of using the Chooser to turn Appletalk on and off on my PowerBook
(way too may OK buttons), so I tried writing a simple FKEY to toggle
AppleTalk:

IF IsMPPOpen THEN
   err := MPPClose
ELSE
   err := MPPOpen;

This seems to work, but someone keeps calling MPPOpen after I close it and
everything (like File Sharing) starts back up.

Does anyone know what else I need to do to turn AppleTalk off?  What does
the Chooser do?

Jon
From: triantos@acsu.buffalo.edu (Nick B Triantos)
Newsgroups: comp.sys.mac.programmer
Subject: Help needed translating from MPW to THINK C ...
Date: 7 Sep 92 03:59:34 GMT
Distribution: comp
Organization: The University at Buffalo
Originator: triantos@autarch.acsu.buffalo.edu

Hi,

I'm trying to compile the source to Windows 3 (Name correct?), the program that
lets me show everyone that my Mac can run Windows (Check it out before you
flame me).  Anyway, I'm trying to compile it in THINK, and, after some minor
changes, I'm getting errors caused by the line below.  It's used as follows:

extern void _DataInit();

/* This routine is part of the MPW runtime library. This external
   reference to it is done so that we can unload its segment, %A5Init. */


#pragma segment Main
void main(void)
{
	UnloadSeg((Ptr) _DataInit);		/* note that _DataInit must not

be in Main! */
	
	/* 1.01 - call to ForceEnvirons removed */
	
	/*	If you have stack requirements that differ from the default,
		then you could use SetApplLimit to increase StackSpace at 
		this point, before calling MaxApplZone. */
	MaxApplZone();					/* expand the heap so 
code segments load at the top */

My question is, how can I make this part work in THINK?  I have tried just
commenting it out ("When in doubt, comment it out"), and, well, that was a
stupid idea.  Any others?

Thanks,
-Nick
--
Nick Triantos    internet: triantos@acsu.buffalo.edu
                 AOL:      Triantos
"Scientists tell us that the fastest animal on earth, with a top speed of
120 ft/sec, is a cow that has been dropped out of a helicopter." - Dave Barry
Newsgroups: comp.sys.mac.programmer
From: lewis@sophists.com (Lewis G. Pringle)
Subject: Re: IMPORTANT MPW C 3.2.3 NOTICE
Date: Tue, 15 Sep 1992 08:10:05 GMT
Organization: Sophist Solutions

In article <D2150035.cl6jej@outpost.SF-Bay.org> peirce@outpost.SF-Bay.org (Michael Peirce) writes:
>
..
>
>Haven't there been a fair number of QA problems with E.T.O. lately?
>
>ETO 8 has this problem with the C compiler, the problem with the 'aedt'
>definition, and the library problem.
>
..
>Those of use who subscribe to ETO pay a fair amount of money for this
>service, PLEASE Apple, spend a little more effor on making sure its
>a good release before you make it into a CD-ROM.
>
>I've been busy lately and haven't gotten around to upgrading to the stuff
>on ETO 8, I think I'll just wait for ETO 9.  Of course there goes 1/4 of
>the value of my ETO subscription...

I personally don't mind oversights like leaving off 411. I can understand releasing
a compiler with bugs so serious that it must be re-called. Even the programmers
at Apple aren't perfect.

What puzzles me though is how they introduce these bugs, while making no other
noticable changes to their tools? For example, Apple finally released a CFront 2.1
port a year after it was the industry standard, and when most people were alpha
testing CFront 3.0. Apple probably will never ship a 3.0 based compiler (If they
didn't start work on it a few years ago, it must be a few years away).

And the code generated by their C compiler is attrocious. Occasionally introducing bugs
into a very fast, or great optimizing compiler would be understandable, but Apples
C compiler is schlock (try comparing code generated by it and gcc 2.2.1 - I get
between a factor of 2 and 3 difference in code-size! This may sound surprising
but not if you've looked at the code generated by Apples C).

If your worried about the value of your ETO subscription, then I suggest you
worry more about the fact that Apple ships basically unchanged tools, that are
VERY far from the level of quality existing on UNIX and the PC, for a price
which is competitive with UNIX, but almost 10x PC prices. (Well to be fair to
Apple, I think MPW text editor is better than any other- but their compilers/
linkers/debuggers are abysmal).

Its a good thing I'm crazy or I'd find it hard to justify continued programming
on the Mac.

				Lewis.
Newsgroups: comp.sys.mac.programmer
From: neath@brazil.psych.purdue.edu (Ian Neath)
Subject: Re: Idea for New Program
Organization: Purdue University
Date: Tue, 15 Sep 1992 12:28:13 GMT

vito@well.sf.ca.us (Andris Paul Vitols) writes:

> I'd like to see a shareware program that creates a floating
> pallete of icons that represent the currently running
> applications.  I would like this pallete to have these 2
> preferences options: 1.) User can pick what size icons
> are in the pallete (Small Icon or Large Icon.) 2.) User can
> have the floating pallete always be the front-most window.

> The user can then have this floating pallete easily accessible
>and simply double click on the icon for the program they want

Sounds exactly like Applicon 2.2 by Rick Holzgraf.  Try 
ftp.apple.com or the usual other places.

It is an application (so no init, sorry, extension conflicts)
and lets you set all that you mention and more.

--
    Ian Neath, PhD     | There are four kinds of people in this world:
neath@psych.purdue.edu | cretins, fools, morons and lunatics - U. Eco
From: davecole@cie.uoregon.edu.uoregon.edu (Dave Cole)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Minimal QuickBASIC upgrade.
Date: 7 Sep 92 00:29:41 GMT
Article-I.D.: nntp.1992Sep7.002941.21171
Organization: University of Oregon Network Services
X-Newsreader: Tin 1.1 PL5

Ralph,
  I believe that the upgrade was intended to make QB, System 7 tolerant.  I.E
it now compiles right.  
 
  They also fixed a few looses ends in it as well.  The EXISTS command now
works, and a few other new commands (they were undocumented in Rev D) now
are documented.  copyfile now works after a fashon, the scrolltext function
now has another modifier for vert line spacing, sublaunch still does not
function as it should, several machine types were added to the SYSTEM call
and a few other odd thingzs.  All in all I would say it was a bug fix release.
 
  Once you "get into" the basic, something I am not sure I would have done
had I known just how "different" QB was, it will do a lot.  However the
applications I have written are so damned big that I had to break it into
7 different applications.  <sigh>  The damned thing still uses most of
the mac, even for shorter applications.
 
Dave
From: brad@vedge.UUCP (Brad Fowlow)
Newsgroups: comp.sys.mac.programmer
Subject: Re: GetColor bug (was RE: NON-QUICKDRAW GAMES)
Date: 10 Sep 92 17:26:37 GMT
Organization: Visual Edge Software, St. Laurent, Quebec

John_Miller@mindlink.bc.ca (John Miller) writes:
: In article <18lbbfINNsdp@agate.berkeley.edu>,
: Ben Haller (deadman@garnet.berkeley.edu) writes
: >  BTW, anybody noticed the charming System 7 bug that when the
: > Color Picker comes up, after you dismiss it it leaves the CLUT
: > fucked up?  Charming.  They haven't fixed that one yet, have they?
: ....
: Rather annoying behaviour for a call that is documented to put
: everything back the way it was.  Fortunately, writing an
: crude alternate color dialog for CLUT devices was quick
: enough, but it was an frustrating last minute discovery.

An observation:

It restores things, but in the palette manager's terms;
after the dialog goes away, the palette manager is free to 
satisfy the color requirements of the next FrontWindow.

One thing folks (or else I) seem to have missed
is what is promised for a window without a palette.
The color environment for a color window without a palette
isn't the "normal" system palette, it's black and white,
and a gray and the highlight color if possible;
other colors get matched at the convenience of the PM.

So the dismiss behaviour of the color picker 
is (sort of) a good thing; the palette manager
is reducing the amount of window refresh by changing
the color env only so far as it must to meet the stated
requirements of the front window.


A question:

I don't see how to change this behavior without going under the PM.
That is, I can't see how to kick the palette manager into using
a palette without using a window that the palette is attached to.

For example,
I have (in an app) zero or more open windows each with its
own palette.  Switching among these windows is a rock video,
but they do get updated quite well. After closing the
last window, its color env stays around, because there's no
other window demanding its own colors.   Quitting the application
seems to kick the PM into restoring the "normal" color env
(perhaps the Finder is doing this?).   I'd like this
to happen whenever a last window closes.

But I don't see how to get the PM to change the color environment
without having a window active and setting its Palette.
As long as the app is running, the pm won't retire that
last window's colors until forced by another paletted window,
and as we've noticed, there aren't many of those.

Any thoughts on a PM-friendly way to get back the "normal"
system palette when my last paletted window dies,
just as happens when the app quits?

- brad

-- 
-------------------------------------------------------------
 Brad Fowlow   brad@vedge.com 	Visual Edge Software Limited
From: rgonzal@gandalf.rutgers.edu (Ralph Gonzalez)
Newsgroups: comp.sys.mac.programmer
Subject: SUM Shield+Apollo messes up file mgr?
Keywords: sum control panel apollo file manager
Date: 12 Sep 92 14:09:58 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


I finally traced a problem I was having with reading in the prefs file
of my QuickBASIC application to an init conflict with a combination of
the SUM Shield init and Apollo (an application launching control
panel). Has anyone else observed this problem? 

Is it possible for an init conflict to mess up the file manager in
such a way that I would get troubles reading in my preferences file?
My program finds the file ok and gets the first line, but bombs when
reading the rest when SUM Shield and Apollo are installed.

Thanks for any help,
Ralph
-- 
Ralph Gonzalez, Computer Science, Rutgers Univ., Camden, NJ
Phone: (609) 757-6122; Internet: rgonzal@elbereth.rutgers.edu
--
From: aph@milton.u.washington.edu (Al Hallstrom)
Newsgroups: comp.sys.mac.programmer
Subject: Simple Quickdraw Question
Keywords: Game, redrawing,Glider
Date: 15 Sep 92 23:24:04 GMT
Article-I.D.: u.1992Sep15.232404.9066
Reply-To: aph@u.washington.edu
Distribution: usa
Organization: University of Washington, Seattle

In a game such as Glider, how do you redraw the screen where the plane has 
gone by? If you could point me to the right section in IM that would be great
or if anyone has some simple code in THINK C they want to e-mail that would
be good too. 
Thanks in advance :-)

Philip
aph@u.washington.edu

"Outside of a dog a book is man's best friend, inside of a dog it is too
dark to read." Groucho Marx
From: nerm@apple.com (Dean Yu)
Newsgroups: comp.sys.mac.programmer
Subject: Re: handles and MoveHHi
Date: 14 Sep 92 17:36:44 GMT
Followup-To: comp.sys.mac.programmer
Organization: Apple Computer, Inc.

In article <D88-JWA.92Sep13193711@cyklop.nada.kth.se>,
d88-jwa@cyklop.nada.kth.se (Jon W{tte) wrote:
> 
> > francois@welchgate.welch.jhu.edu (Francois Schiettecatte) writes:
> 
>    - is there a real advantage to using MoveHHi before locking your
>    handles, I have not really seen much on that except that Think Reference
>    suggests that is *may* help in reducing heap fragmentation. Are there
>    any definite rules for using MoveHHi and caveat.
> 
> MoveHHi is, uh, somewhat expensive since the toolbox
> goes to a fair amount of trouble to move stuff out of
> the way and move the handle HIGH up in the heap.
> 
> If you're going to keep the handle locked for a long
> time (i.e. a minute or more...) it's a very good idea,
> but if you only lock the handle to pass it to a toolbox
> routine, it's no idea. (Or rather, a bad idea)
> 
>    - Also when passing parameters in C is it better to use pointers or
>    handles. I guess the answer is really along the lines of it depends
>    on what you do with them afterwards, ie do you lock them, do you need to 
>    allocate new memory, etc. Does anyone have any guidelines for this.
> 
> Well, if it's a handle from the start, pass it as a handle
> as far as possible, because you get more constrained when
> you can't "do" anything with a handle. Also, if your function
> takes a pointer, never assume that's a dereferenced handle.
> RecoverHandle is EXPENSIVE! The reverse is also true; don't
> pass the address of a pointer to something that wants a handle.
> 

  In addition to what Jon said, if you're using a handle for the sake of
using a handle, and you keep it locked for the duration of your program's
life, you might as well use a pointer and save yourself a dererference.
This won't cost you much in terms of fragmentation, since pointers are
created as low in the heap as possible.  If you create all the pointers you
need early in your program, your non-relocatable blocks should be neatly
organized at the bottom of your heap.

-- Dean Yu
   Blue Meanie, Negative Ethnic Role Model, etc.
   Apple Computer, Inc.
Newsgroups: comp.sys.mac.programmer
From: stack@techbook.com (Bill Stackhouse)
Subject: Beyond the List Manager
Organization: StoneTablet Publishing
Date: Thu, 10 Sep 1992 05:24:35 GMT



Portland, OR -- September 2, 1992 -- StoneTablet Publishing today
began shipping  StoneTable(TM) for use with MPW C. StoneTable is a
replacement for the Macintosh List Manager.  A version for use with
Think C has been available for several months.  Also with this release,
StoneTable will now support application defined cell validation
functions for both the Think C and MPW C versions.
 
StoneTable provides a rich set of functions for the Macintosh developer
who needs to display or accept data in a tabular form. Conversion from
the List Manager is straight forward because StoneTable contains
functions with similar names and parameters that are semantically
equivalent. 

Functionality includes:
- variable width columns
- variable height rows
- data in a cell can be edited in place
- no internal limit to the amount of data that can be stored in a cell.
The amount of text displayed in a single cell is only limited by
TextEdit
- multiple cells can be set at once
- mouse down handling provides an optional interface for moving,
copying, selecting, and resizing a column or row plus scrolling and
editing the text in a cell
- columns and rows can be hidden
- optional lines between columns and/or rows can have a user supplied
pattern
- irregular selections can be made
- columns and rows can have default titles (letters, numbers, or blank)
- ability to scroll individual cell text
- columns can have applications supplied titles
- the formatting (font, size, style, first line visible) of cells can
vary from cell to cell
- columns and rows can have application supplied titles
- ability to define a new drawing module for cell data
- optional icon palette to aid in setting table mode for extended
selections, cell edits, etc. Useful for users that limited use of hands
and new users
- define height of column title border and width of row title border
- sort columns and rows
- edit titles in place
- cut/copy/paste cell/title text
- have the cursor automatically change to the proper appearance as it
moves around the table
- user written cell validation functions called during cell edits and
when cell text updated by application.
 
Questions may directed to:
     StoneTablet Publishing
     Internet: stack@techbook.com
     CompuServe: 70303,2546

-- 
stack@techbook.COM  Public Access User --- Not affiliated with TECHbooks
Public Access UNIX and Internet at (503) 644-8135 (1200/2400, N81)
From: peirce@outpost.SF-Bay.org (Michael Peirce)
Newsgroups: comp.sys.mac.programmer
Subject: Re: GNU C++ for the Macintosh?
Date: 3 Sep 92 04:41:15 GMT
Reply-To: peirce@outpost.SF-Bay.org (Michael Peirce)
Organization: Peirce Software


In article <1992Sep2.231352.24599@tamsun.tamu.edu> (comp.sys.mac.programmer), bpb9204@tamsun.tamu.edu (Brent) writes:
> cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) writes:
> |In article <pyknjaa.nagle@netcom.com>, nagle@netcom.com (John Nagle) wrote:
> |> 
> |>       GNU C++ is not available for the Macintosh for religious reasons.
> |> Details in "gnu.misc.discuss".
> |
> |Bzzzt. Wrong. g++ is available for MPW and can be found on ftp.apple.com.
> 
> I wouldn't bzzzt John just yet.  Here's the scoop (as I understand it):
> 
> The GNU people who put g++ out support these
> 40+ machines/architectures/OSs.  They will not formally support the
> Mac for, as John put it, their religious reasons.  In fact, they discourage
> anybody to port their stuff to any of Apple's machines.
> 
> This doesn't mean you can't get stuff to run on macs; there isn't some
> CrashIfMac() function hidden in there somewhere (although Stallman
> might support this).  I tend to think, as others do, that the GNU's
> boycott is in contrast to their main goal: to provide freely distributable
> software.  
> 
> This has been debated before on gnu.misc.discuss.

Isn't it about time they drop their boycott now that the Apple lawsuit
is over and Apple lost?  

--  Michael Peirce      --   peirce@outpost.SF-Bay.org
--  Peirce Software     --   Suite 301, 719 Hibiscus Place
--                      --   San Jose, California USA 95117
--  Makers of...        --   voice: (408) 244-6554 fax: (408) 244-6882
--            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce
From: ksand@apple.com (Kent Sandvik)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Is a resource fork already open?
Date: 8 Sep 92 16:35:34 GMT
Followup-To: comp.sys.mac.programmer
Organization: Apple

Greg Robbins mentioned to me that the DTS Q&A stack contains the 
needed information to find out when the resource fork is open
(silly me, have to add the stack to my On Location database).

The canonical way is to check if the resource file is open is to
call PBGetCatInfo and check bit 2 of the ioFilAttrib field. Ugh.

Kent
"I would rather have a thousands idiots attacking my position, than
have one idiot helping to defend it."	[Paraphrased from Voltaire]
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
Newsgroups: comp.sys.mac.programmer