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

shulman@topaz.RUTGERS.EDU (Jeff Shulman) (10/31/85)

Delphi Digest          Wednesday, 30 Oct 1985      Volume 1 : Issue 2

Today's Topics:
     FOBJ Resources
     Dialog in C
     LARGE arrays in C
     horizontal retrace interupt?
     RE: Usenet Digest Volume 1 Issue 2 (Re: Msg 2975)
     RMaker Fix
     Jazz "death" loop
     OMNIS 3
     Next ExperLisp release ?
----------------------------------------------------------------------

2920 26-OCT 02:18 Developer's Corner
     FOBJ Resources
     From: STANKRUTE    To: ALL
 
Has anyone figured out the total setup of the DeskTop file's FOBJ
resources ?  We've figured out enough so that we can create new
folders, put folders into other folders, remove folders from other
folders, move folders and their icons around on the desktop, but there
are other mysteries remaining.  How about it ?  Apple Tech Support is
very nice, but there's some strange policy of no information available
on this little goody.  Those policies, of course, raise the red flag
in front of any developer -- a CHALLENGE to the probing Macaholic
mind.
 
------------------------------

2930 26-OCT 14:48 Developer's Corner
     RE: FOBJ Resources (Re: Msg 2920)
     From: ASMCOR       To: STANKRUTE
 
You're ahead of me on this one.  Perhaps you'd like to share what you
do know with the members here, I'd sure like to see it.  Maybe a nice
little description uploaded to the database, or something!?  As for
the Macaholic, I know what you mean <grin>.  By the way, I have a
little DA I'm working on that set's the attributes of a file, just the
type and creator for now.  It works just fine, but the finder does not
update the desktop until an application is run.  Any ideas about how
to force an update?  Jan
 
------------------------------

2934 26-OCT 17:01 Developer's Corner
     RE: FOBJ Resources (Re: Msg 2925)
     From: STANKRUTE    To: PEABO
 
Hi, Peter --
 
Thanks for picking up the FOBJ gauntlet.  Here's what I've figured out
so far :
 
The Finder stores information about disks and folders in FOBJ
resources in the DeskTop file.  I assume that FOBJ stands for Finder
OBJect.
 
A disk's FOBJ gets a resource ID # of 0.  Folders get positive
integers for their FOBJ resource ID's.
 
The Finder uses FOBJs to build its windows.  FOBJs vary in size,
depending on how many objects - files and folders - are contained
therein.  Here's a semi-IM data description of a FOBJ record :
 
TYPE    FOBJThing = RECORD
(offset = 0)    fTMysteryWord0 :        INTEGER ;
(offset = 2)    fTIconLocation :        Point ;
(offset = 6)    fTMysteryWord1 :        INTEGER ;
(offset = 8)    fTMysteryWord2 :        INTEGER ;
(offset = 10)   fTMysteryWord3 :        INTEGER ;
(offset = 12)   fTParentFOBJResID :     INTEGER ;
(offset = 14)   fTMysteryLong0 :        LongWord ;
(offset = 18)   fTMysteryWord4 :        INTEGER ;
(offset = 20)   fTMysteryWord5 :        INTEGER ;
(offset = 22)   fTMysteryWord6 :        INTEGER ;
(offset = 24)   fTMysteryWord7 :        INTEGER ;
(offset = 26)   fTMysteryWord8 :        INTEGER ;
(offset = 28)   fTMysteryWord9 :        INTEGER ;
(offset = 30)   fTMysteryWord10 :       INTEGER ;
(offset = 32)   fTMysteryWord11 :       INTEGER ;
(offset = 34)   fTMysteryWord12 :       INTEGER ;
(offset = 36)   fTMysteryWord13 :       INTEGER ;
(offset = 38)   fTMysteryWord14 :       INTEGER ;
(offset = 40)   fTMysteryWord15 :       INTEGER ;
(offset = 42)   fTMysteryWord16 :       INTEGER ;
(offset = 44)   fTWindowRect :  Rect ;
(offset = 52)   fTHorzScroller :                INTEGER ;
(offset = 54)   fTVertScroller :                INTEGER ;
(offset = 56)   fTNumberOfObjects :     INTEGER ;
(offset = 58)   fTObjectList :       a buncha fTObjects ;
END ;
TYPE    fTObject = RECORD
(offset=0)      mysteryByte0 :          byte ;
(offset=1)      mysteryByte1 :          byte ;
(offset=2)      mysteryByte2 :          byte ;
(offset=3)      mysteryByte3 :          byte
END ;

