Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-075

Internet Message Format | 1995-06-07 | 73.9 KB | [TEXT/R*ch]

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-075
Date: Mon, 12 Dec 1994 16:16:53 +0100 (MET)

C.S.M.P. Digest             Mon, 12 Dec 94       Volume 3 : Issue 75

Today's Topics:

        AppleScript FTP-site?
        C++ and handles
        Finding out whether text is selected in a dialog
        How to get default 'aeut' resource?
        MacsBug - what is it and why?
        how to get PB in PPC completion routine?
        oops..

The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

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.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

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
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks 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 digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


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

>From [e-mail] (Anton Futselaar)
Subject: AppleScript FTP-site?
Date: Mon, 21 Nov 1994 22:43:42 GMT
Organization: Dieren / The Netherlands

Hi,

Is there somewhere out there an FTP-site for AppleScript.

Thanks, Anton.

+++++++++++++++++++++++++++

>From [e-mail] (Dana Cartwright 3rd)
Date: 22 Nov 1994 02:36:16 GMT
Organization: Syracuse University, Syracuse NY, USA

Anton Futselaar ([e-mail]) wrote:
: Is there somewhere out there an FTP-site for AppleScript.

gaea.kgs.ukans.edu


+++++++++++++++++++++++++++

>From [e-mail] ()
Date: Wed, 23 Nov 1994 17:02:14 GMT
Organization: Chemical Abstracts Service, Columbus, Ohio

In article <[e-mail]> [e-mail] (Anton Futselaar) writes:
>Hi,
>
>Is there somewhere out there an FTP-site for AppleScript.
>
>Thanks, Anton.

Try ftp://gaea.kgs.ukans.edu/applescript

Dan Kelsey
([e-mail])

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

>From Richard Kennaway <[e-mail]>
Subject: C++ and handles
Date: 3 Nov 1994 13:52:44 GMT
Organization: SYS, University of East Anglia

I recently ported a C program to C++, which wasn't too difficult, but
when I tried to convert some of the data structures to classes, I ran
into a problem which seems so simple, everyone using C++ on a Mac must
have encountered it.  However, I don't see any nice solution.

How do I use a relocatable block for storing a class object?  Suppose I
define a class xclass containing a member function foo(), and declare an
object x of type **xclass, initialised by a call of NewHandle(
sizeof(xclass) ).  I can't safely call (*x)->foo(), since the implicit
"this" argument to foo() is a dereferenced handle.  If foo() is capable
of allocating memory, then x may get relocated, invalidating the value of
"this".

Possible workarounds:

(1) Don't use relocatable memory to allocate class objects.  (Leads to
memory fragmentation.)

(2) Lock handles before calling member functions and restore their state
afterwards.  (Error-prone and tedious.)

(3) Have each member function first locate the parent handle of "this"
and then either lock it, or always use the handle to access components.
(Memory fragmentation, error-prone, tedious, and how expensive is a call
to RecoverHandle()?)

(4) Abandon C++ on the Mac.

Any other ideas?  I'm using CodeWarrior, but the manual doesn't mention
this problem.

___
\X/ Richard Kennaway, [e-mail], Univ. of East Anglia, Norwich

+++++++++++++++++++++++++++

>From [e-mail] (Arnaud MASSON)
Date: 3 Nov 1994 18:27:22 GMT
Organization: Ensem, Nancy, France

In article <39apvc$[e-mail]>, Richard Kennaway <[e-mail]> writes:
|> I recently ported a C program to C++, which wasn't too difficult, but
|> when I tried to convert some of the data structures to classes, I ran
|> into a problem which seems so simple, everyone using C++ on a Mac must
|> have encountered it.  However, I don't see any nice solution.
|>
|> How do I use a relocatable block for storing a class object?  Suppose I
|> define a class xclass containing a member function foo(), and declare an
|> object x of type **xclass, initialised by a call of NewHandle(
|> sizeof(xclass) ).  I can't safely call (*x)->foo(), since the implicit
|> "this" argument to foo() is a dereferenced handle.  If foo() is capable
|> of allocating memory, then x may get relocated, invalidating the value of
|> "this".
|>
|> Possible workarounds:
|>
|> (1) Don't use relocatable memory to allocate class objects.  (Leads to
|> memory fragmentation.)
|>
|> (2) Lock handles before calling member functions and restore their state
|> afterwards.  (Error-prone and tedious.)
|>
|> (3) Have each member function first locate the parent handle of "this"
|> and then either lock it, or always use the handle to access components.
|> (Memory fragmentation, error-prone, tedious, and how expensive is a call
|> to RecoverHandle()?)
|>
|> (4) Abandon C++ on the Mac.
|>
|> Any other ideas?  I'm using CodeWarrior, but the manual doesn't mention
|> this problem.
|>
|> ___
|> \X/ Richard Kennaway, [e-mail], Univ. of East Anglia, Norwich


Hello, this is my first experience of answering something on the Internet!

About the C++ and handles, I would say that handles are an old system of memory
managment. Now there is virtual memory (and many more RAM of course) than in 1984,
so handles are not needed anymore for small blocks like usual objects of user interface.
On powerPC, it seems that the segment loader (= handles of code)
is not really necessary anymore(I'm not sure, new Inside Mac cost too much).
I think also that multiple inheritance require pointers since it's impossible to have
handle to something inside handle, if you see what I mean.

So, there is today no reason to have C++ objects as handles.

PS: sorry for my bad English. Please, could someone answer me by email ?
I'm student and I would like to know who is on the Internet.

+++++++++++++++++++++++++++

>From Nathaniel P Woods <[e-mail]>
Date: Thu,  3 Nov 1994 14:48:03 -0500
Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA

It is impossible to have a C++ object class as a handle.  Highly
developped classes may create a whole slew of pointers to themselves and
the bitwise copies that the Memory Manager uses would tear C++ objects
to shreds.

Nathaniel

+++++++++++++++++++++++++++

>From [e-mail] (Howard Berkey)
Date: 3 Nov 1994 20:42:04 GMT
Organization: Weyland-Yutani thinking machines division

In article <[e-mail]>,
Nathaniel P Woods  <[e-mail]> wrote:
>It is impossible to have a C++ object class as a handle.  Highly
>developped classes may create a whole slew of pointers to themselves and
>the bitwise copies that the Memory Manager uses would tear C++ objects
>to shreds.
>
>Nathaniel


Really?  You are sure about this?  :-)

-H-

(note that I'm NOT arguing in favor of handle based objects)


+++++++++++++++++++++++++++

>From [e-mail] (Brett Powley)
Date: 4 Nov 1994 14:37:47 +1100
Organization: Telecom Australia - CSSC

Nathaniel P Woods <[e-mail]> writes:

>It is impossible to have a C++ object class as a handle.  Highly
>developped classes may create a whole slew of pointers to themselves and
>the bitwise copies that the Memory Manager uses would tear C++ objects
>to shreds.

I'm not sure what this somewhat confused ramble follows on from but...

C++ allows you to use any allocation mechanism you like, by overriding the
new operator.  You may notice that THINK C with object extensions has
"indirect" classes (i.e. handle-based) while Symantec C++ allows a
__machdl attribute on a class to specify that it is to be handle- rather
than pointer- based.  I haven't found any equivalent mechanism built
into CodeWarrior (yet).

Brett Powley
[e-mail]
Process Software
Wollongong, Australia








+++++++++++++++++++++++++++

>From Nathaniel P Woods <[e-mail]>
Date: Fri,  4 Nov 1994 08:57:39 -0500
Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA

>Really?  You are sure about this?  :-)

