HDTenEightyP/NetNews huggingface dataset:
From: DIGIMATCH@AppleLink.Apple.COM (3M, Ran Bedekar,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Segment woes
Date: 26 Jan 93 15:16:00 GMT
Organization: AppleLink Gateway

Mike,
 
I took a look at one of my applications and discovered that when built in debug
mode the %_MethTables segment is about 33K (using -model near).  I haven't
experienced any problems building or running my app.  Have I somehow been lucky
and not needed the stuff beyond 32K, or is this not really a problem?
 
Thanks,
Nick Nallick
 
P.S.  When I built my program using -model far it crashed immediately.
 
----------------------------------------------------------------------------
It could be that the segment that contains all the PascalObject method
dispatching info (the %_MethTables segment) has grown beyond 32K.  You might
check your last successful build with ResEdit to see if this segment is almost
32K.  If this is the case, you probably have no choice but to turn on Model
Far.
From: bowman@reed.edu (BoBolicious)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: C++ (was re: bedrock defection
Date: 24 Jan 93 22:19:20 GMT
Article-I.D.: reed.1993Jan24.221920.13361
Organization: Reed College, Portland, OR

In article <727841301.8123714@AppleLink.Apple.COM> ALANDAIL@AppleLink.Apple.COM (Personal Software, Alan Dail,PRT) writes:
>I would tend to disagree.  C and C++ both allow so many things to compile that
>could easily be typos but cause the program to do the wrong thing (I do admit
>that C++ is better than C).  For example, anywhere you can use a ==, you can
>also use = (and vice versa) and have the program compile fine (due to the
>definition of the language), but get different results.  Your program will not
>only compile, but may even work fine in some instances.  It doesn't even stand
>out when you are looking over your code.  This error would be cought in Pascal
>(or even in Pascal '9x), but not in C or C++.

MPW C++ will warn you if you use a "=" inside an if.  The biggest problem
I had switching from C to C++ was that I didn't pay enough attention to
the warnings that CFront emits.  My C code was so "warning-laden" that I
tended to just ignore them, but CFront can be quite helpful.  It could be
better, though, I admit.

>There are other many other problems like this that are part of the language and
>not due to the compiler.  This doesn't even address the other language problems
>like having various features clash when used together or having the wrong
>defaults when using features (why isn't virtual the default?).  It's a shame
>that Apple doesn't appear to be doing anything with Pascal '9x which appears to
>give programmers the power of C++ without nearly as many pitfalls.

Do you have any more examples?  I've found C++ to be an ideal mix of flexible
elegance & stiff type-checking.  The biggest gotcha for me is usually a bad
typecast, which if I understand correctly, Pascal allows as well.  Properly
written C++ code can pretty stable; it took many shots-to-the-foot, for
instance, before I was fully convinced that initializing everything to nil
and then checking everything before using it is truly The Way (tm).

cheers,
bobo              In seeking the unattainable,
bowman@reed.edu            simplicity only gets in the way.
Best personal ad ever:
"Functionally dysfunctional bi-polar former pop-star geek with Valium habit
seeks anorexic queen of darkness for co-dependency.  Hobbies include: passing
out, slurred speech, blurred vision and reliving past glory."
_Willamette Week_, 1/7-13/93
From: SW0169@AppleLink.Apple.COM (Cross Software,Helsingborg,SE,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MPWProjector - wish list
Date: 26 Jan 93 16:04:00 GMT
Organization: AppleLink Gateway

Dear MPW Shell development team,
 
I'm "living" with the MPW's Projector feature day 'n' night, and I think that
it's great. However, there are one *very* irritating thing about the CheckIn
and CheckOut windows: the lists are not wide enough. How about making the
window resizeable/zoom to be able to provide a wider list?
 
This irritation accelerates in larger projects (which MPW's Projector feature
is probably designed for) when the units' names gets longer and longer (and
don't tell me to use shorter names). It would have been OK even without a
resizeable window if only I could re-design the CheckIn and CheckOut DITL/DLOG
resources myself with ResEdit -- the trouble is that there aren't any resorces
for these two views!
 
Wouldn't this be something to improve on?
 
Sincerely,
 
Bo "Details, Details, Details" Klintberg
CROSS Software AB
From: KNUPPEL.M@AppleLink.Apple.COM (Mike Knuppel,GEIS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: TPicture, no mPictureHit?
Date: 22 Jan 93 14:50:00 GMT
Organization: AppleLink Gateway

Jeff,
 
I had the same problem. It took forever to find the solution.
 
Here is what I did to fix it. Select the control (TPicture), in AD Lib, and
then go into the class hierarchy. Go into the TControl and check the default
choice. The value in here should correspond to the value of mPictureHit (see
UMacAppGlobals.h). My default choice was set to zero so I never received the
mPictureHit. Being a picture type, I also was receiving the mTurnOn and
mTurnOff events.
 
Hope this helps..
 
Mike K.
From: tal691@huxley.anu.edu.au (Tonio Loewald)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Flame of the Week
Date: 26 Jan 93 11:19:43 GMT
Organization: Australian National University
NNTP-Posting-Host: 150.203.2.12


It would be nice to think, one day, that the Mac community could
be secure enough to allow a Mac entity to become a general entity
without fearing that it would cease to have allegiance to the 
Mac. I guess that we'll have to wait until a phrase like "for
the Macintosh and the personal computer" (I could be misquoting
slightly a recent press release concerning easy open) would be
openly laughed at by everybody.

Tonio "doesn't read BYTE since it endorsed Bush/Quayle" Loewald

-- 
Tonio Loewald | tal691@huxley.anu.edu.au

"Yes!! For the hundred and fiftieth time!
 We're burning in hell!!!" (John Callahan)
Newsgroups: comp.sys.mac.oop.macapp3
From: Adrian C Ruigrok <aruigrok@bnr.ca>
Subject: Printing views that are not shown, revisitted
X-Xxdate: Wed, 27 Jan 93 14:21:53 GMT
Organization: Bell-Northern Research
X-Useragent: Nuntius v1.1.1d12
Date: Wed, 27 Jan 1993 19:16:44 GMT

A couple months ago there was some discussion about the ongoing problem
of printing views that do not
have a visual representation.  MacApp handles printing views that you
have rendered on the screen
but there is no clear way to print stuff that is not shown.  

Did anything ever come of all this discussion.  The last thing I saw was
a request from Jeff Alger 
that we get a response from Apple on how this should be done.  Then
silence!

Could someone send me the state of the art solution to this problem.

Thanks,
Adrian
------------------------------------
Adrian C Ruigrok                 Bell-Northern Research
aruigrok@bnr.ca                  Ottawa, Ontario, Canada
From: D3085@AppleLink.Apple.COM (Progressive Computing, D Lucky,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: C++ (was re: bedrock defec
Date: 24 Jan 93 03:04:00 GMT
Organization: AppleLink Gateway

Alan,
 
I'll play devil's advocate because C++ isn't my favorite language either.
However, are these that folks find wrong with C++ only wrong from an MPW Pascal
perspective (e.g., virtual)?  I'm not trying to upset anyone but maybe things
in C++ make sense from a C++ standpoint.  I also think, however, that I would
like to see some additional capabilities in the C++ language specifications
such as run-time type identification.  I hear that this has been considered by
the ANSI committee but don't know what decision they have made about it.  As
far the MPW C++ implementation, I'd like to see exception handling and
templates.
 
Regards,
 
Dave Lucky
Progressive Computing, Inc.
 
Newsgroups: comp.sys.mac.oop.macapp3
From: squeegee@world.std.com (Stephen C. Gilardi)
Subject: Re: MacApp Class/Method Ref
Organization: SQ Software via The World Public Access UNIX, Brookline, MA
Date: Tue, 26 Jan 1993 00:19:13 GMT

That's completely bogus.  Ship the paper.  I cannot see any
justification at all for not doing it.

Aargh!

--Steve

Stephen C. Gilardi
SQ Software
squeegee@world.std.com
From: DAVEG@APPLE.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MethTables segment
Date: 27 Jan 93 00:52:00 GMT
Organization: AppleLink Gateway

From: Dave Green <daveg@apple.com>
To: MACAPP3TECH$@AppleLink.Apple.COM
 
I appreciated your Linker trivia.  and wanted to bounce something off of
you.
 
The %_Methtables segment contains the dispatching information only for
functions which use PASCAL calling conventions, correct?
 
So, could one take an application which was into the model -far case
and bring it back under the limits by making non-macapp methods of
the hierarchy use C++ calling conventions?
 
Even if the above paragraph is technically correct, is there some
reason other than support for object pascal to avoid this strategy?
 
I have an application that overextended the bounds recently and
still has a ways to go in development.  If I can get it to compile without
using modelf -far at ship time, it would be excellent (bettter performance).
 
one last question:
In segmenting an application (black magic), it would be useful if there
were a spell for detecting cross segment function calls.  Can anyone
offer a suggestion on how to illumate these?  (incantations, runes to be
etched on nearby surfaces... etc.)
 
hoping to tune up my hoggish application,
Dave
From: SIGMUND@NORA.HD.UIB.NO
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: TPicture, no mPictureHit?
Date: 22 Jan 93 10:44:00 GMT
Organization: AppleLink Gateway

From: sigmund@nora.hd.uib.no
To: MACAPP3TECH$@applelink.apple.com
Cc: koppi@aplcenmp.apl.jhu.edu
 
Jeff,
 
Perhaps fEnabled is FALSE?
 
        Sigmund Tveit
        Humanistisk Datasenter
        Norway
From: jwo@gallant.apple.com (Jamie Osborne)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: MacApp makefiles and OtherRsrcFiles
Date: 21 Jan 93 18:10:55 GMT
Reply-To: jwo@apple.com
Organization: Apple Computer, Inc.

marshall@sdd.hp.com (Marshall Clow) writes:
I Had the same problems described below.  I had a file named XYZ.r and
a file named XYZ.rsrc.  The two contained completely different stuff.
Every once in a while everything in my XYZ.rsrc file would disappear.
I discovered that when MABuild was rezzing my XYZ.r file, it rezzed it
into a file called XYZ.rsrc, overwriting the resources I already had
in that file.  It then deleted the rezzed resources, leaving me with
an empty XYZ.rsrc file and a headache.

My solution was to give my XYZ.rsrc file a different name.

-J


>In article <1993Jan20.202603.1138@udel.edu>, gray@tinman.asel.udel.edu
>(John Gray) wrote:
>> 
>> Hello fellow netters:
>> 
>> MacApp makefiles have a variable in them called OtherRsrcFiles which 
>> I understand is to list other Resource files that the app needs.
>> So I thought the rsrc file created by ViewEdit would be an example of
>> a file that should be listed there (ObjectMaster seems to think so too 
>> because it lists the ViewEdit file under the variable when I have it 
>> generate a makefile as well).  At any rate with the ViewEdit file 
>> listed there, when the make gets to point of rezzing the thing it 
>> seems truncate the ViewEdit file to zero bytes (good thing I am 
>> religious about backups).  Anybody know whats going on here.  It 
>> doesn't seem to do it all the time, but very often.
>> 

>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".

>Of course, I could be just blowing smoke, and my success could just be
>apparent. I don't know that this is true, I've just not had the time to
>go and check what MABuild is doing. So far, however, it's worked for me.

>Marshall Clow
>San Diego Printer Division      Hewlett Packard
>Internet: marshall@sdd.hp.com   AppleLink: HP.Marshall    AOL: MClow
From: SW0169@AppleLink.Apple.COM (Cross Software,Helsingborg,SE,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Maybe a MA3 bug?
Date: 27 Jan 93 01:20:00 GMT
Organization: AppleLink Gateway

MacAppers,
 
If someone would be interested (who knows in these Bedrockish times) I think
there's a slight bug in the MA 3.0.1 class TFilesCommand. This bug is not
actually doing any harm, what *I* can see, but...
 
It goes like this:
 
    The TFilesCommand::IFilesCommand() calls IAppleCommand() directly and NOT
the TServerCommand::IServerCommand(). This seems to work anyway, cause
::IServerCommand() just calls ::IAppleCommand() anyway. BUT, if anyone changes
IServerCommand, then what happens? :-).
 
Bo Klintberg
Cross Software AB.
 
Newsgroups: comp.sys.mac.oop.macapp3
From: johore@teal.csn.org (John Orendt)
Subject:  Denver: MacApp tutoring needed!
Organization: Colorado SuperNet, Inc.
X-Newsreader: Tin 1.1 PL4
Date: Mon, 25 Jan 1993 07:35:20 GMT

Hi 
 
My name is John Orendt.
 
I need a tutor to help me learn MacApp using C++.
 
I have an excellent knowledge of C++, FORTRAN, MPW and a
little experience in Pascal.
 
Tutoring can be in person via telephone or via e-mail.
 
There must be a cheaper way to learn MacApp other than going
to Cupertino California and taking a course from Apple.
 
Hopefully we can come to a mutually benificial relationship.


-- 

  JOHN ORENDT         johore@csn.org               .-~~~-,
  O                                               (       )
  H                                              (         )
From: D4887@AppleLink.Apple.COM (Advanced Comm Eng, G G Apple,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: RE: Flame of the Week
Date: 28 Jan 93 20:36:00 GMT
Organization: AppleLink Gateway


 
----------------------------------------------------------------------------
>Why would "focusing" on the Macintosh have anything to do with the IRS not
>recognizing MADA as a nonprofit organization?  I don't get it?
 
   You can't fight city hall or the IRS.  The problem is that nonprofit
tax-exempt organizations can not be "company" specific.  I believe that BMUG
went through the same process.  Our South Bay Mac Group is now SBMUG ("South
Bay" refers to Santa Monica Bay and anything south of LAX down to San Pedro,
not the SF Bay "South Bay"), and recently received tax exempt status.
 
G. Gordon Apple  D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA
From: ALANDAIL@AppleLink.Apple.COM (Personal Software, Alan Dail,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: C++ (was re: bedrock defe
Date: 25 Jan 93 15:22:00 GMT
Organization: AppleLink Gateway

>MPW C++ will warn you if you use a "=" inside an if.
I was unaware of this warning.  Is this a warning that is defined by C++
(meaning all valid C++ compilers will generate it), or something that is added
to the MPW compiler (or CFront) to alert you of a condition that is valid in
C++, but may cause trouble.  If this is part of the language, then it is a
little better than I thought.
 
>The biggest problem I had switching from C to C++ was that I didn't pay enough
>attention to the warnings that CFront emits.  My C code was so "warning-laden"
>that I tended to just ignore them, but CFront can be quite helpful.  It could
>be better, though, I admit.
 
The C++ wanrning system has at least 2 problems:
    So many meaningless warnings are generated, it is easy to be lulled into
ignoring them all together (until something goes wrong).
    Some of the conditions that are warning should really be errors.  For
example, the warning "temporary used for non-const xxxxx & argument".  This
tells you that your method is being called, but the results are being
discarded.   I can't imagine why this would be allowed.
 
I still feel that C++ is more complex than it needs to be.  (Perhaps this is
due to it's roots in C.)  I believe that as our hardware gets more powerful,
our tools should be getting more elegant, not more complex.  Compare SmallTalk
to C++.
 
Alan
From: ALANDAIL@AppleLink.Apple.COM (Personal Software, Alan Dail,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: C++ (was re: bedrock defe
Date: 27 Jan 93 15:54:00 GMT
Organization: AppleLink Gateway

Larry,
 
>You're right about this, and I haven't considered these issues.  The == vs.
>= problem is a flaw that C++ inherits from C.  The same is true of switch
>statements (where leaving out the break in each case is usually a mistake).
 
There are other examples that cannot be blamed on C.  One is the lack of a key
word when overriding or overloading a method.  This would give a safty check
that you havn't made a mistake in your method name.
 
Another example is the lack of the key word inherited.  This allows your code
to automatically adapt as your superclasses evolve.  As it stands now, if you
insert an override, it may never get invoked and you will not get any kind of
indication from the compiler.  Fortuanatly, C++ allows you to write
superclassname::methodname() to get the effect of inherited.  However, even
then, if you change your superclass, you will have trouble.  In any other OO
language I'm aware of, you would have used either inherited or super originally
and never run into a problem.
 
>> like having various features clash when used together or having the wrong
>I think there's a tradeoff here.  You could remove lots of features from
>the language, but then there would be useful things that you couldn't do.
 
You wouldn't have to remove features, just design them to coexist better.  For
example, if you overload a function and then override one instance of it, all
of the other instances get hidden.  Why not allow these featues to coexist
instead of conflict.
 
>> defaults when using features (why isn't virtual the default?).  It's a shame
>C++ was designed for maximum performance.
 
Changing the default would improve reliability without having to impact
performance.  All a programmer would have to do to get the performance would be
to explicitly declare critical methods as nonvirtual.
 
>For example, removing stack-based objects would simplify things
>considerably, but stack-based objects are useful in many places.
 
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.  Doing this
would allow class to be changed to have virtual for its default (or even
better, have no default).
 
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.
 
Alan
From: davidp@stealth.usc.edu (David Peterson)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: MPWProjector - wish list
Date: 28 Jan 1993 11:18:49 -0800
Organization: University of Southern California, Los Angeles, CA
Distribution: world
Reply-To: davidp@usc.edu
NNTP-Posting-Host: stealth.usc.edu


There is also a bug (or hidden feature depending on how you look at it)
in Projector:

If you try to check out modifiable source copies, it grays out those
items in the list that are already checked out modifiable. However if
you click the "Read Only" option, select some source you already have
checked out, then hit the "Modifiable" option, your selection stays, and
you can check out a modifiable copy of the last check-in over the top
of the current modifiable copy.

Not sure if I'd actually fix it though -- Its gotten me out of a couple
of jams.

Just thought others might want to know about it...

-dave.
From: SHIGEYA@FORETUNE.CO.JP
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Is the _MacApp_Class_&_Met
Date: 21 Jan 93 15:04:00 GMT
Organization: AppleLink Gateway

From: Shigeya Suzuki <shigeya@foretune.co.jp>
Subject: Re: Is the _MacApp_Class_&_Met
To: HARRIS.BILL@AppleLink.Apple.COM (Harris,  Bill)
Cc: MACAPP3TECH$@AppleLink.Apple.COM (MacApp 3 Technical Discussion),
     shigeya@foretune.co.jp
 
>>>>> On 21 Jan 93 02:27 GMT, HARRIS.BILL@AppleLink.Apple.COM (Harris, Bill)
said:
 
Harris> The MacApp Class and Method Reference is now available from
Harris> APDA. Thanks for your patience on this one.
 
Great!
 
Will we receive the Reference in ETO 10?
 
shigeya
From: JWBAXTER@HALCYON.HALCYON.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: MacApp Castaways & Prograp
Date: 23 Jan 93 08:26:00 GMT
Organization: AppleLink Gateway

From: jwbaxter@halcyon.halcyon.com
Subject: Re: MacApp Castaways & Prograph
To: MACAPP3TECH$@applelink.apple.com
Cc: szpak@fox.nstn.ns.ca
 
All, and Mark:
   I believe that Prograph deserves a serious look from those who are
feeling abandoned by MacApp/Bedrock/etc.  Or just by those who want another
arrow in their development quiver.
 
   This comment shouldn't surprise those of you who recall my two
FrameWorks articles last year on Prograph.  There are many good things
about Prograph.  I still have concerns about how effectively a team can
write a LARGE application in Prograph.  [But then, MacApp doesn't
completely solve that one, either.]
 
   --John
 
--------------
John W. Baxter   jwbaxter@halcyon.com   [BAXTER.JOHN on AppleLink, from
AppleLink only.]
From: THIERRY@ATHENS.ESF.DE
Newsgroups: comp.sys.mac.oop.macapp3
Subject: (none)
Date: 28 Jan 93 17:24:00 GMT
Organization: AppleLink Gateway

From: thierry@athens.esf.de
Reply-To: thierry@esf.de
To: macapp3tech$@applelink.apple.com
 
 
 
        Please add me to your mailing list.
 
 
   Thierry Cruanes
 
--------------------------------------------------------------
ESF Headquarters                    Tel : ++49+30-820 903 23
Hohenzollerndamm 152                Fax : ++49+30-820 903 19
1000 Berlin 33                      Internet :thierry@esf.de
Germany
From: ALANDAIL@AppleLink.Apple.COM (Personal Software, Alan Dail,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: When no printer is selecte
Date: 26 Jan 93 20:53:00 GMT
Organization: AppleLink Gateway

Jim,
 
I check for a chosen printer with the following code:
 
    PrOpen();
    OSErr error = PrError();
    PrClose();
 
If no printer is chosed, PrOpen generates an error.
 
Alan
From: D4444@AppleLink.Apple.COM (Acius, Cupertino,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Job Opportunity
Date: 22 Jan 93 22:36:00 GMT
Organization: AppleLink Gateway

ACI is an international software publisher dedicated to producing leading-edge
software products such as Object Master,  our advanced source code management
system, and 4th Dimension, the best selling relational database for the
Macintosh.
 
ACI currently has openings for the following positions in its Cupertino, CA
office:
 
 
Software Engineer
 
We are looking for an experienced software Engineer to support the development
of future versions of Object Master. Knowledge of Macintosh development tools
including MPW Pascal and C/C++ required. Knowledge of object oriented
techniques is a plus. This position will also involve some public presentations
of the product to technical audiences.
 
Product Marketing
 
If you are a product marketing expert looking to manage all aspects of a
sophisticated software product, this position is for you. You will be
responsible for all aspects of marketing for Object Master, including
advertising, promotions, channel development, public relations, etc. Strong
product marketing skills required. A technical understanding of and/or prior
experience marketing software development tools a plus.
 
Send your resume to:
 
ACI US
Human Resources
10351 Bubb Road
Cupertino, CA 95014
 
Fax (408) 252-0831
AppleLink D4444
 
We are an equal opportunity employer.
 
Newsgroups: comp.sys.mac.oop.macapp3