Lotsa mystery, eh ?  Must be the time of year.  It amazes me that,
with what little I've cracked, I can do most of what I want to do with
folders : create 'em, move 'em in and out of one another, get rid of
'em.  Here's some detail on each of the fields referenced above :
 
fTMysteryWord0 :
In the cases I've seen, it stays set to $0008.
fTIconLocation :
Location of this FOBJ's icon.  If the FOBJ is a folder,
it's the folder's icon's location in its parent FOBJ's
window.  Well, not exactly -- it's the location in a
rectangle that's inset a tad into that parent window.
Now we see why icons don't like to get too near their
window's edge.  If the FOBJ is a disk, it's the disk's
icon's position on the desktop.  Corresponds to the
fdLocation field of an FInfo record ( see P. 11 of the
File Manager section of IM ).
 
fTMysteryWord1 :
No clues yet.
fTMysteryWord2 :
No clues yet.
fTMysteryWord3 :
Bit 7 gets set when the FOBJ's window is open.
fTParentFOBJResID :
Who this FOBJ belongs to, and thus where its icon
(if visible) will appear.  Corresponds to the
fdFldr field of an FInfo record ( see P. 11 of the
File Manager section of IM ).  A value of 0 indicates
the FOBJ's icon's in the disk window, -2 ($FFFE)
indicates the desktop, -3 ($FFFD) indicates the
trash can, positive values indicate a folder ( the
positive value is then the parent folder's FOBJ
resource ID #).
 
fTMysteryLong0 :
The high three bytes of this little gem show up
intact (or nearly so) in the first three bytes of
an fTObject record (see below).
fTMysteryWord4 :
No clues yet.
fTMysteryWord5 :
No clues yet.
fTMysteryWord6 :
No clues yet.
fTMysteryWord7 :
No clues yet.
fTMysteryWord8 :
No clues yet.
fTMysteryWord9 :
No clues yet.
fTMysteryWord10 :
No clues yet.
fTMysteryWord11 :
No clues yet.
fTMysteryWord12 :
No clues yet.
fTMysteryWord13 :
No clues yet.
fTMysteryWord14 :
No clues yet.
fTMysteryWord15 :
No clues yet.
fTMysteryWord16 :
No clues yet.
fTWindowRect :
No clues yet.
fTHorzScroller :
Affects position and state of the FOBJ's window's
horizontal scroller.  Control values are usually integers,
but I have suspicions this may be two byte-size
scroller-related values.
fTVertScroller :
Same as fTHorzScroller above, but for the vertical
scroller.
 
fTNumberOfObjects :
How many objects - files and folders - are contained
in this FOBJ's window.  If a contained folder holds other
files and/or folders, it still counts as just one contained
object.
 
fTObjectList :
Four-byte data chunklets for the objects numbered in
the previous field.  The first 3 bytes of the data seem
to be lifted from the high 3 bytes of the
fTMysteryLong0 field, but sometimes they vary by a bit
or two.  The fourth byte takes on multiples of 4, but the
pattern is not at all clear. I haven't yet found any
relationship to file numbers or folder resource id's.
Perhaps these are indexes to some kind of list of
file/folder identifiers ?  It seems that a folder would
want to directly access its contained objects, without
having to search all the FInfo fields of a directory.
 
mysteryByte0 :
Nothing yet -- see fTObjectList above.
 
mysteryByte1 :
Nothing yet -- see fTObjectList above.
 
mysteryByte2 :
Nothing yet -- see fTObjectList above.
 
mysteryByte3 :
Nothing yet -- see fTObjectList above.
 
 
So much for field discoveries.  I've watched many of the mystery
fields change, but they seem to do so inconsistently.  Ignoring them
doesn't seem to effect the folder operations I mention below.  If you
or anyone discovers any more, it would be nice to use these field
names.  Unless someone in the know wants to volunteer the REAL names.
 
Now, how do I use what little I've discovered ?  Well, howzabout
creating a new folder from an application.  I just create a new FOBJ
resource that contains the following 58 bytes of hex data :
 
00 08 00 40     00 40 00 00
00 83 01 00     00 00 00 00
EC 06 00 46     00 00 00 00
00 00 99 E5     94 9F 99 E5
94 9F FF FE     00 5C 00 00
00 00 00 00     00 30 00 20
01 00 01 A0     FF F4 FF F4
00 00

Give the resource a name; that'll be the folder's name.  And give it
an unused positive resource id number.  Stick the resulting FOBJ in a
disk's DeskTop file.  This'll create a well- behaved empty folder in
the disk's window.
 
Customization of your new folder ?  Well, change the fTIconLocation
field to move the folder's icon around.  Change the fTWindowRect field
to change the folder's window's dimensions.  Change the
fTParentFOBJResID field to another folder's resource ID number to put
the new folder inside that other folder.
 
To take a folder out of a folder, just change the fTParentFOBJResID
field to the grandparent FOBJ's resource id number (if there is such a
scion), or clear it to 0 to get the folder out into the disk's window.
 