Well not all will do this.  But when you make objects loaded with
virtual inheritance, other complex classes inside of it, you will see
that effect.  That is why you should override operator = to do an assign
for your class when you do stuff that would cause a bitwise copy to
invalidate your class.

Nathaniel

+++++++++++++++++++++++++++

>From Nathaniel P Woods <[e-mail]>
Date: Fri,  4 Nov 1994 09:00:33 -0500
Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA

>C++ allows you to use any allocation mechanism you like, by overriding the
>new operator.

Thats true, but lets say one of your member classes puts a pointer to
itself somewhere else.  If the class was derived from some type of
handle, there would be no way to update that other pointer.

Im not saying it isnt possible to have Handle classes, but when you get
heavy into C++ they will become unusable.

Nathaniel

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Fri, 4 Nov 1994 17:08:25 GMT
Organization: Process Control Center

In article <39ba2a$[e-mail]>, [e-mail]
(Arnaud MASSON) wrote (regarding classes as handles):

> About the C++ and handles, I would say that handles are an old system of
memory
> managment. Now there is virtual memory (and many more RAM of course)
than in 1984,
> so handles are not needed anymore for small blocks like usual objects of
user interface.
> On powerPC, it seems that the segment loader (= handles of code)
> is not really necessary anymore(I'm not sure, new Inside Mac cost too much).
> I think also that multiple inheritance require pointers since it's
impossible to have
> handle to something inside handle, if you see what I mean.
>
> So, there is today no reason to have C++ objects as handles.

As has been discussed extensively in c.s.m.p, handles still have a place
within the Macintosh memory model, despite the relative inexpense of
memory nowadays. However, C++ objects is not one of them.

Arnaud is correct in stating that multiple inheritance is incompatible
with handle-based C++ objects. This has been documented in _develop_ (and,
presumably other places). If you have a class that inherits from
superclasses A and B,
the object will look something like this on the heap:

    +-------------------+
    | Data members      |
    | inherited from    |
    | Class A           |
    +-------------------+
    | Data members      |
    | inherited from    |
    | Class B           |
    +-------------------+
    | more members      |
    +-------------------+

If you need to execute a method inherited from B, the compiler passes a
pointer to where the data members from class B are. With pointer-based
classes, this is just an offset. If you have any experience with handles,
you know that you can't just calculate an offset and pass it to any old
function... memory may get moved somewhere along the line, the pointer is
no longer valid, and general bad kharma.

You will notice that both Smalltalk and THINK C with objects used handles
and implement single-inheritance only . This is no coincidence. Since
Richard is using CW, reverting to THINK C w/objects is not an option.

(Footnote: I'm only 90% sure about Smalltalk & handles. With THINK I know)

The short answer is to use pointers with C++. Your library classes will
use standard handle-based data structures for accessing the Toolbox. If
your class library's hot, it will have lots of tweaks to minimize heap
fragmentation when using objects (I don't think any of the available class
libraries is particularly hot :-\ )


> PS: sorry for my bad English. Please, could someone answer me by email ?
> I'm student and I would like to know who is on the Internet.

Arnaud--hey, your English is better than my French. And, I've seen native
speakers use worse English on the net.

--
Peter Castine               | Useful approximations:
[e-mail]   |  Pi seconds is a nanocentury.
Process Control Center      |  Electricity travels a foot per nanosecond.
Technical University Berlin |  One ostrich egg will feed 24 people for brunch.

+++++++++++++++++++++++++++

>From [e-mail] (Richard Bartel)
Date: 5 Nov 1994 08:21:09 GMT
Organization: NeoSoft Internet Services   [phone]

Nathaniel P Woods ([e-mail]) wrote:
: >C++ allows you to use any allocation mechanism you like, by overriding the
: >new operator.

: Thats true, but lets say one of your member classes puts a pointer to
: itself somewhere else.  If the class was derived from some type of
: handle, there would be no way to update that other pointer.

: Im not saying it isnt possible to have Handle classes, but when you get
: heavy into C++ they will become unusable.

: Nathaniel

I'm new to C++ but I have programmed extensively in Consular 68000
assembler.  So please excuse me for discussing C++ objects as purely data
structures and for any ignorance of C++ specifics.

If a data structure is created via NewHandle (i.e. is a relocatable
block), then it is unadvisable to store "a pointer to itself" except as a
temporary variable while the handle is locked via HLock.  A Mac handle is
not a pointer to a pointer but is a pointer to a "master pointer".  If a
relocatable block relocates, the master pointer is updated to point to the
block's new address.  Therefore, if you need to maintain self-reference
within a relocatable block, then you must store a copy of its handle.

There may be further restrictions that C++ may require that render handles
and relocatable blocks "unusable" as data structures for objects.  I don't
know of any restrictions but then again I am not qualified to comment on
that. If they are unusable, then I am disappointed.  While pointers are
generally preferred over handles (due to speed and simplicity), there are
times when it is nice to have the ability to increase the size of an
object or to allow the object to move so another block may grow.  And
while machines today typically have more RAM than earlier Macs, there's
never too much RAM and virtual memory is not without its costs.  Also, new
apps are getting bigger and lots of older Macs are still out there and
still being used.

As an example, we had to bump up my 8100/80 from 24 to 40Mb of RAM because
Illustrator ran out of memory on some of the larger GIS documents we are
producing, and even still the limitation has not been eliminated.

R.L. Bartel


+++++++++++++++++++++++++++

>From Nathaniel P Woods <[e-mail]>
Date: Sat,  5 Nov 1994 09:58:28 -0500
Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA

>I'm new to C++ but I have programmed extensively in Consular 68000
>assembler.  So please excuse me for discussing C++ objects as purely data
>structures and for any ignorance of C++ specifics.

No prob

>If a data structure is created via NewHandle (i.e. is a relocatable
>block), then it is unadvisable to store "a pointer to itself" except as a
>temporary variable while the handle is locked via HLock.  A Mac handle is
>not a pointer to a pointer but is a pointer to a "master pointer".  If a
>relocatable block relocates, the master pointer is updated to point to the
>block's new address.  Therefore, if you need to maintain self-reference
>within a relocatable block, then you must store a copy of its handle.

Thats exactly the point Ive been making - why C++ classes cant work with
handles.  Classes often have member classes.  With a pointer, these can
be stored as offsets from the beginning of the block, but this wont work
with Handles because as soon as the object gets relocated these other
pointers become invalid.

This is not to say that Handles are not possible with C++.  One can
still reference data with Handles the way one could always, just that
you cant just make C++ classes based from Handles

Nathaniel


+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 5 Nov 1994 16:59:20 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <39apvc$[e-mail]>, Richard Kennaway
<[e-mail]> wrote:

< I recently ported a C program to C++, which wasn't too difficult, but
< when I tried to convert some of the data structures to classes, I ran
< into a problem which seems so simple, everyone using C++ on a Mac must
< have encountered it.  However, I don't see any nice solution.
<
< How do I use a relocatable block for storing a class object?  Suppose I
< define a class xclass containing a member function foo(), and declare an
< object x of type **xclass, initialised by a call of NewHandle(
< sizeof(xclass) ).  I can't safely call (*x)->foo(), since the implicit
< "this" argument to foo() is a dereferenced handle.  If foo() is capable
< of allocating memory, then x may get relocated, invalidating the value of
< "this".
<
< Possible workarounds:
<
< (1) Don't use relocatable memory to allocate class objects.  (Leads to
< memory fragmentation.)
<
< (2) Lock handles before calling member functions and restore their state
< afterwards.  (Error-prone and tedious.)
<
< (3) Have each member function first locate the parent handle of "this"
< and then either lock it, or always use the handle to access components.
< (Memory fragmentation, error-prone, tedious, and how expensive is a call
< to RecoverHandle()?)
<
< (4) Abandon C++ on the Mac.
<
< Any other ideas?  I'm using CodeWarrior, but the manual doesn't mention
< this problem.
<
< ___
< \X/ Richard Kennaway, [e-mail], Univ. of East Anglia, Norwich

If you're using CodeWarrior then your classes are pointers, not handles.
If you have data structures that are handles, they should become data
members of your new classes.  You create your classes in the usual way by
calling operator new.  In the constructor you call NewHandle() to allocate
the data member.  You access the data member as you would any handle from
the methods of the class.  Something like this:

class foo {
   foo::foo() { itsData = NewHandle( kASize); }
   foo::~foo() { if (itsData) DisposeHandle( itsData ); }
   Handle   itsData;
};

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jeremy Ford Bennett)
Date: 4 Nov 1994 20:21:02 GMT
Organization: University of Michigan

