HDTenEightyP/NetNews huggingface dataset:
From: Chris_Knepper@taligent.com (Chris Knepper)
Subject: Re: MacApp Castaways & Prograp
Followup-To: comp.sys.mac.oop.macapp3
Organization: Taligent, Inc.
Date: Thu, 28 Jan 1993 00:48:18 GMT

In article <728086782.8531994@AppleLink.Apple.COM>,
STRATA3D@AppleLink.Apple.COM (StrataVision, Gary Bringhurst,PRT) wrote:
> 
> My take on Prograph (after having used it sparingly) is that it's an incredibly
> fun and stimulating environment, but that the lack of a cross platform strategy
> makes it a poor choice for implementing real world applications.

When I talked to them recently at MacWorld in SF, they assured me that a
Windows version was in the works. A compelling cross-platform strategy will
surely enhance the appeal of their product.

-Chris
 Utility Infielder
 Taligent, Inc.
 chris_knepper@taligent.com
From: NWAI@AppleLink.Apple.COM (Northwest Airlines, M McCarty,AM)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Mailing List
Date: 25 Jan 93 16:14:00 GMT
Organization: AppleLink Gateway

Please remove my AppleLink Address, NWAI, from the MacAppTech list of
addresses.
 
Thanks much
From: AVALON@AppleLink.Apple.COM (Avalon Engineering, R Brenner,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: NEMADA-Directions coming soon
Date: 26 Jan 93 02:08:00 GMT
Organization: AppleLink Gateway

As I mentioned in the last notice, Jeff Alger will be speaking at the next
NEMADA meeting, Tuesday, February 2. Directions to the meeting site will be
posted as soon as they are available, so please stay tuned for the next couple
of days.
 
After the meeting, there will be a brief executive counsel meeting to which all
are invited.
 
Here is a repeat of why you want directions:
----------------------------------------------
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: HARRIS.BILL@AppleLink.Apple.COM (Harris, Bill)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Is the _MacApp_Class_&_Met
Date: 21 Jan 93 02:27:00 GMT
Organization: AppleLink Gateway

The MacApp Class and Method Reference is now available from APDA. Thanks for
your patience on this one.
 
Bill Harris
MacApp/Bedrock Documentation
 
Newsgroups: comp.sys.mac.oop.macapp3
From: ccdyeung@uxmail.ust.hk (David Yeung)
Subject: How can I add a item to Popup menu dynamically?
Organization: Hong Kong University of Science and Technology
X-Newsreader: TIN [version 1.1 PL8]
Date: Fri, 29 Jan 1993 01:56:19 GMT

Hi,

I would like to know if there is any way to add or delete
a item from popup menu dynamically. I am using MacApp 3.0, 
the examples in the document only shows that the popup menu 
items are read from the 'CMNU' resource. Can they be 
deleted/inserted dynamically in the program.
 
Thanks in advance.

David Yeung (ccdyeung@uxmail.ust.hk)
Center of Computing Services and Telecommunication
Hong Kong University of Science and Technology
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re MacApp Class/Method Ref
Date: 24 Jan 93 23:08:00 GMT
Organization: AppleLink Gateway

Bill --
 
Given all of the well-justified unhappiness expressed lately about the poor
return on our ETO investments, and given that ETO claims to provide developers
with MacApp and its documentation, and given that a purchaser of a class
library might reasonably expect to receive paper documentation on the classes
and methods that compose that library (as opposed to just some introductory
"Guides" and a tutorial):
 
    PLEASE RECONSIDER THE DECISION (OR LACK OF DECISION) TO EXCLUDE THE
    MacApp Class and Method Reference FROM ETO!
 
(Or maybe we should all have our lawyers look at the ETO subscription forms and
see what they say about documentation?)
 
-- Dave ("just about got the 411 version memorized by now, anyway") Goldman
   Research Software Design
 
------------------------------------------------------------------------------
The MacApp Class and Method Reference (paper version) is a separate product and
is not included in the ETO series. You have to order it from APDA instead.
 
Bill Harris
MacApp/Bedrock Documentation
From: D3085@AppleLink.Apple.COM (Progressive Computing, D Lucky,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re:
Date: 24 Jan 93 02:54:00 GMT
Organization: AppleLink Gateway

>But there are advantages to having a brittle system.  The actual
>reliability of Mac programs is very high because either a programmer
>gets it right or the entire system dies horribly."
 
I disagree.  Users won't stand for other types of failures either (e.g., when
the program fails saving their document).  I know I want the programs that I
use to just work.  Also, I don't know that I'd agree with the assumption that
the reliability of Mac programs is very high.  That seems like a value
judgement that can't be quantified.
 
 
>>       - C, and C++, are not "safe" languages.  Yes, they are popular.
>>         But you can't make any strong statements about a C or C++
>>               program just because it compiles.  Compare Pascal or Modula.
>>         There's an extensive literature on this subject, and that's
>>               enough to say here.
>
>No argument here.  C++ is one of the biggest mistakes Apple have
>ever made IMHO.
 
Okay, I give up.  Why is Pascal (i.e., MPW Pascal) a safe language?  It seems
that MPW Pascal has extensions that make it unsafe (e.g., @ operator, type
coercion, UNIV).  Why is C++ a mistake?  Compared to Pascal, Modula, or some
other language?
 
Dave Lucky
Progressive Computing
From: CSX.TECH.DEV@AppleLink.Apple.COM (CSX Tech,James E. Stead,DIS,SDA,AM)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: When no printer is selected
Date: 25 Jan 93 21:33:00 GMT
Organization: AppleLink Gateway

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
From: JOHN.OLSEN@AppleLink.Apple.COM (Olsen, John D,APD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Flame Of The Week
Date: 26 Jan 93 16:57:00 GMT
Organization: AppleLink Gateway

In the same vein (I Hope) I also find it disconcerting that the Final schedule
for MADACON 93 _DOES_NOT_ include an "Apple Day" as it did in the past. Apple
does have representatives and is doing several of the talks but there is no
central focus as in the past.
 
I think I will miss this. I am _currently_ developing in C++ using MacApp.
Maybe my next major project will use Bedrock but today I use MacApp. I want and
need support for it. I will most likely not port this application to Bedrock
since it is quite well underway unless the effort is something much less than
say the change form MacApp 2 to 3.
 
I also am interested in hearing where we are headed and Bedrock sounds very
promising if it delivers what they say (speculate?). I need this info for the
future -- but I must complete and maintain the application that I have put a
great number of hours of labor into.
 
Thanx for listening,
 
John.Olsen
 
Newsgroups: comp.sys.mac.oop.macapp3
From: gray@tinman.asel.udel.edu (John Gray)
Subject: ObjectMaster CompileProject Script
Organization: AI duPont Institute
Date: Thu, 28 Jan 1993 16:02:53 GMT

Hello fellow MacAppers:

I recent bought ObjectMaster and have never been able to get the Build
facility to work to my satisfaction.  If I try to use OMMABuild in the 
CompileProject script I get an error that reads:

'###' MABuild: Whoops7 You have not executed the Startup file in the MacApp directory

As far as I can see I have executed all the scripts that I should be.

What are others using for their CompileProject Script.

Thanks in advance

John Gray
gray@asel.udel.edu
From: SZPAK@FOX.NSTN.NS.CA
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MacApp Castaways & Prograph
Date: 22 Jan 93 09:31:00 GMT
Organization: AppleLink Gateway

From: "Mark Szpakowski" <szpak@fox.nstn.ns.ca>
To: MACAPP3TECH$@applelink.apple.com
 
There was a recent message on the Internet OODL mailing list, that I believe
originated on this list, addressed to "MacApp Castaways".  I read this two wa
ys:
 
- MacAppers' feeling of abandonment by Apple, and fear of getting shipwrecked
 on
Bedrock;
- desire, or *need*, for more dynamic language/environment than C++/MacApp:
therefore interest in the good ship OODL.
 
Component Workshop (newborn), Camelot (prenatal), and Dylan (conceived) are n
ew,
proposed OODL environments.  Smalltalk and CLOS are existing OODLs. And there
's
Prograph, several years old, which might be called a VOODL - a Visual OODL.
Visual not just in the Microsoft sense of visual environment for creating vis
ual
applications (gag me with a spoon, they've even renamed their C++ to "Visual
C++"!), but also as visual *language* in visual environment for GUI apps.
 
The visuality makes Prograph unique, offers some enormous benefits (especially
as embedded in Prograph's edit-&-debug-both-interface-and-code-while-running
environment), but also presents some problems:
- due to past history of visual languages, they are often perceived as Mickey
Mouse;
- an executable iconic dataflow language is a rad thought to grok for many
people (look ma, no local variables!). Often the question is asked, "where's
the
code behind this?". The answer, of course, is "you're looking at it". From the
point of view of the destination side of the paradigm shift, the question is
as
whimsical as asking a Chinese person where the English is behind the ideograms
(except that dataflow is far more familiar, especially to corporate types, th
an
is Chinese).
- there are many tools, by many vendors, available for dealing with textual,
ASCII code (editors, parsers, version control tools, etc.), but not for any
other type of code.
 
The question to this list is, is this a fair assessment, and how do you see
Prograph as a VOODL and as an alternative for MacApp castaways?
 
-- Mark
 
Mark Szpakowski, szpak@fox.nstn.ns.ca
TGS Systems, (902) 455-4446, FAX (902) 455-2246
 
 
 
Mark Szpakowski, szpak@fox.nstn.ns.ca
TGS Systems, (902) 455-4446, FAX (902) 455-2246
From: PILLAR.CORP@AppleLink.Apple.COM (Pillar, Foster City,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re:software and jets
Date: 25 Jan 93 18:25:00 GMT
Organization: AppleLink Gateway

Regarding the analogy between reliability of complex software and jets:
 
> like to point out that Boeing and other aircraft developers spend
>BILLIONS of dollars developgind (and performing SQA) on each new
>jet--jets which they then sell for HUNDREDS of MILLIONS dollars.  A major
>software package, on the other hand, costs less than 5 MILLION to develop
>and sells for HUNDREDS of dollars.  Yet, I suggest that the number of
>potential 'fatal' failure points in a major software package are probably
>greater than the number of potential fatal failure points in a modern jet.
 
It's exceedingly unlikely that there are fewer failure points in the jet, when
you consider the whole jet, particularly since the new ones have 10's to 100s
of computer systems in them.  What we don't often thing about is that lots of
the bits that go into it are standard/prefabricated/pre-tested/etc pieces that
don't have to be rigorously tested every time a new model is rolled out: tires,
brake assemblies, particular metallurgical formulations, control cables,
hydraulic assemblies, etc.  Perhaps the better analogy for a large software
system would be the space shuttle, which could only rely on a relatively _much_
smaller set of existing components (Remember the Challenger?).
 
I don't remember where this thread started, but it _has_ brought us around to
the need for _useable_ reusable software components.
 
Lee Harris
From: JOHN.OLSEN@AppleLink.Apple.COM (Olsen, John D,APD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Can't wait for ETO 10
Date: 26 Jan 93 15:26:00 GMT
Organization: AppleLink Gateway

Hi,
 
It is not incremental build capability per se -- it is incremental _LINK_
capability. The idea the way I understand it is the iLinker builds a large
database of your symbols and other pertinent info during the "first" link. It
then leverages off that info for future links. They have a problem though -- it
does not produce .sym info during the iLink so they are fixing (read hacking?)
up a version of SourceBug that will allow it to read the database info so that
we can still do source level debugs. The link time gets down to something like
30 seconds now. You still use the "real" linker for your final build -- the
iLinker is for dev purposes only. (This is the tool they talked about at WWDC
92).
 
I hope I have told the story correctly.
 
John.Olsen
 
Newsgroups: comp.sys.mac.oop.macapp3
From: wgi@aplcomm.jhuapl.edu (W. G. Innanen)
Subject: "MABuild -autobuild" with C/C++
Organization: JHU/APL
Date: Wed, 27 Jan 1993 19:46:53 GMT

I'm having difficulty in figuring out how to go about doing a 
"MABuild -autobuild" on a system that has only C and C++ compilers.  
I have the CD-ROM C/C++ MPW bundle (v3.2.3) with the floppy update 
to v3.2.4, and the MacApp 3.0.1 CD-ROM bundle.  

In trying to do various things, I found that I was unable to do 
an autobuild of the MacApp library:

    MABuild NewApp -autobuild -TwoOhTemplateViews

The system came back with a terminal error because I have no 
Pascal compiler.  In checking around I found that there was one 
lonely Pascal source file in the Libraries, "UPascalTool.inc1.p."  
It seems to be related to building MPW tools in Object Pascal, 
so I figured I could do without it.  However when I removed it 
and tried again, the fact that it was missing caused an error.  
I was unable to find where that source file is referenced.

I was able to continue with my project by locating the ".S7Te2T" 
precompiled library from the CD-ROM, but it bothers me that I 
can't autobuild with just C/C++.   Also, I have to play games with 
the MABuild parameters in order avoid autobuilding and use the 
precompiled libraries.  E.g. use:

    MABuild NewApp -TwoOhTemplateViews -Sym -debug

instead of 

    MABuild NewApp -TwoOhTemplateViews -debug

Does anyone know a way around this problem?  Am I missing 
something obvious?  I probably am. :-(   Any help/advice 
would be appreciated.

Bill
--
Bill Innanen             (Internet) wgi@aplcomm.jhuapl.edu
Johns Hopkins University        Applied Physics Laboratory
#include <stdDisclaimers.h>   /* Unless otherwise noted */

Newsgroups: comp.sys.mac.oop.macapp3
From: gtall@ogre.cica.indiana.edu (Gerry Allwein)
Subject: Re: MacApp Castaways & Prograph
Organization: Indiana University
Date: Sat, 23 Jan 1993 13:44:08 GMT

I don't consider Prograph a replacement for Bedrock although it may be a
replacement for MacApp. I have a love/hate relationship with MacApp. I like
what it does for me, I get irritated by what it sometimes does to me. I
suspect Prograph is similar. The paradigm shift is real but I think somewhat
overblown. If you are going quality work, most of it will be done in design,
not coding. Whatever horn of plenty the paradigm shift gives us, it is giving
it to us in the least productive (and least interesting) part of engineering.

Prograph can't be a replacement for BedPebbles (they ain't rocks yet) unless
it becomes a cross development tool. I'm not aware I can develop on a Mac
under Prograph for that accursed evil-empire inspired machine, the PC. Now,
if you folks could pull that off, I for one would be happy to star in the
commercial selling that snake-oil. Might even take some hints from Pepsi
commercials....

Gerry
From: GILLAM.R@AppleLink.Apple.COM (Richard Gillam,GEIS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: MacApp makefiles and Other
Date: 21 Jan 93 15:05:00 GMT
Organization: AppleLink Gateway

John--
 
I can take a guess as to what your problem might be, having had similar
experiences myself.
 
Is the views file you're looking to include named <YourAppName>.rsrc?  If it
is, it will indeed be overwritten, as MABuild will use that filename as the
name of the output from the Rez step, without looking to see if there's already
a file there it should keep around.  You can probably modify your .r file to
keep this from happening, but it's easier to just rename the .rsrc file.  I
have two, a <MyAppName>Compiled.rsrc file that contins things such as icons
that I create in ResEdit, and a <MyAppName>Views.rsrc file that contains view
hierarchies and supporting resources as created in Ad Lib.  You might find this
helpful.
 
If you haven't defined clashing names as I described above, I'm not sure what
your problem might be.
 
One other thing I learned the hard way:  MABuild only uses OtherRsrcFiles to
track dependencies.  If you actually want these files' resources to be compiled
into your finished product, you have to add "include" lines to your .r file
(and if you're using Projector and want it to track your .rsrc files, make sure
to add "not ckid" to the end of the include lines).
 
Hope this helps,
 
Rich Gillam
GE Information Services
From: ALANDAIL@AppleLink.Apple.COM (Personal Software, Alan Dail,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: C++ (was re: bedrock defection
Date: 24 Jan 93 01:50:00 GMT
Organization: AppleLink Gateway

Larry,
 
>...as safe as Pascal.... MPW C++ may not catch as many errors as it should,
>but that's a compiler problem, not a language problem.
 
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++.
 
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.
 
Alan
 
Newsgroups: comp.sys.mac.oop.macapp3
From: Kees de Ridder <keesr@cc.mey.nl>
Subject: Re: Serial Port Hardware Overrun?
X-Useragent: Nuntius v1.1.1d16
Date: Thu, 21 Jan 1993 14:50:32 GMT
X-Xxdate: Thu, 21 Jan 93 13:53:36 GMT
Organization: Moret Ernst & Young

In article <727584405.1371592@AppleLink.Apple.COM> Biodex Corp,
K.FIELDHOUSE@AppleLink.Apple.COM writes:
>My question is, what things (MacApp releated or not) affect the serial
driver'
>ability to keep up with the data connection?   I'm not opposed to
putting in
>hardware handshaking (I'd prefer not to use Xon/X0ff as that would
complicate
>data transmission) but I'd like to understand better just what is going
on when
>I get these hardware overflows.  Any light you can shed will be greatly
>appreciated.
> 
>Regards,
> 
>Keith
> 


The overrun errors might occur when the mac is in interrupt routines.
When this is 
the case it has nothing to do with MacApp. In the past I noticed that is
was 
sufficient in most cases to disconnect the Apple (even aPlus) from the
net.
---
Internet:         ||   AppleLink:   ||   Voice:        
keesr@cc.mey.nl   ||   Hol0146      ||   (0)10-4074255 
---
From: V0645@AppleLink.Apple.COM (Tandem, Gary Campbell,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: TGridView Horrors
Date: 23 Jan 93 17:54:00 GMT
Organization: AppleLink Gateway

Hi,
 
What about the FONT dialog in DemoDialogs.
 
I use TGridViews all the time in dialogs since I don't how
to do lists but the MacApp way.
 
If DemoDialogs isn't clear enough I have a simple dialog example
of a non-edited TGridView list.
 
cheers,
Gary Campbell
Tandem Computers
AppleLink: V0645
Internet  : campbell_gary@tandem.com
From: PARKS.W@AppleLink.Apple.COM (Parks, William,APD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: TGridView Horrors
Date: 23 Jan 93 10:01:00 GMT
Organization: AppleLink Gateway

Hello
 
    I've been trying to use TGridView for a editable list. I'd like to have
user names in one column and passwords in a second column.
 
    I've looked at the calc example. It's doument based and I'm trying to use
my list in a dialog to enter preferences in the application and save to disk as
a resource.
 
    The calc example is very complicated. Is there a simpler way, or has there
been an article in MacTutor or FrameWorks?? Seems like I've seen one but can't
seem to find it.
 
                Thanks for any ideas.
 
 
                            Bill Parks
From: PETER_BOSANKO@qmrelay.mail.cornell.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Segment woes
Date: 18 Jan 93 21:57:00 GMT
Organization: AppleLink Gateway

AppleLink gatewayed addresses are limited to 35 characters, and this letter
has a longer return address. It has been mapped into the address above.
Reply using that address, and everything should work. The actual address
is in the Internet headers below.
 
From: "Peter Bosanko" <Peter_Bosanko@qmrelay.mail.cornell.edu>
To: "MacApp3 Tech$" <MacApp3Tech$@applelink.apple.com>
 
GatorMail-Q                   Segment woes
Hello,
I'm experiencing a strange error...
 
   ### Goliath:MPW:Tools:Link: Error: Jump table offset
   into code segment is
   greater than 32K. (Error 50) .READFROM
 
... when my MacApp 3.0.1 program is being linked.  It happened after I added a
couple of new classes to my App.  I thought at first that it might be because
one of my segments had gotten too big.  So I made sure all the new code was in
a segment on its own.  It still gets this error.
 
Has anyone seen this before?  Does this mean that I don't have space in my Jump
Table?  Any insights would be appreciated.
 
Pete Bosanko
Cornell Information Technologies
From: krk@oit.itd.umich.edu (Kenneth Knight)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Can't wait for ETO 10
Date: 21 Jan 1993 19:39:45 GMT
Organization: Instructional Technology Laboratory, University of Michigan
NNTP-Posting-Host: helen.oit.itd.umich.edu

In article <727584337.0200705@AppleLink.Apple.COM> PARKS.W@AppleLink.Apple.COM (Parks, William,APD) writes:
>Hello,
> 
>    Just read in MacWeek the MPW 3.3 will have incremental build capabilities.

Just what does incremental build capability mean?

  ** Ken **