To remove a folder, just make sure there's nothing in it, then remove
its FOBJ resource from the Desktop file.  The trick here is
ascertaining the folder's contents.  At this point, I have to keep
track of every folder's parent FOBJ, and every file's folder.  Then I
move all folders out, and all files.  Folder moving is mentioned in
the previous paragraph, and file moving is pretty straight-forward --
again, see page 11 of the File Manager part of IM.  But my method of
ascertaining folder contents is rather inelegant.  If we can crack the
format of the fTObjectList entries, a neater approach may surface. The
Finder wouldn't kloodge, now would it ?!?!?
 
So, Peter, and all interested viewers, there you have it.  Everything
I've discovered so far about FOBJs.  Any appetites whetted for more
???  Tools for digging ?  I did my exploring on a 512K machine with
the following Switcher setup : ResEd 0.8 at 172K, FEdit 3.05 at 172K,
Finder 4.1 at 128K, all with no saved screens.  Go to it. Remember,
you're down in the bowels of this wondrous piece of sandy plastic, so
be careful.  Do it to it before it does it to you.
 
I look forward to future developments -- Stan
 
------------------------------

2945 27-OCT 01:13 Developer's Corner
     RE: FOBJ Resources (Re: Msg 2934)
     From: PEABO        To: STANKRUTE
 
Stan,
I didn't see anything there about locked folders or changing the "View
as" menu option ... that stuff sticks with folders when the disk is
dismounted, so it must be in there somewhere.  peter
 
------------------------------

2965 28-OCT 19:11 Developer's Corner
     RE: FOBJ Resources (Re: Msg 2945)
     From: MCOHEN       To: PEABO
 
I assume one of the 'mystery words' in the file entries referred to
above is the file number (used to GetFileInfo by a file index) rather
than anything too mysterious. I assume the rest of it is the location
of the file withing that window. I haven't actually looked at a FOBJ
to confirm this, though.  - Mike
 
------------------------------

2931 26-OCT 15:32 Programming
     Dialog in C
     From: ASMCOR       To: JEFFS
 
Jeff, this is for jss@sjuvax.UUCP (J. Shapiro) in response to the
question about putting up a dialog box in C.  This is the Megamax C
code.
 
 
main()
{
DialogRecord    drec;
DialogPtr       dptr;
int                             itemhit;
 
    InitGraf(&thePort);
    InitFonts();
    InitWindows();
    InitDialogs(NULL);
    InitCursor();
        dptr = GetNewDialog(200,&drec,-1L);
        while(itemhit != 1)
                ModalDialog(NULL,&itemhit);
        CloseDialog(dptr);
}
 