In article <39caab$[e-mail]>,
Brett Powley <[e-mail]> wrote:
>Nathaniel P Woods <[e-mail]> writes:
>
[snip]
>
>I'm not sure what this somewhat confused ramble follows on from but...
>
>C++ allows you to use any allocation mechanism you like, by overriding the
>new operator.  You may notice that THINK C with object extensions has
>"indirect" classes (i.e. handle-based) while Symantec C++ allows a
>__machdl attribute on a class to specify that it is to be handle- rather
>than pointer- based.  I haven't found any equivalent mechanism built
>into CodeWarrior (yet).
>
>Brett Powley
>[e-mail]
>Process Software
>Wollongong, Australia

Would you mind going into more detail on the _machdl attribute? I'm currently
working on a small project where I will have an array of class objects
in SC++ that will end up in a global structure that is a handle.
I'm writing a small AfterDark module for a class so the handle is not my idea.
Any info provided would be appreciated.

Jeremy

--
[e-mail]
Student of Computer Science, University of Michigan
For PGP key finger [e-mail]
In the end, there can be only one.

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Mon, 7 Nov 1994 21:02:56 GMT
Organization: Apple Computer

Nathaniel P Woods, [e-mail] writes:
> It is impossible to have a C++ object class as a handle.  Highly
> developped classes may create a whole slew of pointers to themselves and
> the bitwise copies that the Memory Manager uses would tear C++ objects
> to shreds.

Nope. You can have objects in handles, as long as the compiler knows they are
in handles -- both cfront and Symantec C++ have extensions to the language
that do this. There is of course additional overhead for all the
double-dereferencing, and you have to be careful to lock the handle when
necessary.

What _is_ impossible is to use multiple inheritance with handle-based
objects, because MI requires multiple objects inside an object, and you can't
put a relocatable block inside another relocatable block.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 8 Nov 1994 20:57:24 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <39ff9l$[e-mail]>, [e-mail]
(Richard Bartel) wrote:

< While pointers are
< generally preferred over handles (due to speed and simplicity), there are
< times when it is nice to have the ability to increase the size of an
< object or to allow the object to move so another block may grow.
< R.L. Bartel

You might resize a handle used as a data member, but resizing the actual
object is very unlikely.

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 9 Nov 1994 01:00:56 GMT
Organization: Apple Computer

Nathaniel P Woods, [e-mail] writes:
> Im not saying it isnt possible to have Handle classes, but when you get
> heavy into C++ they will become unusable.

This is untrue. Before you keep trying to insist on this, please read the
Symantec or MPW documentation about "HandleObject" or the "__machdl"
attribute. Both of these allow you to have full C++ objects in handles. The
only limitation is no multiple inheritance. Very large systems like MacApp
and MacApp-based applications have been built using this type of object.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From Nathaniel P Woods <[e-mail]>
Date: Wed,  9 Nov 1994 02:37:58 -0500
Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA

>This is untrue. Before you keep trying to insist on this, please read the
>Symantec or MPW documentation about "HandleObject" or the "__machdl"
>attribute. Both of these allow you to have full C++ objects in handles. The
>only limitation is no multiple inheritance. Very large systems like MacApp
>and MacApp-based applications have been built using this type of object.

Does MacApp use full C++ extensions in ways like PowerPlant does with
multiple inheritance, objects declared in the global scope or anything
else?  Or are handle-classes only possible with second-rate OOP
implementations that dont use constructors/destructors?  If they managed
to make a compiler that used handles with multiple inheritance etc it
would make the most awkward looking classes imaginable.

Nathaniel

+++++++++++++++++++++++++++

>From [e-mail] (Atman Jacob Binstock)
Date: 9 Nov 1994 12:34:56 -0500
Organization: Integrated Software Inc.

In article <[e-mail]>,
Jens Alfke  <[e-mail]> wrote:
>This is untrue. Before you keep trying to insist on this, please read the
>Symantec or MPW documentation about "HandleObject" or the "__machdl"
>attribute. Both of these allow you to have full C++ objects in handles. The
>only limitation is no multiple inheritance. Very large systems like MacApp

I don't have any experience with HandleObjects, so my comments will only
be about Symantec's __machdl classes.  I found __machdl classes to pose
significant problems.  First, there is no safe and simple way to use
access functions for a member M of a __machdl class E (i.e. return a
reference or pointer to a member).  You have several choices: return a normal
reference and hope the object doesn't move (fine for short term, bad for
extended references), or cook up a reference class template Href that
contains a __machdl pointer to E and an offset to M.  However, the second
solution is not recursive - it fails for M's access functions.  Which means M
needs to know whether it is IN a normal object or a __machdl object.  Which
means that it has to return an envelope object that can either be a normal
reference or an Href.  Sound like a pain?  If M is to return an Href, how
does it get the __machdl pointer to E that it needs?  Well, M will have to be
"parented" - aware of the particular object that it is contained in.  This is
a terrible bother for perhaps a simple class that sometimes won't even be
used inside a __machdl class, and this problem  occurs every time you
need to use a pointer or reference to a member of a __machdl object.

The solutions I outlined are doable if you really really want C++
objects in movable memory.  However, I found Symantec C++ 7.0.3's
__machdl's much too buggy to make a simple class work correctly.
Classes mixing __machdl's and templates would rarely compile, and those
that did would often had faulty code generated.  I would strongly
suggest avoiding __machdl classes, unless you have very simple classes
and you are very tight on memory.

--
Atman Binstock                                       Integrated Software Inc.
[e-mail]                                        speaking only for myself

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 09 Nov 1994 14:12:01 -0800
Organization: Novell, Inc., Walnut Creek/Macintosh Site

In article <[e-mail]>,
Jens Alfke <[e-mail]> wrote:

> ...please read the
> Symantec or MPW documentation about "HandleObject" or the "__machdl"
> attribute. Both of these allow you to have full C++ objects in handles. The
> only limitation is no multiple inheritance...

The only limitation is that you must remove the '=' key from your
keyboard... :-)

--
 The views expressed here do not necessarily reflect those of my employer.

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 10 Nov 1994 00:07:03 GMT
Organization: Apple Computer

Nathaniel P Woods, [e-mail] writes:
> Thats exactly the point Ive been making - why C++ classes cant work with
> handles.  Classes often have member classes.  With a pointer, these can
> be stored as offsets from the beginning of the block, but this wont work
> with Handles because as soon as the object gets relocated these other
> pointers become invalid.

