HDTenEightyP/NetNews huggingface dataset:
From: SDOBBS@TRIVIA.COGINST.UWF.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Drawing
Date: 11 Jan 93 21:59:00 GMT
Organization: AppleLink Gateway

Hello,
        I am having a problem drawing.  I have subclasses TEditText and
(attempted) to make it moveable.  I have implemented a TTracker in the
DoMouseCommand of the TEditText.  In the DoIt method of the TTracker I
modify the fLocation of the TEditext, and then try various things to try
and get the TEditText to be drawn in the new location, but none of them
work.  Can anyone give me any suggestions?
 
Steven Dobbs <sdobbs@ai.uwf.edu>
Institute For Human and Machine Cognition
University of West Florida
Pensacola, Florida
 
Man will occasionally stumble upon the truth, but most of the
time he will pick himself up and continue on.
From: KENTON@AppleLink.Apple.COM (Hanson, Kenton)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Draw (double)????
Date: 9 Jan 93 01:49:00 GMT
Organization: AppleLink Gateway

Bill,
 
    Regarding the formatting of double in MacApp, look at subroutine
 pascal void TCell::ValueToString()
in file "MacApp:Examples:CPlusExamples:Calc:UCalcCells.cp"
 
also look at the SANE.h file for the interface to
   num2dec(theFormat, aValueType, aDecimal);
   dec2str(theFormat, aDecimal, aCString);
 
Further explanations of these routines can be found in the Apple Sane Manual
2nd edition
 
Hope this helps,
 
Kenton Hanson
Apple Numerics Group
From: MARX.PETER@AppleLink.Apple.COM (Marx, Peter,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: more ETO griping...
Date: 11 Jan 93 06:56:00 GMT
Organization: AppleLink Gateway

Folks,
 
Perhaps my last general note about ETO was too strong. The first number of
issues were great, even if they were sometimes late. It is very useful to me to
have the entire development suite easily available in a single location.
 
I just wonder why Apple doesn't put EVERYTHING into a subscription service
(e.g. a high-end Partner program) and COMMIT to making everything available
there. I don't understand why Apple doesn't see this in their interest. To make
themselves dependent upon third parties for the development tools is rather
foolish in my opinion. Why did they do MacApp to begin with?!
 
Peter Marx
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Takeover - QA
Date: 4 Jan 93 21:40:00 GMT
Organization: AppleLink Gateway

Jesse --
 
I appreciate your points, and agree with your general approach toward QA.
However, I am trying to address some very specific issues with current MacApp
maintenance, faced as we are with the existing situation of many shipping or
soon-to-be-shipping apps and very minimal ongoing Apple support.
 
> You discuss a bug-fix and use phrases like "guaranteed" and "cannot possibly
> cause..." Don't tempt fate.
 
Ah, but to refrain from tempting fate is to refrain from living life itself!
<end of poetical interlude>
 
> Without discussing this particular bug,...
 
This is a specific example. Discussing this particular bug is precisely the
point.
 
> E.g., pushing the size of a code segment up by a few bytes - just enough
> to cause overflows in an application that links user code into that segment.
 
This would happen to the hapless user even after Apple did eight person-weeks
of MacApp QA testing. This is not a QA problem.
 
> We apply bug fixes if we need them (and we usually can do them in subclasses
> of our own)
 
As long as you can do them in subclasses you are reasonably safe. Some do
require modifying the source code, though. (E.g., they affect global
procedures.) In those cases, you have to reapply each fix each time you load an
updated officially-sanctioned release of MacApp. If Apple can put out the fix
in its official Bug Doc, why can't it apply the fixes itself?
 
And if the answer to that is that Apple won't apply the fix until it can do its
eight person-weeks of QA, but Apple _is_ willing to list the fix in its Bug Doc
in the interim, then how dare you apply the bug fix yourself, without your own
eight person-week QA cycle?
 
> "[why do all of these discussions insist that all bug work and QA needs to be
> done in a vacuum???]". The answer is because the greater the degree of
> separation between the coder and the tester, the more likely the
> testing is to be thorough.
 
No, I meant "why do all of these discussions insist that all bug fixes have to
be worked out by Apple (or MADA, or whomever), applied by Apple, tested by
Apple, and officially released by Apple, without recognizing the collective
genius and testing facilities of all the developers on MacAppTech$???"
 
