HDTenEightyP/NetNews huggingface dataset:
From: TOM_BECKER@UMACMAIL.APLDBIO.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MethTables? Use -NoBottlene
Date: 27 Jan 93 19:12:00 GMT
Organization: AppleLink Gateway

From: "Tom Becker" <Tom_Becker@umacmail.apldbio.com>
To: "MacApp3 Tech$" <macapp3tech$@applelink.apple.com>
 
MethTables? Use -NoBottleneck!
Dear Friends,
 
If your %_Methtables segment overflows, and you're trying to build with -Debug,
the first thing you should try is -NoBottleneck.  MABuild -Debug automatically
turns on -Bottleneck, which inhibits the linker's method table optimizations.
MABuild -Debug -NoBottleneck turns the optimizations back on.  The caveat is
you lose "discipline method calls" on all the methods that are optimized into
ordinary procedure calls, so you could end up inside a method with "this ==
nil"!  Check objects with FailNonObject before calling their methods.
 
If you're or overflowing your method table and you're already using
-NoBottleneck or -NoDebug, my deepest sympathies.  Before you try -Model Far,
you may want to try hacking your application so it has fewer classes and fewer
overridden methods.  Not only may this get you in under the wire, it can
improve your app's structure and performance at the same time.
 
Hope this helps,
 
Tom Becker
Applied Biosystems, Inc.
twb@apldbio.com
 
 
 
Newsgroups: comp.sys.mac.oop.macapp3
From: lsr@taligent.com (Larry Rosenstein)
Subject: Re: Defections from BedRock?
Followup-To: comp.sys.mac.oop.macapp3
Organization: Taligent, Inc.
Date: Fri, 22 Jan 1993 19:05:00 GMT

In article <1993Jan21.173741.7225@netcom.com>, nagle@netcom.com (John
Nagle) wrote:
> 
>        - The system is "brittle", in that incorrect parameters to system 
> 	 calls can result in system errors.  (This is not true of UNIX,

I seem to recall an article in CACM where someone tried passing random
parameters to UNIX system calls.  They were able to make some kernels crash
quite easily.  Certainly the Mac is much worse in this regard, but UNIX is
not perfect.

>        - C, and C++, are not "safe" languages.  Yes, they are popular.

C++ is quite a bit safer than C, and I think it's as safe as Pascal.  (At
least something like MPW Pascal where you can do various casts, etc.)  MPW
C++ may not catch as many errors as it should, but that's a compiler
problem, not a language problem.

>        - The use of "trap patching" results in interdependencies
> 	 between programs which continually cause problems.  The
>          whole "system extensions" concept is flawed.  Interdependency

The problem is that INIT-writers don't appreciate the fact that any trap
patch becomes part of the system software.  People call upon Apple to solve
this problem, but I don't think there's any solution, other than to
restrict extensions to using hooks that Apple has defined.  (But then you
have to give up things like a hierarchical Apple menu.)

Larry Rosenstein
Taligent, Inc.

lsr@taligent.com
From: SHIGEYA@FORETUNE.CO.JP
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: PC9800
Date: 21 Jan 93 10:32:00 GMT
Organization: AppleLink Gateway

From: Shigeya Suzuki <shigeya@foretune.co.jp>
To: JHA.RD.DVJ@AppleLink.Apple.COM (Ha Telecom,  Roger Diaz, IDV)
Cc: MACAPP3TECH$@AppleLink.Apple.COM (MacApp 3 Technical Discussion),
     shigeya@foretune.co.jp
 
I answered three questions as below. But I think these things are not
fit on the scope of this list. You'd better to choose other
forum/list/newsgroups to ask these questions.
 
Also, I guess you're Developer and in Japan. You'd better ask someone
in your company to ask these questions. I think there are very few
people who can answer these questions.
 
I included bit extra information for other developers, so anyway,
 
>>>>> On 19 Jan 93 08:07 GMT, JHA.RD.DVJ@AppleLink.Apple.COM (Ha Telecom, Rog
er Diaz,IDV) said:
 