I think you mean "member objects" -- instance variables of an object which
themselves are C++ objects. You can use these (and I have) with handle-based
objects, provided that the member object is not a handle (obvious, since you
can't put a handle inside a handle) and that pointers to the member object
are not kept around for a long time -- you can keep pointers to the member
object around as long as you are not calling any Toolbox routines or as long
as the owning handle object is locked down, but not longer than that.
Provided you obey those rules (which are very much like any other
handle-based Mac techniques) you can use handle-based C++ objects just fine.

You may want to say that this is bad programming practice -- I disagree with
you on that, but it's better than saying "it's impossible", which is flat out
wrong.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From Nathaniel P Woods <[e-mail]>
Date: Thu, 10 Nov 1994 08:12:43 -0500
Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA

>I think you mean "member objects" -- instance variables of an object which
>themselves are C++ objects. You can use these (and I have) with handle-based
>objects, provided that the member object is not a handle (obvious, since you
>can't put a handle inside a handle) and that pointers to the member object
>are not kept around for a long time -- you can keep pointers to the member
>object around as long as you are not calling any Toolbox routines or as long
>as the owning handle object is locked down, but not longer than that.
>Provided you obey those rules (which are very much like any other
>handle-based Mac techniques) you can use handle-based C++ objects just fine.

I do _not_ mean member objects.  I mean superclasses of objects.  Watch
this code:

class A {
public:
  short a;
  short z;
};

class B {
public:
  short b;
  short x;
};

class C : public A, public B {
public:
  short c;
};

C is now an object that contains five shorts, the offset values will be
something like this:

+0 a
+2 z
+4 b
+6 x
+8 c

There are two inherited classes, and none use handles.  You cant
reference the 'B' superclass with a handle because they are inside the
block of memory itself.

Nathaniel

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 10 Nov 1994 19:43:16 GMT
Organization: Apple Computer

Nathaniel P Woods, [e-mail] writes:
> Does MacApp use full C++ extensions in ways like PowerPlant does with
> multiple inheritance, objects declared in the global scope or anything
> else?  Or are handle-classes only possible with second-rate OOP
> implementations that dont use constructors/destructors?

MacApp doesn't use MI, which I keep pointing out is impossible with handle
based objects. Handle-based objects cannot also be used as global variables
since they don't live in the global data space.
However, I would not call these restrictions "second-rate OOP". HandleObjects
support the full C++ constructor/destructor notion. And I know several OOP
experts who consider MI to be too dangerous and complex to use.

As I said before, I am not arguing with you that HandleObjects are more
restricted than C++ objects. I'm just peeved that you keep saying it's
impossible to put objects in handles, when it is not only possible but common.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 10 Nov 1994 21:59:13 GMT
Organization: Apple Computer

Brian Stern, [e-mail] writes:
> You might resize a handle used as a data member, but resizing the actual
> object is very unlikely.

No, you can resize the object. I've used dynamic-array classes like:

class Stack :HandleObject {
public:
  void  Push( long );
  long Pop( );

private:
  long nItems;
  long item[];
};

The implementation of Push uses PtrAndHand to append the new item to the end
of the handle. It's just like regular use of handles to store dynamic data
types, except that the handle happens to be treated as an object by the
compiler.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From Nathaniel P Woods <[e-mail]>
Date: Thu, 10 Nov 1994 22:22:08 -0500
Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA

>MacApp doesn't use MI, which I keep pointing out is impossible with handle
>based objects. Handle-based objects cannot also be used as global variables
>since they don't live in the global data space.
>However, I would not call these restrictions "second-rate OOP". HandleObjects
>support the full C++ constructor/destructor notion. And I know several OOP
>experts who consider MI to be too dangerous and complex to use.

...which is exactly what I keep pointing out.  Second-rate is merely a
term that I am using for objects that are limited in their power.  MI is
not dangerous and complex to use, no more than your automobile is.  You
have to know how it works or else it becomes a killing machine.  Some of
C++'s greatest strengths is being able to have multiple inheritance
which increases the power of modularity.  C++'s main reason for its wide
acceptance is the fact it can be used on a function-based language,
OOP-based language or what have you.

>As I said before, I am not arguing with you that HandleObjects are more
>restricted than C++ objects. I'm just peeved that you keep saying it's
>impossible to put objects in handles, when it is not only possible but common.

I _never_ said it was impossible to put some types of C++ objects in
Handles, only the ones that lose all of the features that seperate C++
from OOP extensions like the one in THINK C.  Handles as objects are
less common everyday, because OOP implementations are being switched
over to full C++.

Nathaniel

+++++++++++++++++++++++++++

>From Nathaniel P Woods <[e-mail]>
Date: Fri, 11 Nov 1994 10:32:32 -0500
Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA

>class Stack :HandleObject {
>public:
>  void  Push( long );
>  long Pop( );
>
>private:
>  long nItems;
>  long item[];
>};

What this means is that you cannot define a subclass of this class.

+++++++++++++++++++++++++++

>From [e-mail] (Miguel Cruz)
Date: Sun, 13 Nov 1994 04:08:49 GMT
Organization: Unaffiliated

I sure wish more of this thread were still hanging around here. Anyway,
here's a dopey question:

I understand how to do C++ in a more normal memory environment, and I
understand how to do C on the Mac. What I don't understand is the way to
create C++ objects into memory I got as a handle from the Memory Manager
(without copying them there "by hand"). I'm sure it's obvious, but I can't
find any information about it on the CodeWarrior CD (or any particularly
germane code samples).

Any pointers to a code snippet or so to get me started?

Thanks,

miguel

+++++++++++++++++++++++++++

>From [e-mail] (Miguel Cruz)
Date: Sun, 13 Nov 1994 05:21:39 GMT
Organization: Unaffiliated

In article <[e-mail]>, Miguel Cruz <[e-mail]> wrote:
>understand how to do C on the Mac. What I don't understand is the way to
>create C++ objects into memory I got as a handle from the Memory Manager

Okay, I downloaded TECplusSample from ftp.apple.com and they used some
mysterious class HandleObject. I tried that and it appears to work just
fine. However, I'd really like to find the documentation of this. In
desperation, I searched my entire hard disk for the text 'HandleObject'
and it was nowhere (except in TECPlusSample).

Furthermore, in my mad haste to switch CDs, I dragged the Inside Mac CD-ROM
icon to the trash and when the Mac ejected it, the tray pushed a glass of
grape juice off my desk and into my lap. Let that be a lesson to
development tool vendors: all this would have been avoided with better
documentation.

miguel

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Sun, 13 Nov 1994 02:44:46 -0500
Organization: One Step Beyond

[e-mail] (Miguel Cruz) wrote:

) > understand how to do C on the Mac. What I don't understand is the
) > way to create C++ objects into memory I got as a handle from the
) > Memory Manager
)
) Okay, I downloaded TECplusSample from ftp.apple.com and they used some
) mysterious class HandleObject. I tried that and it appears to work just
) fine. However, I'd really like to find the documentation of this. In
) desperation, I searched my entire hard disk for the text 'HandleObject'
) and it was nowhere (except in TECPlusSample).

HandleObject was a hack used by Apple and Symantec to provide Handle
based objects in C++ (and the Think "object C") before multiple inheritance
became an issue in the C++ world.

"Real" C++ can't use handle based objects because of thorney issues with
vtables, invisible pointers used in multiple inheritance and other such
C++ compiler minutia.  Can someone who knows more about the theoretical
reasons behind this prohibition chime in with more detailed info.

Basically, forget about it.  One of the few benefits handle based objects
would provide is dynamically resizable objects, but since C++ objects can
be stack based, you can simply add a handle field to it and get the same
result and be safer to boot.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Sun, 13 Nov 1994 10:49:30 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail]
(Robert Mah) wrote:

> "Real" C++ can't use handle based objects because of thorney issues with
> vtables, invisible pointers used in multiple inheritance and other such
> C++ compiler minutia.  Can someone who knows more about the theoretical
> reasons behind this prohibition chime in with more detailed info.