-- Dave
From: GER.XSE0201@AppleLink.Apple.COM (Frank Becker Computertechnik,DE,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Another one! (Part 1)
Date: 6 Jan 93 10:13:00 GMT
Organization: AppleLink Gateway

Dear MacAppers,
 
I think it is a good way to include every bug fix in a conditional compilation
so every one can choose if he/she will use the fixes or not.
What is about 3 of 4 defines like
 
o WellTestedFix
for changes that seem to work fine (this Fix was made three or more releases
before the actual version)
o TestedFix
for changes that seem to work fine (this Fix was made 2 releases before the
actual version)
o NewFix
as the Name show this are fixes which are new in this release, but checked from
someone.
o UncheckedFix
as the Name show this are fixes which are new in this release, but not checked.
 
I use actually only one define, but if we didn't get new releases I use more
defines for my own.
 
Best regards
From: JWBAXTER@HALCYON.HALCYON.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Quality of CW's Class Libr
Date: 9 Jan 93 16:52:00 GMT
Organization: AppleLink Gateway

From: jwbaxter@halcyon.halcyon.com
Subject: Re: Quality of CW's Class Library
To: DRAPER@ODIN.MDA.UTH.TMC.EDU
Cc: MACAPP3TECH$@applelink.apple.com
 
> Does anybody have any comments on the quality of the Component Workshop
>class library?
>
>Is the architecture sound?
Ed,
   In addition to Jeff's and Bob's comments, it's worth noting that
platform-independence is built into the library from the start.  Just as
one example, there's a Picture class.  Which as reasonable behavior.  On
the Mac, when you ask for one of these you get a MacPicture, in which the
reasonable behavior is implemented using a Macintosh picture.  On the
(future) Windows version, the same code would produce a picture thing
suitable for Windows.  As long as you write code for the Picture class,
your code should move unscathed.  Same for Fonts, Icons, Files, etc, etc,
etc.  Clearly, if you write code which "knows" it's dealing with a
Macintosh picture, then your code is "stuck" on the Mac.  That's your
fault, not the framework's.
   Whether this works in practice will be learned later this year.
      --John
 
--------------
John W. Baxter   jwbaxter@halcyon.com   [BAXTER.JOHN on AppleLink, from
AppleLink only.]
From: AVALON@AppleLink.Apple.COM (Avalon Engineering, R Brenner,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: NEMADA-Meet Jeff Alger
Date: 12 Jan 93 15:57:00 GMT
Organization: AppleLink Gateway

Welcome back to NEMADA!
 
Now that we're back from our holiday hiatus, it's time to get things moving in
a big way. You heard it whispered in the hallways... you read about it in the
papers... you saw him pumping gas at the local station... You know who I'm talking
about!...
 
No, it's not Elvis... it's Jeff Alger! (Co-author of "Developing Object-Oriented
Software for the Macintosh -- Analysis, Design, and Programming")
 
On Tuesday, February 2 (the January meeting has a mild case of hyperextension),
he'll be in town to talk about Solution Based Modeling and let us peek into his
crystal ball as he foretells the future of OO development. Stay tuned for
directions, this is one show you don't want to miss!
 
Our meeting coincides with Jeff Alger's New England seminar on SBM. For more
information, you can talk to Tom Cahill at (408) 255-0974.
 
Russ Brenner
Avalon Engineering, Inc.
"Live long in Gloucester"
From: B.HABLUTZEL@AppleLink.Apple.COM (Hablutzel, Bob,CST)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Component Workshop
Date: 8 Jan 93 04:26:00 GMT
Organization: AppleLink Gateway

Chris -
 
  Just to strengthen what Kent said, it is not only 16MB minimum, but 16MB
_real_ RAM. I was running with 8 real/16 virtual at one point, only to get
horrified looks out of the CS people. It did work, sometimes, but it is really,
really not recommended. Also, I am currently running it on an fx, and it is not
too bad. I can't wait for the 950, though.
  Personally, I would say 20MB is really the minimum, just in case you wanted
to run the operating system at the same time...
 
 
Bob
 
 
Bob Hablutzel
Hablutzel Consulting
ALink: B.HABLUTZEL
Phone: 708 328 0130
From: LANGFORD@AppleLink.Apple.COM (Paradigm Publishing, B Langford,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Link Error with RunTime.o
Date: 11 Jan 93 06:08:00 GMT
Organization: AppleLink Gateway

Hi, my name is Jungho.
Thank you for the help on "Errors in Linking" the other day.
 
Now I have another error that I can not understand.
Please, help me.
 
Note: Currently MPW from E.T.O. 9 is employed.
 
This is what happened.
   MABuildTool - v. 3.0.1 Release 6/10/92          Start: 10:38:17 PM 1/10/93
 
   Copyright Apple Computer, Inc. 1986-1992
   All Rights Reserved.
 
   AutoSaving...
   Target Folder: "RAM Disk:Keystone:.S7NmDbDmUnPeRaTeSmfCfD:"
   Making:        Skeleton.MAMake
   Compiling:     MSkeleton.cp
   warning: -d or -u option(s) will not affect code saved in dump file
   Linking:       Skeleton
   ### While reading file "Sun:MPW:Libraries:Libraries:RunTime.o"
   ### Sun:MPW:Tools:Link: Error: PC-relative edit, offset out of range. (Error
48) %__MAIN (260)
     Reference to: main in file: RAM
Disk:Keystone:.S7NmDbDmUnPeRaTeSmfCfD:MSkeleton.cp.o
   ### Sun:MPW:Tools:Link: Error: PC-relative edit, offset out of range. (Error
48) %__MAIN (260)
     Reference to: %__MAIN in file: ### Sun:MPW:Tools:Link: Bad file name or
volume name (perhaps zero-length) (OS error -37)
   ### Sun:MPW:Tools:Link: Error: Resource I/O error, # (Error 6) getting file
modification date.
   ### Sun:MPW:Tools:Link: Errors prevented normal completion.
   ### MPW Shell - Command " " was not found.
   ### MPW Shell - Execution of RAM
Disk:Keystone:.S7NmDbDmUnPeRaTeSmfCfD:Skeleton.MakeIt terminated.
   ### MPW Shell - Execution of MABuild terminated.
 
Thank you.
From: ALGER@AppleLink.Apple.COM (Alger, Jeff,VCA)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Quality of CW's Class Libr
Date: 8 Jan 93 17:52:00 GMT
Organization: AppleLink Gateway

Ed,
 
My assessment of CW's class library would be "shallow with a germ of
greatness."  That is, architecturally it is innovative and very well conceived,
but it remains somewhat feature-poor.  I would much rather have this than the
other way around since it provides a very solid foundation on which to build.
 
An example: "buttonness", if I may coin the term, is an abstract concept
unrelated to the visualization of the "button."  As a result, the same button
class can be used for Control Manager buttons, tool palette buttons, and menu
items, each of which mixes in a different rendering class to go with the
abstract button behavior.  Throughout the architecture is similarly
well-factored.
 
Regards,
Jeff Alger
SBM International
From: wallich@ncd.com (Ken Wallich)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: ETO-expensive,toothless,obsele
Date: 13 Jan 93 02:50:25 GMT
Reply-To: wallich@ncd.com (Ken Wallich)

MARX.PETER@AppleLink.Apple.COM (Marx, Peter,PRT) writes:

>ETO - Expensive, Toothless, and Obselete?

:-)
 
>I would love for
>Symantec and Apple to prove me wrong, but it seems that their attentions are
>being directed at other things (fonts, pc exchange cdevs, etc.)

Well, I'd guess they're intentions are to create a complex (and from
what I hear, prohibitively expensive) development system for the 'new
mac' and assure that there is no competetion.  As it stands now, if I
don't want to use MPW to do "serious" development, I can use the far
less expensive Think C.  I've owned both MPW and Think C for a long
time (although I stopped upgrading them both a while ago).  If
Symantec and Apple co-develop an expensive development environment,
who will author the inexpensive one, Microsoft ;-)?