* End of C program...the rest of this is the RMaker file *
 
!Test DLOG
 
 
Type DITL
 
 ,200
2
*   1
BtnItem Enabled
168 314 188 374
OK
 
*   2
StatText Enabled
65 109 85 292
This is a test dialog box.
 
 
Type DLOG
 
  ,200
Test Dialog
66 56 270 448
Visible NoGoAway
0
0
200
 
------------------------------

2957 27-OCT 20:35 Programming
     LARGE arrays in C
     From: FH           To: ALL
 
I just got Megamax C, and I noticed that they don't allow arrays
larger than 32K.  I need at least 128K for an array, or 4 32K arrays.
Is there a simple way to get around the Mac's $#!+ memory manager?
thanks Frank
 
------------------------------

2959 27-OCT 23:15 Programming
     RE: LARGE arrays in C (Re: Msg 2957)
     From: ASMCOR       To: FH
 
Well, what I would do is use NewPtr to set up the block of memory, and
then just use pointers instead of trying to use an array per se.  If
you grab the memory right off, you shouldn't have much trouble with
fragmented heaps, either.  Jan
 
------------------------------

2961 28-OCT 00:55 Programming
     RE: LARGE arrays in C (Re: Msg 2957)
     From: PEABO        To: FH
 
Frank,
It is not the Mac memory manager which is the limitation ...
NewHandle() takes a long argument, and is very happy to assign huge
chunks of memory.
 
You could use a pointer instead of an array and bypass the Megamax
memory allocation routine.  It is possible to lock a large block in
memory so you can avoid the double indirection of a Handle, and use a
dereferenced Handle as a pointer safely, but you need to be a little
careful if you are running on a 128K machine or in a small Switcher
partition.
 
peter
 
------------------------------

2967 28-OCT 19:29 Programming
     horizontal retrace interupt?
     From: JIMH         To: ALL
 
Does anyone know if there is a horizontal retrace interupt in the mac
system?  the resreason for this somewhat strange request is that at
the top of the screen you have only a couple of milliseconds to update
the screen during vertical blanking.  it would be somewhat better when
using single screen animation to be able to start redrawing a part of
the screen right after the retrace has passed it by.  thus you would
have the entire 16.+ millisecond to update.  I did this on my old
Commodore 64 to make the 8 sprites look like many more. the SS
hardware doc. shows at flag that is set during horizontal blanking, so
i am looking for a way to tell what raster line is currently being
drawn.  any help wo uld be appreciated.  - jim hopper
 
------------------------------
 
     RE: Usenet Digest Volume 1 Issue 2 (Re: Msg 2975)
     From: ASMCOR       To: JEFFS (NR)
 
Reply to the RMaker problem...
Mark,
Yep, I had that same problem.  Finally gave up on it and used ResEdit to patch
the darn thing.
Jan
 
------------------------------

2982 30-OCT 06:59 Programming
     RMaker Fix
     From: LOFTUSBECKER To: ALL
 
Here is a copy of the patch to the Apple Resource Compiler (from MDS)
that fixes the bug of not accepting \0x for specifying a char, where x
was A-F.
 
(Courtesy Andy Hertzfeld, Resource Compilers Author)
 
Find:           0C41 0011 .Substitute:    0C41 0016
 
------------------------------
 
2977 29-OCT 19:08 Business Mac
     Jazz "death" loop
     From: PIZZAMAN     To: ALL
 
Today, was working with the Jazz database, and found out, after an
hour, that my data disk was locked! Shouldn't have been a major
problem, except that the program went into a "death" loop. Asked if I
wanted to save the data, but when "yes" was clicked, got an error
message. The o.k. got me back to the "do you want to save" message.
Tried ejecting the disk with paper clip, taking off the lock, and
re-inserting, but no luck. Lost an hours data entry. Seems like a
serious flaw for us dummies who like to keep our disks locked while we
are just playing with them or copying them for backup. Anyone else
have this problem with Jazz, or no how I could have gotten out of the
"death" loop? Barry
 
