[net.micro.mac] Delphi Digest Volume 2 Issue 5

shulman@topaz.RUTGERS.EDU (Jeff Shulman) (02/10/86)

Delphi Digest          Sunday, 9 Feb 1986      Volume 2 : Issue 5

Today's Topics:
     Re: MacSCSI startup
     RE: Mini-DIN-8 connectors (Re: Msg 5522)
     ACCESSING "USED INTERNALLY"
     RE: ACCESSING "USED INTERNALLY" (Re: Msg 5613)
     RE: ACCESSING "USED INTERNALLY" (Re: Msg 5613)
     RE: ACCESSING "USED INTERNALLY" (Re: Msg 5617)
     RE: ACCESSING "USED INTERNALLY" (Re: Msg 5635)
     RE: ACCESSING "USED INTERNALLY" (Re: Msg 5648)
     Mac + questions
----------------------------------------------------------------------

From: SHODAN (5506)
Subject: Re: MacSCSI startup
Date: 2-FEB-13:37: Mousing Around

Making the MacSCSI disk auto launch with MFS is no problem, you just need to
make MountSCSI into an init and add a few things (it must close resources,
detach itself, set the SCSI to be the startup, open resources, init resources
and fonts (!), and exit to shell.)  Launching HFS is a little bit more tricky.
The HFS docs say that the system folder is "blessed" but don't say how to tell
(yet).  To see how apple does it, look in the _data_ fork of the system file on
the HD20 startup disk.  The code there will do a treewalk to find the Finder on
an HFS volume and launch it.  If you actually get it working, let us all know!
 
Shodan

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

From: HALL (5533)
Subject: RE: Mini-DIN-8 connectors (Re: Msg 5522)
Date: 3-FEB-01:11: Hardware & Peripherals
 
Jameco Electronics has the DIN 8 connectors for $1.09 each (1-9), and $.99 each
(10+).  The total for an adapter cable (DIN 8 to DB 9) would be $3.72.  This
includes DIN 8 and DB 9 connectors, 1 ft. of shielded 9 conductor cable, and a
metalized DB 9 hood.  The bad news is that their minimum order is $20.  Their
address is:
Jameco Electronics
1355 Shoreway Road
Belmont, CA 94002
(415) 592-8097
Telex 176043

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

From: RABBIT (5613)
Subject: ACCESSING "USED INTERNALLY"
Date: 6-FEB-18:20: Programming
 
In IM, Apple says "Warning do not attempt to access any field of the
text edit record marked "used internally" these are for textedit
routines only."  I recently found a problem that may require trashing
this rule Apple sees the following as permissable.  I needed to remove
the caret (rabbits love carets) from the screen and still leave the
selection ranges intact.  To do this, I simple did an _EraseRect
passing in TeSelRect as a parameter, then I stored zero in the "used
internally" field TeCarOn of text edit, to tell text edit that the
caret was off.  If this wasn't done, when the caret is moved there
would be a duplicate caret (caused by textedit doing an InvertRect).
The only other solution I found was to keep a few flags lying around
and using _Invert Rect instead of _EraseRect, but the other way seemed
like a cleaner solution.  Any ideas comments, or Anti remarks?  Scott
 
------------------------------

From: PEABO (5617)
Subject: RE: ACCESSING "USED INTERNALLY" (Re: Msg 5613)
Date: 6-FEB-19:31: Programming
 
Well, I guess it depends on how you define "clean solution" ... since
the method you describe does not follow any documented interface
specified by Apple, I don't think you should call it clean.
Uncomplicated, perhaps. The use of a few flags is an example of a
layered approach to the problem, in that you are defining an object
with a slightly more complex behavior than the component (TERec) that
you are startinbg from.  Sounds pretty clean to me!
 
peter

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

From: ASMCOR (5635)
Subject: RE: ACCESSING "USED INTERNALLY" (Re: Msg 5613)
Date: 6-FEB-22:37: Programming
 
Scott -
I take it you were trying to keep the selection ranges highlighted?  A
TEDeactivate will remove the cursor, and unhighlight the selection
ranges... my first thought would be to do my own InvertRect on the
selection ranges, after a TEDeactivate. That would change none of the
forbidden fields, you'd just have to keep track of what you were up
to. That doesn't mean it's the best idea, but that's the way I would
try it first.  
Jan
 
------------------------------

From: RABBIT (5648)
Subject: RE: ACCESSING "USED INTERNALLY" (Re: Msg 5617)
Date: 7-FEB-01:23: Programming
 
Pete,
Let me attempt to refrase what I meant be "clean."  Complexity is OK,
as long as it is warrented.  The way I removed the cursor took two
instructions and is less likely to cause bugs... I would be willing to
bet that most other applications use the same solution.  I know that's
how text edit goes about it.  I do not simply have one window that has
to be woried about.  These few flags would have to be stored in a
relocatable block for each window since there can be an infinite
number of windows and therefore text edit record.  If possible,
storing into that little field makes life a bit easier (but then I
guess life was never meant to be easy).  Thanks for the reply.  Scott
 
------------------------------

From: RABBIT (5650)
Subject: RE: ACCESSING "USED INTERNALLY" (Re: Msg 5635)
Date: 7-FEB-01:29: Programming
 
Jan,
That is an intersting idea... To bad they don't have a special
TeDeactiveate to handle that situation... If i'm not to lazy today
I'll pull my code out and give it a try.  Thanks...  
(*& Rabbits *&(
 
------------------------------

From: PEABO (5651)
Subject: RE: ACCESSING "USED INTERNALLY" (Re: Msg 5648)
Date: 7-FEB-02:25: Programming
 
Scott,
It's a dilemma whether to program for simplicity at the moment (few
instructions and easy to understand code) or to program for permanence
(by adhering to strict interface standards).  I would contrast this to
the obvious clean solution of appending the filename to the volume
name with a colon intervening.  A very straightforward method of
storing a reference to a file which, unfortunately, falls to pieces
when you run your program under HFS. Apple anticipated that problem by
telling people not to do it, yet look at the numerous glitches in
programs written by people with the best of intentions. An well-known
curse is stated "May you live in interesting times".  The computer
analog of that might be "May you specialize in designing interfaces"!
 
peter

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

From: DSACHS (5640)
Subject: Mac + questions
Date: 6-FEB-22:52: Hardware & Peripherals
 
I am thinking of upgrading my macintosh, and I would like to know if
anyone has information on the following subjects. 1.  What software,
if any, will not work properly with a Mac + (On MFS volumes - HFS
incompatability is being discussed) for such reasons as dependency on
the old ROMS, dependency on the memory size, and copy protection not
working with the new double sided disk. 2.  There is a rumor going
around that some single sided disks have an uncoated top surface (The
unused surface for single side usage) that may cause physical damage
to the top head of a double-sided drive.

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

End of Delphi Digest
********************