It's enough to make you wish you'd just supported windows all along.
After all, even though it's a mediocre system, it's always been
mediocre, and always will be.  You know where you stand with them, and
they seem to encourage system development by guys with normal jobs who
like to program in their copius free time.  Ok, so they don't really
have a good object-oriented development environment.  Give 'em a
couple more years.  They'll ship a mediocre one, and marginally
improve it.  You know what to expect, how long it will take, and that
it will be cheap.

Ok, I'll eat my sarcastic hat now...



-- 
Ken Wallich

wallich@ncd.com ~ ken@wallich.com ~ kmw@al.org ~ [...]decwrl!vixie!amber!ken
From: REDDEN@AppleLink.Apple.COM (Redden, Kevin)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Link error
Date: 8 Jan 93 15:34:00 GMT
Organization: AppleLink Gateway

Jungho,
 
>### Sun:MPW:Tools:Make - IO error trying to get file info for "Sun:MacApp
>3.0.1:Libraries:.S7NmDbDmUnPeRaTeSmfCfD:MacApp.lib"
># Directory not found (OS error -120)
>
>etc.
 
The problem with your third trial is probably that you did not use the
-autobuild option to rebuild all of MacApp with -ModelFar on.
 
(Only use this option once and you should probably put in a -e to make sure
everything is rebuilt.)
 