Roger>    1) What files other than those from IchiTaro can be imported
Roger> to the Mac from NEC PCs?
 
Up to the application you're using.
 
But I don't know applications which can import other than Ichi-Taro.
(may exist, but I don't know.
 
Ichitaro is best selling Word Processor for NEC PC9801 (best selling
Personal Computer in Japan) but recently it is availble for othe
platforms.
 
Roger>    2) What are the top selling programs for business and
Roger> general use on the PC 9800 series?
 
If you say, general use, it must be Lotus 1-2-3 or Excel, or some
database program like dBase.
 
Roger>    3) Do products exist which allow data to transferred between
Roger> the Atari Portfolio, Sharp Wizard or Casio's PDAs and the Mac?
Roger> If so, what are their names?
 
I know there are transfer program/cable apckage for Sharp Wizard in
states, but protocol and cable is differnt from Japanese version of
Sharp organizer.
 
Recently ParcWay released a package which includes HyperCard stack and
cable to transfer between Sharp organizer (like PA-8500, PA-X1, etc.)
and Macinosh.
 
Roger>    4) Does anyone know the name of the product introduced last
Roger> year by Xerox which allows you to command your computer to send
Roger> files to a destination from any fax machine?
 
I don't know this.
 
Shigeya Suzuki
shigeya@foretune.co.jp / AppleLink: FORETUNE.DVJ
From: VELOCIO@AppleLink.Apple.COM (Maurer, Joseph)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: When no printer is selecte
Date: 25 Jan 93 23:35:00 GMT
Organization: AppleLink Gateway

Try to look at the 'STR ' resource -8192 in the System file. It holds the name
of the currently chosen printer, and probably contains the null string (or does
not exist at all?) if no printer has been chosen.
 