Multiple inheritance causes requirements for pointers into the middle of
objects.  Pointers into the middle of [unlocked] handles are (for
practical purposes) impossible.  Hence no MI in HandleObject.

Apple went further:  since no MI, no need for the double-sized vtables
which were used in CFront-like C++ implementations to support MI.  So
HandleObject used the older vtables.  So did SingleObject.  And of course
PascalObject used Apple Object Pascal style method lookup (no vtables in
the CFront sense).

   [Verb tense is strange above:  Apple's CFront-based C++ is still
around, but they say phase out of using it.  So I used past tense.]

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   Sorry...clever signatures require cleverness, not found here.
   [e-mail]

+++++++++++++++++++++++++++

>From Richard Kennaway <[e-mail]>
Date: 14 Nov 1994 09:43:04 GMT
Organization: SYS, University of East Anglia

In article <[e-mail]> John W.
Baxter, [e-mail] writes:
> Multiple inheritance causes requirements for pointers into the middle of
> objects.  Pointers into the middle of [unlocked] handles are (for
> practical purposes) impossible.  Hence no MI in HandleObject.

In discussions with colleagues here, someone suggested that the problem
of pointers into unlocked handles might be solved by representing such
"pointers" as a pair consisting of a handle and an offset.  This would be
at the implementation level, the user would still write *p and the code
generated would do a double dereference + offset.

I'll leave to the experts the question of whether this would work or be
practical.

___
\X/ Richard Kennaway, [e-mail], Univ. of East Anglia, Norwich

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Mon, 14 Nov 1994 17:29:48 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Atman Jacob Binstock) writes:
>The solutions I outlined are doable if you really really want C++
>objects in movable memory.  However, I found Symantec C++ 7.0.3's
>__machdl's much too buggy to make a simple class work correctly.
>Classes mixing __machdl's and templates would rarely compile, and those
>that did would often had faulty code generated.  I would strongly
>suggest avoiding __machdl classes, unless you have very simple classes
>and you are very tight on memory.

      Yes.  I reported many bugs in this area to Symantec back in
late 1993, as long-time readers of this group may remember.  In general,
trying to do anything with a "Pascal object" or "handle object" in SC++
that isn't required for Think C compatibility probably won't work.

                                        John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Mon, 14 Nov 1994 17:38:39 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Jens Alfke <[e-mail]> writes:
>I think you mean "member objects" -- instance variables of an object which
>themselves are C++ objects. You can use these (and I have) with handle-based
>objects, provided that the member object is not a handle (obvious, since you
>can't put a handle inside a handle) and that pointers to the member object
>are not kept around for a long time -- you can keep pointers to the member
>object around as long as you are not calling any Toolbox routines or as long
>as the owning handle object is locked down, but not longer than that.
>Provided you obey those rules (which are very much like any other
>handle-based Mac techniques) you can use handle-based C++ objects just fine.

     Doesn't work for member objects with constructors.  The member's
constructor gets called with the owning handle object not locked down.
If the member's constructor does an allocation, the owning handle object
may move.  The user can't program around this, because there's no place
where user code has control that the locking could be performed.  The
owning handle object's constructor doesn't get called until it's too late,
and the member's constructor doesn't know it's inside a handle.

     If C++ is to be used with handles, the compiler is going to have
to generate HLock/HUnlock calls in some situations.  There's too much
automatic object behavior in C++ for manual locking to work.

                                        John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Greg Ewing)
Date: 15 Nov 1994 00:44:15 GMT
Organization: University of Canterbury, Christchurch, New Zealand


In article <3a7bf8$[e-mail]>, Richard Kennaway <[e-mail]> writes:
|> representing such
|> "pointers" as a pair consisting of a handle and an offset.
|>
|> I'll leave to the experts the question of whether this would work or be
|> practical.

I have no doubt that it could be made to work; whether it
would be worth the effort is another matter.

This scheme would have to be used consistently for every
single pointer of any kind whatsoever. Every pointer
dereference would involve doing something quite complicated,
since it would have to take account of the case where
it's really just an ordinary pointer, and if not,
do a double-dereference-and-add.

C++ programmers might not be very impressed when they find
that an innocent-looking piece of code like

        *p++ = *q++;

generates about a dozen instructions!

Some optimisations may be possible if the compiler can
prove that a given pointer is referencing something that
won't move during some region of code. How often the
compiler could prove this I don't know.

Also, some provision would need to be made for interfacing
with the toolbox and other pieces of code that don't
know about all of this.

So, it could be done, but it would have far-reaching
consequences. Probably it's much better to forget about
handles and hope that Apple comes up with a decent
virtual-address-space OS.

|> \X/ Richard Kennaway, [e-mail], Univ. of East Anglia, Norwich

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|
[e-mail]         +--------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 14 Nov 1994 19:39:21 -0800
Organization: Novell, Inc., Walnut Creek/Macintosh Site

In article <[e-mail]>,
[e-mail] (Bruce Hoult) wrote:

> Nathaniel P Woods <[e-mail]> writes:
> > Jens wrote:
> > > I've used dynamic-array classes...
> > What this means is that you cannot define a subclass of this class.
> You can subclass it fine, as long as you don't add any data mambers.

This holds true until you try to compile such classes with a compiler
which wants to put the hidden data members (the ones that point into the
various tables, including but not limited to the virtual function
dispatcher) at the *end* of the object instead of at the beginning. Since
ARM says compilers can put these members anywhere it's convenient, it's
likely some compiler somewhere does or will do this.

Personally, I find that it's easier to put dynamically sized structures in
their own allocated block, with only a pointer or handle in the object,
since it's easier and less expensive to do reference counting for copies
that way.

However, I do think it would be nice for ANSI to specify that the hidden
members be placed at the beginning of an object *and* specify rules the
compiler could enforce for unbounded array declarations within classes.
Perhaps there are implementation restrictions of which I am not aware.

--
 The views expressed here do not necessarily reflect those of my employer.

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 14 Nov 1994 19:45:23 -0800
Organization: Novell, Inc., Walnut Creek/Macintosh Site

In article <[e-mail]>,
[e-mail] (Robert Mah) wrote:

> One of the few benefits handle based objects
> would provide is dynamically resizable objects, but since C++ objects can
> be stack based...

...you need to make the constructor protected and provide a static member
function which calls it in the right way.

There's always a smart-ass ready to step in and snipe, eh? :-)

--
 The views expressed here do not necessarily reflect those of my employer.

 "Furthermore, in my mad haste to switch CDs, I dragged the Inside Mac CD-ROM
 icon to the trash and when the Mac ejected it, the tray pushed a glass of
 grape juice off my desk and into my lap. Let that be a lesson to
 development tool vendors: all this would have been avoided with better
 documentation." -- Miguel Cruz <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Wed, 16 Nov 1994 21:55:24 +1300 (NZDT)
Organization: (none)

[e-mail] (Pete Gontier) writes:
> However, I do think it would be nice for ANSI to specify that the hidden
> members be placed at the beginning of an object *and* specify rules the
> compiler could enforce for unbounded array declarations within classes.
> Perhaps there are implementation restrictions of which I am not aware.

Well, yeah, there are good reasons that they can't always go at the
front.  Consider:

class a {
        void dosomething();
        int calculatethis();

        int i;
        char c;
};

class b: public a {
        virtual void dosomethingelse();
};


Now, class "a" dosn't have any virtual functions, and therefore
doesn't have a vptr.  Class "b" has a virtual function, and needs a
vptr, and so it has to go after class "a"'s data members, unless you
want to break lots of programs.