Kevin
From: COMPONENT@AppleLink.Apple.COM (Component Software, S Ballard,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: COMPONENT SOFTWARE intos
Date: 4 Jan 93 19:36:00 GMT
Organization: AppleLink Gateway

Attn:
Attn:
SentBy: Jennifer Johnson
 
Regarding:                    COMPONENT SOFTWARE intos Component Proponent_
Component Software Corporation introduces the
 Component Proponent Program
 
We are looking for a few good Mac programmers to join our new Component
Proponent Program. Use the fastest development environment available to drive
new business for your consulting company and help us create add-on components,
tools, and sample code. We'll even help you sell your Components to other
Component Workshop(tm) developers worldwide so you can earn some money. After
all, your success is our success.
 
Here's how it works. You get
 
o a single-user license for Component Workshop at a greatly reduced price -
$495 (that's 80% off the list price of $2,495) and unlimited access to our
Bulletin Board System for technical tips, threads with other developers and
file-in's for minor bug fixes.
 
o 120 days of FREE maintenance and significant discounts off annual
maintenance contracts, training, add-on products and upgrades. (You need to
build either sample code or a Component for the BBS within 120 days to qualify
for further discounts).
 
o special access to our Bulletin Board for marketing your Components.
 
Component Workshop is the first "OBJECTS ONLY" dynamic development environment
based on C++. We take the definition of object-oriented programming seriously
and deliver maintainable, easily ported, easy to extend applications which are
built out of reusable parts. Incremental compilation, garbage collection, and
an application framwork ensure that you will develop applications faster than
ever before.
 
Component Workshop is based on C++ and uses a subset of the AT&T's 2.1 C++
standard. You may give up some C++ syntax, but you get back your weekends and
will earn a reputation as someone who delivers NEW APPLICATIONS early -
instead of promises for next year.
 
If you'd like to rapidly grow your business and make a little cash building
reusable Components, join us NOW and start using the most talked about new
development environment available. Call us today at 617/862-9700 and say "I
want to be a Component Proponent!" three times fast.
 
Please note:  COMPONENT WORKSHOP requires a Macintosh IIci or better with a
MC68030 or x040 processor running at 33MHz, System 7, a M68881 floating point
coprocessor, at least 25 Mbytes of hard disk space and 16 Mbytes of physical
memory (20 Mbytes are recommended) and MPW C(tm) for development.
 
These prices are valid in the U.S. only and do not include shipping charges.
From: aides@hamlet.umd.edu (Marcus Wilhoit)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Total Chaos
Date: 7 Jan 93 18:47:31 GMT
Organization: University of Maryland, Computer Sci. Center
X-UserAgent: Nuntius v1.1.1d9
X-XXMessage-ID: <A771E56D4502023A@front-office-mac.umd.edu>
X-XXDate: Thu, 7 Jan 93 05:49:33 GMT


What in the World is going on?  It seems to me that Apple will just
become a software
company with the advent of the Power PC.  Nothing makes any sense?  What
will be the
difference between a PowerPC made by IBM as opposed to one made by Apple?
 Multi-
platform should be multi-GUI either windows or MacOS, the platform will
pretty much
be the same (the Power PC).  NeXT and other companies are also looking at
the Power PC chip.  Is everyone going with one really fast platform in
which the will use something like Bedrock for writting applications?

What is the Power PC anyway?  It is supposed to run AIX, Macintosh, AUX,
Power-Open
(AIX union AUX).  Why?  Where does Apple Computer fit in?  The Lawyers
must love
the contract disputes.   Ok, Maybe is not Vaporware?   Hmmmm.

I am a die-hard MAC person and I was thinking about upgrading to 16MB RAM
so I could
take full advantage of MacApp 3.0.  With the death of MacApp 3.0 I think
I will just stick with virtual memory and finish the MacApp Turtorial.

I guess the computer-software industry is going through some type of
transfomation. I may be wrong, but after we make sense of it all a few
companies we know and love now are not going to be here.

The IBM & Apple "Technological Alliance" seems more like a Merger to me
with a trick to keep the government from calling it a Monopoly.

Please someone help me see the light!  If there is one?
From: DRAPER@ODIN.MDA.UTH.TMC.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: more ETO griping...
Date: 11 Jan 93 15:30:00 GMT
Organization: AppleLink Gateway

>To make themselves dependent upon third parties for the development tools is
>rather foolish in my opinion. Why did they do MacApp to begin with?!
 
I couldn't disagree more.  Apple's domination of the development tools
market has seriously hindered the development of new tools by third
parties.  Haven't you ever ask yourself why Borland and Microsoft haven't
entered the Mac development tools market?
 
Here's an excerpt from one of my postings back in September:
 
>Where is the competition?
>WHERE IS THE FREEMARKET?
>Is the current deficiency in Mac programming tools a product of:
>    a) Apple's *over involvement* in development tools?
> Or perhaps:
>    a) Developer over reliance on Apple tools?
 