------------------------------

2978 29-OCT 23:02 Business Mac
     OMNIS 3
     From: RSS          To: ANYONE (NR)
 
Has anyone out there had any experience with Omnis 3?  I would like to
know how bulleproof it is, whether the multiuser version enables
record-locking or only file-locking, and whether it is THE BEST
database for vertical applications developme nt.  Any comments or
opinions would be welcomed. - RSS
 
------------------------------

2983 30-OCT 18:19 Programming
     prog
     From: KENWINOGRAD  To: ALL
 
Does anyone know exactly how the text input to a GetInfo dialog is
stored ? I have already discovered that when you type some info into a
GetInfo box, the actual text itself is stored as a standard
pascal-type string (first byte is count byte) in a FCMT resource in
the desktop file.  I have also discovered that the ID of this resource
changes when you change the name of the file.  So, it would appear
that the ID given is some sort of a code based on the file name ?
Anyone have an idea on the code used ?

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

2942 26-OCT 20:33 Tools for Development
     Next ExperLisp release ?
     From: ROWLAND      To: ALL
 
Does anyone know when the version 2 release of Experlisp is coming
out? I have used the older one and am now about to do some things that
I suspect would be a whole lot easier with the expected features of
the new version.
 
Mike
 
------------------------------

2963 28-OCT 01:04 Tools for Development
     RE: Next ExperLisp release ? (Re: Msg 2942)
     From: MOUSEKETEER  To: ROWLAND
 
Talked to the Experlisp folks this past week, and they promised that
the new 1.4 was going out by the end of same.  The version to allow
stand-alone applications, though, won't be finished until Jan-Feb.,
they say, and will be the "price of a new manual" to upgrade, which
probably translates into late March (smile).
 
------------------------------

2968 28-OCT 20:32 Tools for Development
     RE: Next ExperLisp release ? (Re: Msg 2963)
     From: ROWLAND      To: MOUSEKETEER
 
Sigh. I got V1.4 a week or so ago - the editor enhancements (mostly
flashing paren matching is very nice. Seems to be a little less
fragile, but I've gotten skittish about trying anything too far out. I
guess I might as well plunge in and try doing things myself. (See I
missed a closing paren !) Thanks for the info.
 
Mike

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

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

							Jeff

uucp:   ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!shulman
arpa:   SHULMAN@RUTGERS
CIS:    76136,667
Delphi: JEFFS

tim@k.cs.cmu.edu (Tim Maroney) (11/03/85)

Jeff, I appreciate your work in posting these digests.  However, could you
adhere more closely to the informal standard for ARPA digests, that is, a
line beginning with 'From:' (NO initial white space) at the start of each
article?  That would make it much easier on those of us who prefer using the
"d" (digest) command of readnews to read digests.  Thanks!
-=-
Tim Maroney, CMU Center for Art and Technology
Tim.Maroney@k.cs.cmu.edu	uucp: {seismo,decwrl,etc.}!k.cs.cmu.edu!tim
CompuServe:	74176,1360	I am my own hunchbacked assistant.

shulman@topaz.RUTGERS.EDU (Jeff Shulman) (11/04/85)

I realize that those digests don't currently adhere to the Arpa standards.
The reasons are twofold: 1) The header you see is exactly as it is on Delphi
and I would have to manually change each message and 2) I am currently
producing these by *hand*.  I am waiting for digestification software but the
author of said software has been too busy to handle my requests.

I suppose that while I'm doing them by hand I could put the "From:"
field in but when (and if) it becomes an automated process I may not
be able to (or I may *have* to for the software to work.)

I also would not mind a "mod.micro.mac.delphi" (or some such name) group
but I am hesitant to ask for one given the current state of affairs.

							Jeff

uucp:   ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!shulman
arpa:   SHULMAN@RUTGERS
CIS:    76136,667
Delphi: JEFFS