It *would* be possible to make use of the mechanism provided for multiple
inheritence to put the vptr at the front, and have a cast from a* to b*
(or the revers) add a constant.  But I don't think people would expect that.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Shahid M. Alam)
Date: Wed, 16 Nov 1994 08:19:12 -0600
Organization: The University of Texas at Austin

In article <[e-mail]>,
[e-mail] (Pete Gontier) wrote:
> ...you need to make the constructor protected and provide a static member
> function which calls it in the right way.

or an argument-taking ctor to do the same (while protecting the default ctor).

______________________
Shahid M. Alam
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Wed, 16 Nov 1994 21:55:24 +1300 (NZDT)
Organization: (none)

[e-mail] (Pete Gontier) writes:
> However, I do think it would be nice for ANSI to specify that the hidden
> members be placed at the beginning of an object *and* specify rules the
> compiler could enforce for unbounded array declarations within classes.
> Perhaps there are implementation restrictions of which I am not aware.

Well, yeah, there are good reasons that they can't always go at the
front.  Consider:

class a {
        void dosomething();
        int calculatethis();

        int i;
        char c;
};

class b: public a {
        virtual void dosomethingelse();
};


Now, class "a" dosn't have any virtual functions, and therefore
doesn't have a vptr.  Class "b" has a virtual function, and needs a
vptr, and so it has to go after class "a"'s data members, unless you
want to break lots of programs.

It *would* be possible to make use of the mechanism provided for multiple
inheritence to put the vptr at the front, and have a cast from a* to b*
(or the revers) add a constant.  But I don't think people would expect that.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Shahid M. Alam)
Date: Wed, 16 Nov 1994 08:19:12 -0600
Organization: The University of Texas at Austin

In article <[e-mail]>,
[e-mail] (Pete Gontier) wrote:
> ...you need to make the constructor protected and provide a static member
> function which calls it in the right way.

or an argument-taking ctor to do the same (while protecting the default ctor).

______________________
Shahid M. Alam
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Wed, 16 Nov 1994 21:55:24 +1300 (NZDT)
Organization: (none)

[e-mail] (Pete Gontier) writes:
> However, I do think it would be nice for ANSI to specify that the hidden
> members be placed at the beginning of an object *and* specify rules the
> compiler could enforce for unbounded array declarations within classes.
> Perhaps there are implementation restrictions of which I am not aware.

Well, yeah, there are good reasons that they can't always go at the
front.  Consider:

class a {
        void dosomething();
        int calculatethis();

        int i;
        char c;
};

class b: public a {
        virtual void dosomethingelse();
};


Now, class "a" dosn't have any virtual functions, and therefore
doesn't have a vptr.  Class "b" has a virtual function, and needs a
vptr, and so it has to go after class "a"'s data members, unless you
want to break lots of programs.

It *would* be possible to make use of the mechanism provided for multiple
inheritence to put the vptr at the front, and have a cast from a* to b*
(or the revers) add a constant.  But I don't think people would expect that.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Shahid M. Alam)
Date: Wed, 16 Nov 1994 08:19:12 -0600
Organization: The University of Texas at Austin

In article <[e-mail]>,
[e-mail] (Pete Gontier) wrote:
> ...you need to make the constructor protected and provide a static member
> function which calls it in the right way.

or an argument-taking ctor to do the same (while protecting the default ctor).

______________________
Shahid M. Alam
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Fri, 25 Nov 1994 15:19:01 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>, [e-mail] (Miguel Cruz) wrote:

> In article <[e-mail]>, Miguel Cruz <[e-mail]> wrote:
> >understand how to do C on the Mac. What I don't understand is the way to
> >create C++ objects into memory I got as a handle from the Memory Manager
>
> Okay, I downloaded TECplusSample from ftp.apple.com and they used some
> mysterious class HandleObject. I tried that and it appears to work just
> fine. However, I'd really like to find the documentation of this. In
> desperation, I searched my entire hard disk for the text 'HandleObject'
> and it was nowhere (except in TECPlusSample).

HandleObject (and PascalObject) were and are documented int the MPW C++
documentation.

--Kent

--
Kent Sandvik   [e-mail]   New Media Analyst/Programmer
Private activities on Internet.

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

>From [e-mail] (Sean Crist)
Subject: Finding out whether text is selected in a dialog
Date: 11 Nov 1994 18:33:16 GMT
Organization: University of Pennsylvania, Linguistics Department

My application has modeless dialogs containing editable text items, and I
want to tell whether some text is actually selected so that I can
enable/disable the Cut and Copy commands appropriately.  There's lots of
handy routines going back as far as OldIM Vol. I to handle the actual
cutting and pasting, but I don't see any prescribed way to tell whether
some text is selected.

The solution appears to be to look at the TextH field of the dialog record
to get the currently active TEHandle, and then look in that TEHandle to see
whether any text is selected.  What I want to know is whether this is
kosher; mucking around in the Toolbox's data structures like this seems to
be discouraged, but I don't see any other way to do this.

  \/ __ __    _\_     --Kurisuto  ([e-mail])
 ---  |  |    \ /
  _| ,| ,|   -----    For a free copy of the Bill of Rights, finger
  _| ,| ,|    [_]     this account.
   |  |  |    [_]





+++++++++++++++++++++++++++

>From [e-mail] (Barton Jaques)
Date: Tue, 15 Nov 1994 12:21:44 -0700
Organization: Wimsey Information Services

The solution appears to be to look at the TextH field of the dialog record
to get the currently active TEHandle, and then look in that TEHandle to see
whether any text is selected.

  Yes, that's exactly what you should do. Check TERec.selStart and
TERec.selEnd to see if any characters are selected, then find them in
TERec.hText (handle to text).

  You're not actually mucking with Apple's precious data structures,
you're just spying on them. Anyway, in my ModalDialogs I quite freely
discard Apple's hTexts and replace them with my own. Just call TECalText
(and maybe TESetSelect) and TEUpdate afterward to make sure everything
still displays right.
--
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Thu, 24 Nov 1994 10:37:29 +0800
Organization: Department of Computer Science, University of Western Australia

In article <3a0ddc$[e-mail]>, [e-mail]
(Sean Crist) wrote:

>The solution appears to be to look at the TextH field of the dialog record
>to get the currently active TEHandle, and then look in that TEHandle to see
>whether any text is selected.  What I want to know is whether this is
>kosher; mucking around in the Toolbox's data structures like this seems to
>be discouraged, but I don't see any other way to do this.

Welcome to the world of the Dialog Manager, where lots of things just
can't be done nicely.  You have to either accept that and do them horribly
or eschew the Dialog Manager and do it all yourself.  For an official DTS
line on this, take at look at the following TechNote...

  M.TB.ToolboxKarma M.TB39 TN227
  "Toolbox Karma"
  This Technical Note discusses Macintosh Toolbox compatibility and what you
  can do to help the Macintosh continue evolving in the future.

Share and Enjoy.
--
Quinn "The Eskimo!"  "Some-kind-of-secret-weapon-came-out-of-nowhere-
                      and-took-Captain-Bipto-to-his-dooooooooom!"
  May the Force be with you!

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

>From [e-mail] (Gary McGath)
Subject: How to get default 'aeut' resource?
Date: Fri, 18 Nov 1994 15:52:29 GMT
Organization: Conceptual Design

  I'm trying to figure out the right way to access the 'aeut' resource of
the default scripting component. OpenComponentResFile() looks as if it
might provide a key portion of the answer, but the documentation implies
it can only be called from within a component. Either general advice or
pointers to sample source code would be welcome. If convenient, please
copy to me by E-mail.