I think it's as pertinent today as it was back then.  WE NEED CHOICE.  Why
did Apple have to deal with Symantec when it unloaded MacApp?  Was there NO
other developer in the entire world that could do the job?  In my opinion,
there are some really sticky Anti-Trust issues involved with this
Apple/Symantec alliance.
 
I don't mean to imply that Apple NOT be involved in the development tools
market.  But I do think that the main focus of development tools marketing
should be to evangelize third party developers.  Third parties should be
the ones that are "pushing the technology envelope."
 
 
People need to stop complaining about what Apple doesn't do, and simply do
it themselves.
 
 
 
 
      |E|J-  ED DRAPER
 rEpar|D|<-  Radiologic/Pathologic Institute
             The University of Texas M.D. Anderson Cancer Center
             draper@odin.mda.uth.tmc.edu
From: COMPONENT@AppleLink.Apple.COM (Component Software, S Ballard,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Attention MacApp Programm
Date: 4 Jan 93 19:45:00 GMT
Organization: AppleLink Gateway

Attn:
Attn:
Attn:
SentBy: Jennifer Johnson
 
Regarding:                    Attention MacApp Programmers!
ATTENTION MACAPP PROGRAMMERS!
Component Software Corporation wants to convert you.
 
Starting January 1, 1993, until March 31, 1993, we are offering a "MacApp
TradeUp Special" just to MacApp programmers. Call us with your credit card
number (Visa/MC) and then mail or fax a copy of the cover of your latest
MacApp CD-ROM. We'll ship immediately*!
 
Here's what you get:
 
o An 80% discount - Component Workshop(tm), including our OBJECTS ONLY dynamic
environment, incremental C++ compiler/linker(offering  a 60 to 1 improvement
over a typical MacApp compile to run cycle), garbage collector, portable
application framework, class libraries, integrated tools, the Extruder(tm) and
unlimited access to our Bulletin Board System for $495. (That's a $2,000
savings off the list price of $2,495.)
 
o Discounted Support - Annual maintenance (automatic shipment of maintenance.
releases) for only $200. This is a $175 savings off the standard list price of
$375.
 
o Half priced training - Our two day training program is a sure way to get up
and running as quickly as possible. Held at our Lexington, MA facilities,
training is regularly $1,500 per student. MacApp TradeUp customers may attend
for only $750.
 
COMPONENT WORKSHOP is based on C++ and uses a subset of the AT&T's 2.1 C++
standard. You may give up some C++ syntax, but you get back your weekends and
will earn a reputation as someone who delivers NEW APPLICATIONS early -
instead of promises for next year.
 
Call today if you would like to eliminate long compile cycles and never have
to chase down a nil pointer or other memory management bugs again. As one of
our major customer says: "Turnaround time, turnaround time, turnaround time!"
 
These prices are valid in the U.S. only and do not include shipping charges.
 
Please note:  COMPONENT WORKSHOP requires a Macintosh IIci or better with a
MC68030 or x040 processor running at 33MHz, System 7, a M68881 floating point
coprocessor, at least 25 Mbytes of hard disk space and 16 Mbytes of physical
memory (20 Mbytes are recommended) and MPW C(tm) for development.
 
* The product will ship in two phases, the Development environment immediately
and the Extruder on 4/14/93.