Joseph Maurer
From: ENS.CC@AppleLink.Apple.COM (ENS Computer Consulting,CAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Record -> Struct
Date: 21 Jan 93 08:01:00 GMT
Organization: AppleLink Gateway

Attn: MacApp3 Tech $
SentBy: Paul Ens
 
Record -> Struct                                     1/18/93    3:32 PM
 
Hello all,
 
(I've been having problems with this message, my appologies to anyone who gets
multiple copies.)
 
In a Pascal unit, I have the following record type, along with a function,
returning me an "empty" record:
 
   AddressFormat = (None,HStApt,AptStH,LotBlock,LandLoc,Parcel);
   Addr_Rec = RECORD
       HNo : String[12];
       Apt : String[7];
       Street : String[30];
       addrForm : AddressFormat;
   END;
 
I want to convert this unit to C++ for use in both Pascal and C++ programs.
So, I defined a struct as follows:
 
   enum AddressFormat { None, HStApt, AptStH, LotBlock, LandLoc, Parcel };
   struct Addr_Rec
   {
       unsigned char   HNo[13], Apt[8], Street[31];
       AddressFormat   addrForm;
   };
   typedef struct Addr_Rec Addr_Rec;
 
The problem comes when I want to write the function to return an empty one. I
can't figure out how to make each field an empty Pascal string.
 
'(myRec)->HNo = "\p"' doesn't work. I get told that I can't assign a constant
to a variable. I've tried using combinations of CStr255, but to no avail.
 
I know that I could set the proper byte to zero to get empty strings, but that
won't help later when I want to set values to something specific.
 
Can someone let me in on the proper way to do this?
 
Thanks.
 
Paul Ens
ENS Computer Consulting
 
Newsgroups: comp.sys.mac.oop.macapp3
From: koppi@aplcenmp.apl.jhu.edu (Jeffrey Alan Koppi)
Subject: TPicture, no mPictureHit?
Organization: Johns Hopkins Continuing Professional Programs
Date: Wed, 20 Jan 1993 23:08:23 GMT



I have created a TWindow that contains a TPicture 
as a subview using Ad Lib.  The TPicture displays 
a pict which contains icon-like buttons.  

The problem is: when I click the mouse within the 
pict, I am NOT getting mPictureHit events
in my TMyPicture::DoEvent() function.  

Does anyone have an idea what I am missing? 
Thanks in advance.

Jeff Koppi
koppi@aplcenmp.apl.jhu.edu
From: V0645@AppleLink.Apple.COM (Tandem, Gary Campbell,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: MacApp Reference is great
Date: 27 Jan 93 04:54:00 GMT
Organization: AppleLink Gateway

Hi,
 
I have to second this, I'm using the reference more than the 411 help
because it is the same information, actually faster to find information
because the organization is soooooo good, and I don't have to keep the
CD with the 411 files on-line all the time.
 
Get it, its cool.
 
Gary Campbell
Tandem Computers
V0645
From: MARSHALL_CLOW@HPSDR163.SDD.HP.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: When no printer is selec
Date: 26 Jan 93 09:36:00 GMT
Organization: AppleLink Gateway

From: "Marshall Clow" <marshall_clow@hpsdr163.sdd.hp.com>
To: CSX.TECH.DEV@AppleLink.Apple.COM,  macapp3tech$@applelink.apple.com
 
        Reply to:   RE>When no printer is selected
 
> Does anyone know the proper way to detect that the user has not selected a
> printer in the Chooser? The MacApp printing mechanism is not very
well-behaved
> under this circumstance, so I'd prefer to avoid calling InitUPrinting and to
> disable the Print menu item when this is the case.
 
> Thanks ahead of time!
 
> Jim Stead
> CSX Technology
 
The name of the currently selected printer driver is stored in the system file
in resource 'STR '(-8192). If the user has never selected a printer, that
string
will be empty. A more subtle problem occurs if the user has selected a printer
and the printer driver had been moved, renamed, or deleted. This is left as an
exercise for the user. (Don't forget to look in both the Syustem folder and the
Extensions folder under System 7, and to resolve aliases! )
 
-- Marshall
From: Bob Cent <cent@u.washington.edu>
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MacApp Reference (R0195LL/A)
Date: 22 Jan 1993 23:40:38 GMT
Organization: University of Washington
Distribution: world
NNTP-Posting-Host: cent.rprc.washington.edu
X-UserAgent: Nuntius v1.1.1d12
X-XXMessage-ID: <A785C7393C010B23@cent.rprc.washington.edu>
X-XXDate: Fri, 22 Jan 93 15:46:01 GMT

Greetings,

I have heard that the APDA MacApp Reference (R0195LL/A) is a very useful
book.  Unless I'm mistaken, I believe that the book is a reference for
MacApp 3.0;  I am using MacApp 2.01.  Would this book be of any value to
me?

Bob Cent  (cent@u.washington.edu)
University of Washington, SJ-50
Seattle, WA  98195
Newsgroups: comp.sys.mac.oop.macapp3
From: totic@milton.cs.uiuc.edu (Aleksandar Totic)
Subject: Looking for a better TEView, >32K chars & expandable
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Wed, 27 Jan 1993 23:26:55 GMT

Hi,
I am about to start writing a text viewer application, that might include
graphics and more than 32K characters in the future. I will also need to 
assign properties other than styles to regions of text. It seems that I will
need to implement most of the features of a text-editor. Has anyone 
implemented anything similar, or knows where can I find examples of 
views like this? Final product will be in the public domain, so I cannot
use any commercial code.

Aleks
From: MADA@AppleLink.Apple.COM (MADA Admin, Steve Mann,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: RE: TGridView Horrors
Date: 25 Jan 93 20:48:00 GMT
Organization: AppleLink Gateway

Bill:
 
You may have seen "Managing Named-object Lists" by G. Gordon Apple in the
January 1993 issue of FrameWorks.
 
Steve Mann
From: D4887@AppleLink.Apple.COM (Advanced Comm Eng, G G Apple,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Flame of the Week
Date: 25 Jan 93 20:23:00 GMT
Organization: AppleLink Gateway


 
----------------------------------------------------------------------------
>"Macintosh" should be retained in the name
>and the emphasis continue to be on the Macintosh platform.
 
    I would think that this would depend on how much future the Macintosh has.
IMHO, the Macintosh is nearing the end of it product life-cycle (remember
"Apple II Forever"?).  I for one am looking forward to migrating ASAP to a
PowerPC running Pink.  My impression is that the plan is to convert the entire
Macintosh line to PowerPC hardware within about two years.  Maybe it will still
be called a "Macintosh" and can run existing Mac software through emulation
and/or native primary toolbox calls.  But I assume it will also run Pink.
Given the choice of using the existing (and increasingly) kludgey toolbox calls
vs working with a truly OOP, truly multitasking, protected mode operating
system, which would you choose?
 
    My point is that the name "Macintosh" may or may not relevant within the
near future.
 
G. Gordon Apple   D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA
 
 
 
Newsgroups: comp.sys.mac.oop.macapp3
From: Reid Ellis <rae@Alias.com>
Subject: Re: Defections from BedRock?
Organization: Alias Research, Inc., Toronto ON Canada
Date: Thu, 21 Jan 1993 15:39:39 GMT

Kent Sandvik <ksand@apple.com> writes:
|[templates] are nice, and exception handling is nice, but when push
|comes to show you could write a really nice application and if the
|application fills a niche, and is a user-experience wonder, it will
|sell, regardless of templates and exception handling.

Christopher Russo <chris_russo@gateway.qm.apple.com> writes:
|I think that we'd all agree that people will find a way to make great
|products no matter what tools they're given.  Further, I'm quite sure
|that you could cut down a large redwood with a butter knife.  Hand me
|the chainsaw tho, would ya?  Certainly you're not suggesting that we
|should have our hands tied so that we can write better software.

I'd like to second Chris' point.  Exception handling is especially
useful in C++ constructors.  Rather than having separate methods to do
the real initialization [since constructors can't fail and don't
return error codes] you could simply do all the real work in the
constructor, sending an exception if something goes wrong.

Templates I can live without [macros will do for now] but exceptions
would really make my coding life easier.

Maybe this should be moved to a non-macapp group?

Reid
--
Reid Ellis                                            
rae@utcs.utoronto.ca        ||           rae@Alias.com
CDA0610@applelink.apple.com ||  +1 416 362 9181 [work]
From: ALANDAIL@AppleLink.Apple.COM (Personal Software, Alan Dail,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Re2: C++ (was re: bedrock
Date: 28 Jan 93 16:43:00 GMT
Organization: AppleLink Gateway

Mark,
 
>>I agree that stack-based objects are usefull. However, I don't think they are
>>quite the same thing as a class and could be restricted to structs.
 
>Heh, never tried resource acquisition? If MacApp had real exception handling
>you'd see a LOT of stack-based classes for that purpose.
 
I think you missed my point about stack based objects.  (Perhapse "restricting
class based objects to structs" went to far.  I was suggesting that there is a
difference between a new "type" and a new "class".  (I am defining a type as
something that is designed to have no virtual methods.)  In general, objects
that are designed to be stack based are really new types (i.e. CStr255), which
struct handles nicely.  A class, on the other hand, should have most, if not
all, of it's non private methods virtual.  However, in c++, EVERYTHING defaults
to nonvirtual.  This give a bias for methods to be nonvirtual until a reason
(performance) is discovered for them to be virtual.  The bias should be for
methods to be virtual.  Even better would be to have this issue resolved by the
linker like Object Pascal does, or the environment.
 
>Or use an intelligent DevEnv like Component Workshop.
I thought that Component Workshop also requires you to specify a method to be
virtual.  Also, Component Workshop isn't really C++.  What do you if you want
to port any of your Component Workshop code to Window or Unix, or Pink?  Not to
put down component workshop, but one of the attactions C++ has is that you know
that you can find at least one C++ compiler on pretty much any system you want
to port any of your code to.
 
>>I don't think any of these changes would this would impact the power of C++,
>>but would make it less error prone and easier to learn.
>How do stack-based objects make C++ harder to learn?
 
The fact that they cause nonvirtual to be the default for class makes the
language more error prone.  Also, I was referring to all of the possibble
language changes I mentioned when I made this statement.
 
Alan
 
PS  It's too late to complain about these problems with C++ anyway.  Changing
them would break too much code.  I just hope the designer of the next language
that gains wide spread acceptance realises that programmer productivity can be
improved more by having the compiler catch mistakes for you than by always
striving to reduce the number of characters you have to type.
From: ALGER@AppleLink.Apple.COM (Alger, Jeff,VCA)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re3: C++ (was re: bedrock defe
Date: 27 Jan 93 19:03:00 GMT
Organization: AppleLink Gateway

Alan et al,
 
Let's not forget in this trashing of C++ that there are some very good features
of the language that simply aren't used very much, the idioms Larry spoke of
(and I STRONGLY recommend that people attend his talk at MADACON).  As just one
of many examples, consider possibilities for smart pointers.
 
class foo {...};
class PFoo {
private:
    foo* fFoo;
public:
// various constructors, operator=, etc.
    foo* operator-> (void) { return fFoo; }
};
 
Now one can use a PFoo as a direct replacement for a foo* in almost every
circumstance.  It is the same four bytes and operator->, being inline, is the
same overhead as using a foo* directly.  What's the big deal?  Suppose, perhaps
only with a compile-time debug switch on, we make operator-> and other methods
a little more sophisticated:
 
1. Check to make sure fFoo is non-nil.  This traps nil pointers very
efficiently.
2. As suggested in my Frameworks article, keep a reference count in each foo,
counting how many PFoos there are out there.  Now, in foo's destructor make
sure the reference count is zero and raise an exception otherwise.  This traps
dangling pointers.
3. For that matter, when the reference count goes to zero put the foo into a
list of objects that should have been deleted and weren't, thereby trapping
memory leaks.
 
These are just a few of the things that one can do in C++ that have no
convenient counterpart in Pascal or most other efficiently compiled languages.
And if there is a performance concern, it is very easy to bracket them with
conditional compilation switches.  I am not really an apologist for C++ (I'll
pay the price for an OODL any day), but it continues to be the butt of a lot of
undeserved criticism.  Used wisely, I think C++ is actually one of the best
platforms for building robust code that still runs fast.
 
Regards,
Jeff Alger
SBM International
From: D4161@AppleLink.Apple.COM (Adept, John DiBiasi,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: How can I detect overlappi
Date: 26 Jan 93 12:16:00 GMT
Organization: AppleLink Gateway

>[1] MacApp makes it possible to change from the program
>    the relative position of a view from its superView using?
 
>[2] Can I detect from my program if two views are just about to start
>    overlapping (they share an edge or a corner)?
 
(1) Use the Locate() Method.
 
(2) Depending upon the characteristics of what you're displaying, check out the
Quickdraw SectRect and SectRgn calls which identify if there is an intersection
between two rectangles or regions.
From: B.HABLUTZEL@AppleLink.Apple.COM (Hablutzel, Bob,CST)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: TPicture, no mPictureHit?
Date: 22 Jan 93 14:40:00 GMT
Organization: AppleLink Gateway

Jeff -
 
  Make sure that you have enabled the picture. By default, Ad Lib creates
pictures in a disabled state.
 
Bob
 
 
Bob Hablutzel
Hablutzel Consulting
ALink: B.HABLUTZEL
Phone: 708 328 0130
From: sw@network-analysis-ltd.co.uk (Sak Wathanasin)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: MacApp makefiles and OtherRsrcFiles
Date: 23 Jan 93 10:28:09 GMT
Reply-To: sw@network-analysis-ltd.co.uk
Organization: Network Analysis Ltd
X-Mailer: uAccess - Macintosh Release: 1.6v1


In article <marshall-200193124922@hpsdr160.sdd.hp.com> (comp.sys.mac.oop.macapp3), marshall@sdd.hp.com (Marshall Clow) writes:

> I also had this problem, and this is my "solution". I was building an
> app called "XXY", and my resource file was named "XXY.rsrc". Every time
> I did a complete build (from scratch) as well as every now and then
> (i.e, no apparent pattern), my XXY.rsrc file became 0 bytes long. I changed
> it's name to "XXY Views.rsrc", changed the makefile, and I have had no
> further problems (so far).
> 
> What I suspect is that somewhere, MABuild is making a temp file named
> "{AppName}.rsrc".

MABuild has a default rule that "knows" how to create an .rsrc file from
a .r file. It has another built in rule that automatically includes
a "{AppName}.r" in a build. Unfortunately, most people have an {AppName}.r
file, and when it gets Rez'ed, it creates an "{AppName}.rsrc" unless you've
overridden the default rule in your Makefile.

Renaming either the .r or .rsrc file so that they have different roots should
do the trick; I'd imagine the latter is more convenient for most.


Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

uucp:      ...!uknet!nan!sw  Phone: (+44) 203 419996
AppleLink: NAN.LTD           Internet: sw@network-analysis-ltd.co.uk
From: lasleyse@wam.umd.edu (Scott E. Lasley)
Subject: Re: "MABuild -autobuild" with C/C++
Organization: University of Maryland, College Park
Date: Thu, 28 Jan 1993 17:08:10 GMT

In article <C1JIED.9Gy@netnews.jhuapl.edu> wgi@aplcomm.jhuapl.edu (W. G. Innanen) writes:
>
>Thanks to Scott Lasley <lasleyse@wam.umd.edu> I have my answer.  It's 
>all covered in the dts/mac/tools/macapp-3-0-1-bug-doc.hqx file at 
>ftp.apple.com.  The bottom line is that some MAMake files have to 
>be modified.  The above file gives all the details.
>

The real thanks should go to the peple who put the bug list together
(DSG?) and to Mark Johnson (sp?) who put it at ftp.apple.com where
people who do not have applelink access can get the file.

Scott   lasleyse@wam.umd.edu
"...and there were bumper stickers saying "Free Love" like
it was some kind of political prisoner..."  David Wilcox
From: GILLAM.R@AppleLink.Apple.COM (Richard Gillam,GEIS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Re MacApp Class/Method Ref
Date: 25 Jan 93 16:55:00 GMT
Organization: AppleLink Gateway

I'll second what Dave said.  We got paper documentation to everything else
included in ETO, evn if we didn't get all of it in a timely manner.  When
MacApp 3 came out on ETO, we got complete PAPER copies of all the documentation
for it that was available at that time.  I think everyone would concede that
the tutorial and the Programmer's Guide are NOT complete and by themselves
don't come anywhere near close to providing us with the information we need to
program with MacApp.  The 411 documentation is okay, but it's hard to use, and
it's not paper.
 
I think all ETO subscribers should get the MacApp Reference, and I think that
should be made retroactive to whenever it was actually released (rather than
just to current ETO subscribers).
 
Rich Gillam
(my opinions, not those of)
GE Information Services
From: ICE0003@AppleLink.Apple.COM (ICEC Remote Design Hf,Reykjavik,IVC)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Bug in AdLib handlers
Date: 28 Jan 93 09:15:00 GMT
Organization: AppleLink Gateway

When you create handler that sends menu command to window with given id
the window won't get the menu command because of bug in UHandlerBehavior.cp.
 
The bug is in the method TEventHandler* THandlerBehavior::getTarget(void* data)
in the section "case kWindowIDTarget:" in line
if (window && window->IsShown() &&
    window->fIdentifier == ((handlerData*)   data)->targetParam2)
                                                    ^^^^^^^^^^^^
this should by targetParam1 that is
    window->fIdentifier == ((handlerData*)   data)->targetParam1)
 
Viktor.