--
          Gary McGath
          [e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 23 Nov 1994 00:32:20 GMT
Organization: Apple Computer

Gary McGath, [e-mail] writes:
>   I'm trying to figure out the right way to access the 'aeut' resource of
> the default scripting component. OpenComponentResFile() looks as if it
> might provide a key portion of the answer, but the documentation implies
> it can only be called from within a component.

There is an undocumented OSAGetSysTerminology call that AppleScript
implements (this is what the Script Editor calls) but it appears to have been
sanitized out of the shipping OSA.h and AppleScript.h headers.
However, it is safe to call OpenComponentResFile on another component, so you
can do it that way. Just remember to detach the resource and make it
unpurgeable, of course.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 25 Nov 94 11:25:56 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, Jens Alfke <[e-mail]> writes:
>
> There is an undocumented OSAGetSysTerminology call that AppleScript
> implements (this is what the Script Editor calls) but it appears to have been
> sanitized out of the shipping OSA.h and AppleScript.h headers.

I believe you'll find this call in ASDebugging.h/.p. It looks like this:

    CONST
        kASSelectGetSysTerminology = 0110BH;


    PROCEDURE OSAGetSysTerminology
      (
        scriptingComponent : ComponentInstance;
        modeFlags : AESendMode;
        terminologyID : ShortInt;
        VAR terminologyList : AEDesc
      ) : OSAError;

        CODE
            02F3CH, 10, kASSelectGetSysTerminology,
            07000H,
            0A82AH;

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

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

>From [e-mail] (Steven J. Mcclue)
Subject: MacsBug - what is it and why?
Date: Mon, 21 Nov 1994 10:19:23 +0000
Organization: Dept of Genetics, University of Cambridge

Apologies if this is the wrong place for this, but could someone tell me what programmers use MacsBug for? I'm a real newbie at programming (ie, I'm about half way through Dave Mark's book "Learn C on the Mac" and not finding it easy!!), and I've often seen mention of MacsBug. I used to have a copy, but on the rare occasions it popped up, it seemed full of unintelligible stuff. Now that I'm deling with lots of unintelligible stuff, maybe some kind soul could enlighten me as to what it all means?

Thanks!
Steve McClue
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Eric Jackson)
Date: Mon, 21 Nov 1994 16:27:23 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <sjm-2111941019230001@131.111.46.92>,
Steven J. Mcclue <[e-mail]> wrote:
>Apologies if this is the wrong place for this, but could someone tell me what programmers use MacsBug for? I'm a real newbie at programming (ie, I'm about half way through Dave Mark's book "Learn C on the Mac" and not finding it easy!!), and I've often seen mention of MacsBug. I used to have a copy, but on the rare occasions it popped up, it seemed full of unintelligible stuff. Now that I'm deling with lots of unintelligible stuff, maybe some kind soul could enlighten me as to what it all means?
>
>Thanks!
>Steve McClue
>[e-mail]

Yes this is exactly the place to post questions like this.  The idea
behind this news group was to provide a place for newbies to post questions
with out having to feel embarassed about it.  What is MacsBug,
that would take a while to explain in detail.  In one sentince
its a LowLever debugger, and a good one.  This means that it takes
you down into the assemble language lever.  I have never writen any
assemble language code but I still like to look at it.  After a
while you will start to learn more and more about it.

Here are a couple of basic tips.  You can get into MacsBug by
calling: DebugStr("\p your debugger comment goes here");
with the think Use Debugger option turned of.  Once your in the
debugger you can go again assuming things are not messed up by
typing g, to step one step at a time type s, to get out of your
application type ea for exit application, if your application is
already messed up type rb for reboot.  You can also type es for
exit shell.  Type h for help and get a list of all the commands,
type il for instruction list and get an assembly language list of
your code.  If you look at it you might be able to see some tool
box routines that you recognise to get an idea of where you are.

Normally you use a lowlever debugger when your high level debugger
is not working correctly in finding a bug.  There is quite a lot
more to know about MacsBug, but this will give you a really short
overview.

Eric Jackson
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Marc Cooperman)
Date: Tue, 22 Nov 1994 10:07:55 -0500
Organization: Jumpstart Technologies

I don't claim to be a MacsBug expert.

It's a low-level debugger - which means, generally, you don't see source
code in it, but you can look directly at the Macs memory, registers, and
program counter, which describe its state, at a level below such higher
level languages like C.

You enter MacsBug in 2 situations - the machine encounters a heinous
processing error in a particular program from which it can't recover, so
it gives up, and
deposits you into the aesthetically pleasing MacsBug screen, in the vain
hope the you too speak hexdecimal and will be able to diagnose the
problem. In this case you can type es [Return] to try and cleanly exit the
program and recover to the finder, or ea [Return] to try restarting the
offending program from scratch.
If you're feeling brave, you can try the sc or sc7 commands to do a "stack
crawl" which basically shows you a heirarchy of function calls leading up
to the crash. If the program was compiled with debugging info, you may
actually see readable function names, and if this a development project of
your own, it may give you a clue where to look for a bug in your code.

The other situation is a forced MacsBug entry where you either hit the
interrupt switch on your Mac (I think this causes an "NMI" Non Maskable
Interrupt? on the processor) which puts you immediately in MacsBug with
the "NMI" message, or by calling DebugStr() from your code, which can
print a message of your choice, say if you detect an error condition like
a NULL pointer BEFORE it actually hoses your machine.

In article <sjm-2111941019230001@131.111.46.92>, [e-mail]
(Steven J. Mcclue) wrote:

> Apologies if this is the wrong place for this, but could someone tell me
what programmers use MacsBug for? I'm a real newbie at programming (ie,
I'm about half way through Dave Mark's book "Learn C on the Mac" and not
finding it easy!!), and I've often seen mention of MacsBug. I used to have
a copy, but on the rare occasions it popped up, it seemed full of
unintelligible stuff. Now that I'm deling with lots of unintelligible
stuff, maybe some kind soul could enlighten me as to what it all means?
>
> Thanks!
> Steve McClue
> [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: Mon, 28 Nov 1994 15:56:13 -0500
Organization: The Pitt, Chemistry

In article <[e-mail]>, [e-mail] (Eric Jackson) wrote:

> Normally you use a lowlever debugger when your high level debugger
> is not working correctly in finding a bug.  There is quite a lot
> more to know about MacsBug, but this will give you a really short
> overview.

   [tips omitted]

   If you [original poster] are interested in getting a handle on
     more info, consider buying a copy of:

        _MacsBug Reference and Debugging Guide_
          by Apple Computer  $35
                 Addison Wesley, 1990, ISBN: 0-201-56768-7

     just started chewing on it myself.  But it seems to be the only
     reference for MacsBug.

   BTW, anyone know if there is a chance that this will eventually
     wind up in DocViewer format on a _develop_ bookmark or Developer
     reference CD?  I'm kind of surprised it hasn't, maybe Apple is
     waiting for version 6.5 final release before doing it...?


 Internet: [e-mail]            _/   _/  _/  _/_/_/   _/   _/
   eWorld: nick                     _/_/ _/  _/  _/   _/  _/_/_/
      CIS: 71232,766               _/ _/_/  _/  _/       _/ _/
     http://www.pitt.edu/~nick/   _/   _/  _/   _/_/_/  _/   _/


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

>From [e-mail] (Telesis North)
Subject: how to get PB in PPC completion routine?
Date: Thu, 24 Nov 1994 23:53:56 GMT
Organization: sparodic

Does anyone out there have a good strategy for writing completion routines
that compile for both PPC and 68K?

My problem is that I have to write a completion routine for the serial
driver. I would _really_ like to get access to the parameter block;
unfortunately, it's not passed as a parameter. (That would be too
sensible.)

