HDTenEightyP/NetNews huggingface dataset:
From: D4887@AppleLink.Apple.COM (Advanced Comm Eng, G G Apple,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: * Takeover Proposal *
Date: 22 Dec 92 18:31:00 GMT
Organization: AppleLink Gateway


 
----------------------------------------------------------------------------
>"this cannot possibly affect
>anything except..." changes actually broke lots of things.]
 
    You are absolutely correct.  As someone who has served as a communications
systems engineer and systems manager on commercial, military, and space
programs (including the space shuttle), I can assure you that even small
changes require extensive testing and reverification for which we used to
charge the feds beaucoup bucks to make up for the buy-in bid prices.
 
    Back in the 70's we used to anticipate the transition from doing things in
hardware to doing them in software.  Problems could be fixed and systems could
be maintained because at least the "software could be changed".  Later, we went
back to doing many designs in hardware because we learned that at least the
"hardware could be changed."
 
    An example is the present situation in MacApp where it can't handle more
than one scrap type at a time because of a fix for an earlier bug.
 
    A proper combination of OOP and framework/system design can minimize these
problems and limit the effects of change propagation.  However, determining the
effects of any change is still not easy or obvious.
 
    Also, there is a very strong need for centralized configuration/version
management unless you want total chaos and version dispersion.  That is why we
prefer officially (Apple Computer) blessed solutions to our own or someone
else's hack solutions.
 
G. Gordon Apple   D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA
 
*** Anxiously awaiting news that the BedRock Marines have landed and wondering
how long it will be until the code-starved can be fed. ***
From: GER.XSE0097@AppleLink.Apple.COM (Germany - Proficomp, M Greve,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Sourcebug error
Date: 3 Jan 93 17:02:00 GMT
Organization: AppleLink Gateway
From: KSAND@AppleLink.Apple.COM (Sandvik, Kent)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: More about the System 7.1 WDEF
Date: 22 Dec 92 19:16:00 GMT
Organization: AppleLink Gateway

OK, me and my big mouth. I have to take back the hint about using the new WDEF
that is part of the Wordscript 2 package of System 7.1. The engineer
responsible promised us that it was OK for developers to use it. However this
is/was not formal, and instead of causing possible problems we at DTS agreed
that is better to now tell developers to use this WDEF.
 
Instead you need to use the old trick, i.e. use or modify the WDEF that is
available in the MacApp 3.0.1 distribution. And if someone wants to rewrite the
WDEF, and gets into trouble -- and is a partner -- contact DTS and we will sort
out the issues.
 
Cheers,
Kent
PS: Another hint, I've seen a lot of alternate WDEFs, in C, in both the
developer CD and the MacHack-92 CD. It makes actually sense to rewrite WDEFs in
C, because the future PowerPC port is far more easy if you have code in C.
From: ksand@apple.com (Kent Sandvik )
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: AppleEvent source for MacApp
Date: 23 Dec 92 00:48:17 GMT
Followup-To: comp.sys.mac.oop.macapp3
Organization: (Evil Eye Creature from Mars, Inc.)

In article <725046526.3918062@AppleLink.Apple.COM>,
D6431@AppleLink.Apple.COM (OptImage Interactive Svcs,PRT) wrote:
> I'm trying to get my MacApp Application to respond to apple events.  Does
> anyone know of a sample app (with source code) that is  written in MacApp that
> does simple apple event handling??  I have access to apple link and the
> developer CDs. Or could you send it to me if you have something.  The official
> documentation is weak.  I know how to process regular apple events in C but not
> in MacApp.

Search for AEGestalt MacApp 3.0 sample that sends and receives
SetData/GetData
events (quite common). It's on the Developer CD.

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
"Don't just do something!  Stand there!"  -- Mystery Science Theater 3000
From: JWBAXTER@HALCYON.HALCYON.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: * Takeover Proposal *
Date: 22 Dec 92 07:18:00 GMT
Organization: AppleLink Gateway

From: jwbaxter@halcyon.halcyon.com
To: MACAPP3TECH$@applelink.apple.com
 
>> A LOT of the bug reports are trivial little fixes, with no worries about
>> distant side-effects, so why should every MacApp developer always have to
>> individually modify his/her MacApp source?
>
   I come from a world in which there is no such thing.  ANY change
invalidates all previous proof of correctness.  [The company had several
pretty hefty mainframes which when not otherwise engaged overnight would be
running [self-scoring] regression testing to try to validate the most
recent changes/patches.  Every bug report and change approval generated
additional regression tests based on the new information.  The regresson
testing was CONSTANTLY demonstrating that the "this cannot possibly affect
anything except..." changes actually broke lots of things.]
 
My comment is a little strong.  "No worries" however is off the mark at the
other end of the spectrum.  OOP helps move everything towards the "no
worries" end of things (when done correctly...there's a good bit of
"not-correctly" lurking in MacApp, much of it imposed by the toolbox).
 
Nonetheless, it's better for (most) needed changes to be made and proven
centrally (as I indicated in a private message of support to Dave).
   --John
 
--------------
John W. Baxter   jwbaxter@halcyon.com   [BAXTER.JOHN on AppleLink, from
AppleLink only.]
From: DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: AppleEvent source for MacA
Date: 22 Dec 92 19:33:00 GMT
Organization: AppleLink Gateway

Hi Jay,
 
I have developped MacApp 3.0.1 classes with AE's and it is working. I'm using
only the kAEWaitReply option, thus the client is waiting for answer from the
server and eventually resulting in a timeout-error.
 
I was experimenting during some while until i found a *nice-OOP* solution.
I overwrote the 'DoAppleCommand' in the TDocument or TFileBasedDocument, but
this didn't work, so i overwrote it in the TApplication with a little trick
(searching the TDocument with a specific FileSpec).
 
The classes are part of my *framework-above-MacApp*: ie a DB access method.
I can convert it to a *NothingAE* example, but this will take some time. If
there are a lot of members interresting in this stuff, i will do it and first
submit it to a *specialist* (because it is not perfect! - sending a request to
a server on another Mac is not tested - later when i receive my PB 180) and
eventually it is worth for an article in FrameWorks.
 
Next step will be OSL, after the DU course on diskette (after NewYear), which
is very good (i compiled the whole stuff once), but THINK C 5.0.
 
> The official documentation is weak
 
1. 'Programmer's Guide to MacApp' gives anly one example (Publish/Subscribe)
2. Develop CD 'AppleEventoMacApp3.0b1o7.0' (Japanese example) is not clear
3. Develop CD 'AEObject-Edition1.0.2 Sample' is very good, but non-MacApp
 
Regards
Willy
 
ps: If you implement AE's, use 'AETracker 3.0', which is VERY GOOD for
debugging AE's
 
Newsgroups: comp.sys.mac.oop.macapp3
From: nagle@netcom.com (John Nagle)
Subject: Re: Re2: * Takeover Proposal *
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 28 Dec 1992 19:46:59 GMT

ksand@apple.com (Kent Sandvik ) writes:
>Well, I've been involved with PowerPC for a long time, and the
>platform will run existing binaries in emulation mode (quite well
>and fast based on the current tests we've done), as well
>as have a new native API that is a refinement of the current one so
>there's not a lot of work concerning a port to PowerPC.

       Remember, Apple claims Mac PowerBooks will run DOS programs, with
fine print at the bottom of the ad saying you need an emulation program
such as Soft PC.  Performance is comparable to PCs of 1985 vintage.
That's "emulation mode", as Apple markets it today.

       So Apple's strategy for the 90s is an all-new machine, an all-new
application interface, and a "penalty box" (a la that of Microsoft Windows) 
for running obsolete (old Mac) applications.  

       With a change that big, the user has to face a major conversion.
So there's a choice: convert to Apple's new line, or convert to something
else.  

					John Nagle
       
Newsgroups: comp.sys.mac.oop.macapp3
From: ksand@apple.com (Kent Sandvik )
Subject: Hello, but I must be going...
Date: Mon, 28 Dec 1992 00:24:14 GMT
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.macapp3

In article <725492228.1473624@AppleLink.Apple.COM>, RSD@AppleLink.Apple.COM
(Research SW Design, D Goldman,PRT) wrote:
> (c) at best show up in an Apple bug doc, and that only if we're unexpectedly
> lucky (Kent says he's being transfered to another engineering department!);
 
Hi, I guess I need to clarify what is going on. I'm leaving DTS, because
I will take part in the startup of the PIE Newton DTS group. Expect
postings
from me concerning MacApp to (fortunately :-)) diminish in two weeks'
time.

Just to stop any rumors about this all, DTS has two fully qualified
MacApp engineers. Also, our core technology front line group now
has engineers that know about MacApp and OOP. In addition, DTS will
fill my position as soon as possible with a similar candidate. So 
from MacApp support point of view the situation is fully under control,
and this was a perfect time for me to move on to new challenges.

Have fun, and I'm sure we will meet again concerning Newton and PIE
products! Unfortunately I couldn't make it concerning MADACon, and 
that was sad, because last year's MADACon in Florida was one of the
funniest computer conferences I've attended.

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
"Don't just do something!  Stand there!"  -- Mystery Science Theater 3000
From: lenoil@catalogic.com (Robert Lenoil)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: TEditText P.S.
Date: 28 Dec 92 11:31:31 GMT
Organization: Catalogic, Mountain View, California [Voice: 415-961-4649]

>By the way, despite the occasional inquiry here, I've never seen an
>explanation of the point of all this floating TEView business in the first
>place

Pre-3.0, TEditText could only be used with TDialogView, which was essentially
an objectized version of the toolbox Dialog Manager. So the short answer to
your question is "because that's how the dialog manager did it." As to why
the *dialog manager* used a floating TextEdit record, I suspect the 64k RAM
of the original Macintosh had everything to do with it.
From: DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Bedrock News
Date: 22 Dec 92 18:15:00 GMT
Organization: AppleLink Gateway

Hi all,
 
> The proposed price tag (10K or higher) would surely keep us from using
Bedrock unless ..
 
As a *small* developer this price (if the information is right) is too high. I
think even for in-house developers it will allmost impossible to justify it.
Until now we got MacApp on ETO for a reasonable price. I hope that Bedrock will
be distrubuted in the same way (sources included) and the conversion from
MacApp will be minimum or procedural (Have we forgot the conversion from MacApp
2.0?)
 
> MacApp has been an excellent framework
 
Indeed MacApp is very good, in spite of
    - some bugs should be fixed, i never fix a long list of bugs (*they* call
it APARS and PTF's) in advance. If i have a problem i look to the *Bug list*
and fix it. But i expect regularly updatings, and this is missing on the ETO.
Why is Apple not fixing the bugs and give us an updated version on the next ETO
(MacApp 3.0.2, MacApp 3.0.3, ..., MacApp 3.1.0, ...) ?????
    - missing new features: OSL, QuickTime, ...
    - missing incremental build
    - missing the DLL's feature
 
> Cross-platform development is not that important to us ...
> We need a framework that keeps pace with the latest Macintosh developments
and fully supports them as they are released
 
For myself, cross-platform is NOT important (perhaps (!) i miss some
opportunities)
    - i maked some time ago a choice: (if i go in detail it will be a 32K link)
        - OS2, even 2.0, is still BAD!
        - Windows 3.1 is good, but there is still *a DOS*, i mean the 'c\'
        - Mac interface is from the beginning very good and consistent.
    - it is allmost impossible to learn all the new features on all OS's.
 
Thus my strategy is to writing a *framework* above MacApp, and so i'm prepared
for *small* conversions. So, if Bedrock will be too expensive, i will continue
with MacApp 3.0.1
 
It is 11:55: we need formal info ... (specially from Apple)
 
Regards
Willy
From: B.HABLUTZEL@AppleLink.Apple.COM (Hablutzel, Bob,CST)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Saving in Excel format?
Date: 29 Dec 92 15:23:00 GMT
Organization: AppleLink Gateway

Kent -
 
  If you can possibly get away with it, I would look at using tab delimited
text instead of strict Excel format - Excel has the right to change w/o notice,
and probably will. Tab delimited can't really change all that much.
 
  If you need examples of exporting tab delimited text, take a look at the Calc
example program.
 
Bob
 
 
 
Bob Hablutzel
Hablutzel Consulting
ALink: B.HABLUTZEL
Phone: 708 328 0130
From: ksand@apple.com (Kent Sandvik )
Newsgroups: comp.sys.mac.oop.misc
Subject: Re: Learning App Frameworks (was Re: THINK Class Library learning..)
Date: 30 Dec 92 18:35:35 GMT
Followup-To: comp.sys.mac.oop.misc
Organization: (Evil Eye Creature from Mars, Inc.)

In article <6606.2b41845f@hayes.com>, bcoleman@hayes.com (Bill Coleman)
wrote:
> Sounds like you are suggesting people build frameworks in Eiffel, which
> has formal mechanisms for defining pre and post conditions for all routines.
 
> Too bad there isn't such an Eiffel implementation for the Mac.

It's not that hard to add pre- and post-conditions with methods using 
assertions. I have my own ASSERT macro package that is conditionally
compiled in during debug mode, and it certainly catches a lot of errors
I would not be aware of otherwise. It's a matter of strict programming
to add in an additional line after each error producing statement. And 
yes indeed a language such as Eiffel helps, but it does not imply that
you can't do the same thing using for instance macros in C/C++.

Cheers,
Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
"Don't just do something!  Stand there!"  -- Mystery Science Theater 3000
Newsgroups: comp.sys.mac.oop.misc,comp.sys.mac.programmer
From: nagle@netcom.com (John Nagle)
Subject: Re: Summary: I'm faint! I just saw the price for MPW!
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 22 Dec 1992 07:07:55 GMT

lsr@taligent.com (Larry Rosenstein) writes:
>In article <1992Dec20.200609.15692@netcom.com>, nagle@netcom.com (John
>Nagle) wrote:
>> 
>>      It's also worth noting that if you use MacApp, your source code may
>> be "contaminated" with Apple code, and you may have legal difficulties 
>Can you cite a part of the MacApp license agreement that might lead to
>problems?  I don't know of any clause that would contaminate your source
>code.  While it may say that you cannot port MacApp to another platform,
>you are always free to take your source code and port that.  

      The Developer CD Series volume II  (which its literature
says contains sample code) comes with the statement "The Software and Manuals
contain copyrighted material, trade secrets and other proprietary material
and in order to protect them you may not decompile, reverse engineer, 
disassemble, or otherwise reduce the Software to a human-perceivable form.
You may not modify, network, rent, lease, loan, sell, distribute, or create
derivative works based upon the Software in whole or in part..."
(from paragraph 2, "Restrictions")

      Note that this is on a CD that contains sample code which Apple
encouraged you to copy into your own programs.

      I dropped out of Apple's Certified Developer Program in 1990, so
I'm not up to date on current terms.  But at least back then, these
things came with language sufficiently overreaching that avoiding
contamination with Apple intellectual property would be difficult.
This gives Apple some leverage if you later port something that might
contain some sample code to another platform.

      It's scary having sample code around with that kind of restrictive
language attached.  And destroying the CD, as required to terminate the
agreement under Paragraph 3 of its licence agreement, is a real pain.
Trying to break a CD in half by hand is dangerous.  I finally had to use
a heavy-duty paper punch.

      I think Apple has become more reasonable since 1990, but I haven't
checked.  I don't use MacApp.

						John Nagle
Newsgroups: comp.sys.mac.oop.misc,comp.sys.mac.programmer
From: lsr@taligent.com (Larry Rosenstein)
Subject: Re: Summary: I'm faint! I just saw the price for MPW!
Followup-To: comp.sys.mac.oop.misc,comp.sys.mac.programmer
Organization: Taligent, Inc.
Date: Wed, 23 Dec 1992 02:00:33 GMT

In article <1h7sdqINNr0p@calvin.NYU.EDU>, roy@mchip00.med.nyu.edu (Roy
Smith) wrote:
> 
> state the "you may not [...] create derivative works based upon the Software
> in whole or in part".  If writing an application based on MacAPP isn't a
> derivitive work, I'd like to know what is.

It seems to me that the same would be true of using the MPW libraries.  As
Kent pointed out, Apple puts a general statement on its CD-ROMs, but there
are exceptions such as Snippets. 

I think that if you ship a MacApp program you need to get a separate
license, which I suspect is not included in the ETO subscription.  So
perhaps that would satisfy any legal concerns one my have.

Anyone who has concerns should contact the Apple Software Licensing
Department.

Larry Rosenstein
Taligent, Inc.

lsr@taligent.com
From: Bob Cent <cent@u.washington.edu>
Newsgroups: comp.sys.mac.oop.misc
Subject: MacApp: diff in & output files
Date: 30 Dec 1992 23:23:38 GMT
Organization: University of Washington
Distribution: world
NNTP-Posting-Host: cent.rprc.washington.edu
X-UserAgent: Nuntius v1.1.1d12
X-XXMessage-ID: <A767708367010B23@cent.rprc.washington.edu>
X-XXDate: Wed, 30 Dec 92 15:28:03 GMT

In Think Pascal and MacApp2: I want to open an existing file, read it,
then create a new file which the user names and fill then it with
information.  Then close both files.

Using MacApp I know how to open, read, write, and close a file, but I 
have not found an example of how to query for both an input and an output
file name.  I can imagine how to do this procedurally, but how is it
recommended to do this in MacApp?  Thanks!

Bob Cent  (cent@u.washington.edu)
University of Washington, SJ-50
Seattle, WA  98195
Newsgroups: comp.sys.mac.oop.misc
From: Daryl_Spitzer@mindlink.bc.ca (Daryl Spitzer)
Subject: ?SmalltalkAgents?
Organization: MIND LINK! - British Columbia, Canada
Date: Sun, 3 Jan 1993 19:02:08 GMT

I just saw an ad. for SmalltalkAgents (from QKS - Quasar Knowledge Systems)
for Macintosh.  (Inside back cover of MacTech magazine.)  It sounds like it
supports System 7 and the Toolbox better than Smalltalk/V Mac.  Has anyone
any experience with it?  Comments?

--
-------------------------------------------------------------------
 Daryl_Spitzer@mindlink.bc.ca     "Life isn't just, life just is."
         a2251@mindlink.bc.ca              -- Me  (I think.)
-------------------------------------------------------------------
Xref: sparky comp.sys.mac.oop.misc:136 comp.sys.mac.programmer:20212
From: roy@mchip00.med.nyu.edu (Roy Smith)
Newsgroups: comp.sys.mac.oop.misc,comp.sys.mac.programmer
Subject: Re: Summary: I'm faint! I just saw the price for MPW!
Date: 22 Dec 1992 20:05:14 GMT
Organization: New York University, School of Medicine
NNTP-Posting-Host: mchip00.med.nyu.edu

nagle@netcom.com (John Nagle) wrote:
> and in order to protect them you may not decompile, reverse engineer, 
> disassemble, or otherwise reduce the Software to a human-perceivable form.

lsr@taligent.com (Larry Rosenstein) replied:
>I don't have any CDs around to see what the situation is today.

	The paper folder that comes tucked into the ETO-8 disk (the
latest-minus-one ETO shipped, but the latest one I've got here) has the same
warning about reverse engineering, being a trade secret, etc.  They also
state the "you may not [...] create derivative works based upon the Software
in whole or in part".  If writing an application based on MacAPP isn't a
derivitive work, I'd like to know what is.

-- 
Roy Smith <roy@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."
Newsgroups: comp.sys.mac.oop.misc
From: lsr@taligent.com (Larry Rosenstein)
Subject: Re: Summary: I'm faint! I just saw the price for MPW!
Followup-To: comp.sys.mac.oop.misc,comp.sys.mac.programmer
Organization: Taligent, Inc.
Date: Mon, 21 Dec 1992 18:40:47 GMT

In article <1992Dec20.200609.15692@netcom.com>, nagle@netcom.com (John
Nagle) wrote:
> 
>      It's also worth noting that if you use MacApp, your source code may
> be "contaminated" with Apple code, and you may have legal difficulties 

Can you cite a part of the MacApp license agreement that might lead to
problems?  I don't know of any clause that would contaminate your source
code.  While it may say that you cannot port MacApp to another platform,
you are always free to take your source code and port that.  

If by contaminate you mean that you write code that works with MacApp,
which itself can't be ported, then any Mac application would be
contaminated.

Larry Rosenstein
Taligent, Inc.

lsr@taligent.com
From: jsuker@orion.oac.uci.edu (Johnathon Suker)
Subject: Re: Summary: I'm faint! I just saw the price for MPW!
Newsgroups: comp.sys.mac.oop.misc,comp.sys.mac.programmer
Date: 23 Dec 92 17:25:45 GMT

ksand@apple.com (Kent Sandvik ) writes:

>> Also, all the Tech Notes and DTS Sample Code I've seen has carried an
>> explict statement that you can use this and distribute it, provided you do
>> not sell it.

>statement does not clearly state that the snippets also belong to this 
>category, but this is the case as well. So I will talk with the people
>downstairs making sure that this is also included to the license in 
>future.

Kent,

	I came onto this thread rather late, but I am writing a program
that uses some code from one of the TechNotes (it is a generic socket
listener) also from TechNote 18.  When done I wanted to release this 
program as shareware/freeware (I havent decided yet).  Am I to assume
I now cannot?  I am modifying the code for my purposes but you can only
write an event loop so many ways and so I used the TechNote code.  Do
I now have to re-write all of it or just give Apple credit (which I 
was going to do anyway)?

				Thanks for the information in advance,
						Johnathon

--
Johnathon Suker                   | If I were human I believe the proper
University of California, Irvine  | response would be, 'Go To Hell'. If I 
Univeristy Library                | were human.
jlsuker@UCI.EDU                   |             Spock - ST:TUC
Newsgroups: comp.sys.mac.oop.misc