For 68K, A0 comes in pointing to the PB, and a bit of assembly will put it
into a local variable. Clearly this isn't going to work on a PowerMac.

(I realize that I could leave the completion routine as 68K without a
significant performance hit - at least until Copland - but I'd prefer not
to complicate my build process with mixed code.)

Anyone have any ideas? (What does DTS think?)

--
Roger Pantos                 Telesis North, Inc.           telesisnorth
Mac Software Guy             [e-mail]       (AppleLink)
"They want better products for free."  -- from "Dilbert"

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 24 Nov 1994 23:55:12 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Telesis
North) writes:

>My problem is that I have to write a completion routine for the serial
>driver. I would _really_ like to get access to the parameter block;
>unfortunately, it's not passed as a parameter. (That would be too
>sensible.)
>
> (a bunch ommitted )
>
> Anyone have any ideas? (What does DTS think?)

Look in Files.h and you'll find what you need for IOCompletion routines.
If you're compiling native, the parameter block pointer is passed to your
completion routine as a parameter.

However, for the time being I'd leave completion routines in 68K code
because the Device Manager is still emulated 68K code.  You'd have the
overhead of a couple of mixed mode switches if your completion routine was
written in PowerPC code.  Since you shouldn't be doing processor intensive
processing at completion time anyway, writing PowerPC completion routines
shouldn't help your performance (and quite possibly will hurt it under
System 7).

- Jim Luther

+++++++++++++++++++++++++++

>From [e-mail] (Paul Lalonde)
Date: Fri, 25 Nov 1994 07:46:39 -0400
Organization: McGill University School of Architecture

In article <[e-mail]>, [e-mail] (Telesis
North) wrote:

> Does anyone out there have a good strategy for writing completion routines
> that compile for both PPC and 68K?
>
> My problem is that I have to write a completion routine for the serial
> driver. I would _really_ like to get access to the parameter block;
> unfortunately, it's not passed as a parameter. (That would be too
> sensible.)


If you're using CodeWarrior, you can declare a function argument as residing
in a register (68K only). You would then have a slightly different function
declaration for your completion proc, depending if you're compiling for the
PPC or not:

#if USESCODEFRAGMENTS
extern void  MyCompletionProc(ParmBlkPtr pbPtr);
#else
extern void MyCompletionProc(ParmBlkPtr pbPtr : __A0);
#endif


And the code would look like this:


#if USESCODEFRAGMENTS
void  MyCompletionProc(ParmBlkPtr pbPtr)
#else
void MyCompletionProc(ParmBlkPtr pbPtr : __A0)
#endif
{
   ParmBlkPtr   pb  = pbPtr;

   // do stuff here -- don't forget to set up A5!
}


Hope this helps

Paul Lalonde
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Sat, 26 Nov 1994 15:59:48 +0100
Organization: The Conspiracy

In article <[e-mail]>,
[e-mail] (Telesis North) wrote:

>My problem is that I have to write a completion routine for the serial
>driver. I would _really_ like to get access to the parameter block;
>unfortunately, it's not passed as a parameter. (That would be too
>sensible.)

Oh, but on the PowerPC runtime architecture, it IS passed as a
parameter. And you can force the compiler to use a parameter in
A0 under 68K by using #pragma parameter. So your callback can
have a declaration like any function, with a
pointer-to-param-block argument.

>For 68K, A0 comes in pointing to the PB, and a bit of assembly will put it
>into a local variable. Clearly this isn't going to work on a PowerMac.

The PowerMacs have one, well-defined calling convention, used
*everywhere*

>(I realize that I could leave the completion routine as 68K without a
>significant performance hit - at least until Copland - but I'd prefer not
>to complicate my build process with mixed code.)

Not only that, but you'll SEE a large performance hit for the
NATIVE callback, because the serial drivers are 68K code.

You can of course build a routine descriptor that describes the
calling convention of the callback and use that.

Cheers,

                                        / h+


--
  Jon Wdtte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
 ~r ~/.signature


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

>From [e-mail] (Christian E. Hopps)
Subject: oops..
Date: 20 Nov 1994 09:27:55 GMT
Organization: University of Michigan EECS Dept.

I caught myself (luckily) making a big mistake today.

void
func(SomeHandle joe)
{
        (**joe).j_rgn = NewRgn();       /* bug */

I think this should be in the FAQ regarding handles.  Not many
programmers (I think) deal with Order of Evaluation issues like
this one.  At least for me, handles are something new and so
the above code didn't seem bad.

Incase you haven't caught the bug (its probably patently obviuos
to long time mac people).  NewRgn() will move memory (or so
you should assume) and C (most languages?), except in the case of
&&, ||, comma, and ?:, does not specify order of evaluation.
Therefore assuming worst case, the compiler evaluates the handle,
i.e. locates the memory to store to and then calls NewRgn().  Finally
it stores the result in the afore mentioned memory.  Oops except
NewRgn() moved memory so the result is stored in bogusville.

Thus the proper thing to do is:
        RgnHandle rh;

        rh = NewRgn();
        (**joe).j_rgn = rh;

Things like ap[i] = i++; are obvious to me.  Being new to handles
however hid the order of evaluation issue from me.  Maybe this should
go in the FAQ?

Chris.

+++++++++++++++++++++++++++

>From [e-mail] (Stefan Kurth)
Date: 21 Nov 1994 00:34:28 +0100
Organization: none

In article <3an4qr$[e-mail]>, [e-mail]
(Christian E. Hopps) wrote:

> void
> func(SomeHandle joe)
> {
>       (**joe).j_rgn = NewRgn();       /* bug */
>
> I think this should be in the FAQ regarding handles.

There's an explicit warning about this in Inside Macintosh (both the old
IM Vol I and NIM:Memory).

BTW, I'd strongly suggest to get yourself a copy of QC; it does a
terrific job at finding such bugs for you (and many others too).  A demo
is available at the common Mac archives, the full version is something
like $99.  Well worth the money.

________________________________________________________________________
Stefan Kurth             Berlin, Germany          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Miika Asunta)
Date: 24 Nov 1994 23:15:23 GMT
Organization: Sibelius Academy, Helsinki

In <3an4qr$[e-mail]> [e-mail] (Christian E. Hopps) writes:

>I caught myself (luckily) making a big mistake today.

>void
>func(SomeHandle joe)
>{
>       (**joe).j_rgn = NewRgn();       /* bug */

>Thus the proper thing to do is:
>       RgnHandle rh;

>       rh = NewRgn();
>       (**joe).j_rgn = rh;

Or as well:

MoveHHi(joe); HLock(joe);
(**joe).j_rgn = NewRgn();
HUnlock(joe);
--
Miika Asunta
[e-mail]                    Double Bass Player
tel. [phone]                   Macintosh Programmer

+++++++++++++++++++++++++++

>From [e-mail] (Christian E. Hopps)
Date: 25 Nov 1994 05:40:49 GMT
Organization: University of Michigan EECS Dept.

Miika Asunta ([e-mail]) wrote:
: In <3an4qr$[e-mail]> [e-mail] (Christian E. Hopps) writes:

: >I caught myself (luckily) making a big mistake today.

: >void
: >func(SomeHandle joe)
: >{
: >     (**joe).j_rgn = NewRgn();       /* bug */

: >Thus the proper thing to do is:
: >     RgnHandle rh;

: >     rh = NewRgn();
: >     (**joe).j_rgn = rh;

: Or as well:

: MoveHHi(joe); HLock(joe);
: (**joe).j_rgn = NewRgn();
: HUnlock(joe);

Have you profiled that?  I recommend highly that you do it my way. :)

Chris.

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

End of C.S.M.P. Digest
**********************