HDTenEightyP/NetNews huggingface dataset:
From: DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: The Takeover ...
Date: 29 Dec 92 02:38:00 GMT
Organization: AppleLink Gateway

Hi all,
 
First to Kent:
> And what are the real bottlenecks of the Macintosh today?
Real multiprogramming (multitasking) with priorities and time-slicing setup via
CDEV or something else. Perhaps with PowerPC?
 
I believe that there will be no or minor penalty for todays 7.x Mac
applications running on a PowerPC: the penalty is compensated by higher speed
of the RISC. I refer to "Blueprint for the Decade" (an Apple document) p. 8:
"Smooth Migration Path", and an article in "Apple Direct".
Running SoftPC on a Mac is very slow, even on a Mac IIfx: that's real
emulation. But there is a market for this product.
 
But ... on p. 10 in the same document:
 
### i quote "MacApp - Speeding Application Development"
    ...
    "MacApp provides a timely way to incorporate new features when new versions
of system software are introduced. When MacApp began shipping, developers who
had created their programs with MacApp 2.0 were able to gain full support for
System 7 features in a matter of days instead of months."
    "MacApp will track advancements in the System 7 platform, including
QuickTime, OCCE and user interface enhancements. MacApp gives in-house and
commercial software developers the ability to track these capabilities as well,
while also providing a head start toward programming for Pink."
### end quote
 
The analysis:
    1. "new features when new versions of system software are introduced":
       ---> Indeed MacApp 3.0 supports some new Sysatem 7.0 features:
            AppleEvents, Balloons. But there was a big conversion from MacApp
            2.0.
    2. "QuickTime, OCCE and user interface enhancements":
        ---> de nada.
    3. "providing a head start toward programming for Pink":
        ---> smooth migration to Bedrock? (see below)
 
So what???
    Or, this article has no value (only commercial)
    Or, framework software is moving too fast and we developers can't follow.
        We can't change every year to another framework.
 
In any case, i work 23+ years with IBM and one thing is sure: When a product
WILL BE obsoleted, we receive an official letter specifying that 1 year from
now it will be obsoleted and AFTER that date no more maintenance. In the
meantime (during 1 year) we received support and official bug fixes.
 
Thus, ETO subscribers received no official document about MacApp obsolete.
We expect that Apple fix the bugs until Bedrock is released and give us a
smooth migration to it, otherwise we can better develop as in *the old days*:
vinala C(++)/Pascal and create our own *framework* and using MacApp as a base
for trivial procedures or find another solution ...
 
Regards,
Willy "WDW" De Waele
From: PHILMONT@AppleLink.Apple.COM (Philmont SW Mill, Jesse Feiler,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re3: Takeover
Date: 29 Dec 92 18:01:00 GMT
Organization: AppleLink Gateway

Jeff,
 
I agree with your points about the resources required to support MacApp, and
would like to add a few of my own.
 
This most recent epistolary tempest once again demonstrates the diversity of
MacApp users and our needs and wishes. Some of us cry for stability and
guaranteed fixes (Bernadette's link about 8 person-weeks to do a test surprised
my only by being lower than I would have suspected). Others want performance
modifications, incorporation of new OS features (GX, OCE, etc.), and still
others are breathing down the throat of cross-platform support.
 
MADA is not an appropriate organization to support MacApp. What MADA is
appropriate for is formalizing our requests/complaints/wishes, etc. I would
like to see MADA collect our wishes, complaints, etc. on a routine basis, and
send out a ballot on which all members could vote for their favorites. Given
the limited resources available for MacApp support (and those resources would
be limited even if Apple committed 50 people full-time to the project), Apple
would have some idea of the relative value of each change. (And, of course,
nothing would prevent Apple from posing a few items for the ballot -- like GX,
OCE, etc. -- to gauge their popularity.)
 
In this way, MADA could do what it does best (i.e., funneling our sometimes
discordant voices into a mellifluous tune) and representing its members before
the powers that be at Apple. In addition, such a process could be expanded to
other platforms, giving MADA a leading role in the coordinating of user
requests, and using our joint clout to request Apple, Symantec, etc. to do what
they do best.
 
MADAcon would be an obvious place at which to discuss such a plan and at which
to take some preliminary votes. On behalf of those of us with critical
production deadlines in March who will NOT be in San Diego, may I humbly
request that if anything like this is done, it allow for input via AppleLink.
 
Jesse
From: PARKS.W@AppleLink.Apple.COM (Parks, William,APD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Descendent in another unit???
Date: 3 Jan 93 05:33:00 GMT
Organization: AppleLink Gateway


    I am having problems using a descendent class of a classe I have derived
from standard MacApp. It works ok when it is in the same unit as their ancestor
class. But when I move them to another unit, no amount of includes, MAMake, or
class PascalObj TAdminDialog; forward declaration I still get an error.
 
        base class undefined.
 
    I've even tried extern to no avail.
 
    I seem to be missing something basic.
 
 
                    Any help would be appreciated.
 
                                Thanks Bill Parks
From: MADA@AppleLink.Apple.COM (MADA Admin, Steve Mann,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MADA Meeting Reminder
Date: 31 Dec 92 00:29:00 GMT
Organization: AppleLink Gateway

Just a reminder:
 
There will be a MADA meeting at MacWorld, Wednesday Jan 6th at 7PM, room 252 in
the Moscone center. Component Workshop, Sierra Software, Electron Mining, and
Emergent Behavior will be presenting.
 
Also, MADA will be at the APDA Developer Support Organizations table in Moscone
room 250 Wed-Fri 10AM-noon. Stop by and say hello.
From: DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Performance tests...
Date: 27 Dec 92 03:21:00 GMT
Organization: AppleLink Gateway

Hi,
 
> Then if you have some highly computational sections to write, feel free to do
them as straight Pascal or C (whichever you're more comfortable with;
performance differences usually relate more to the efficiency of your
particular compiler [and the cleverness of your particular programmers] than to
language choice)
 
The language with the most performance is still the assembler (closest to the
hardware), if good designed. No compiler can beat straight assembler coding.
But ... we know all the disavantages of the assembler. Perhaps small pieces
inline coding?
 
Indeed, the choice of a OOP framework or not is depending on other criteria.
 
Regards
Willy
From: DUNCAN.KEN@AppleLink.Apple.COM (UT Austin, Ken Duncan,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re3: Takeover
Date: 29 Dec 92 02:05:00 GMT
Organization: AppleLink Gateway

MacAppers and Apple Decison Makers,
 
To follow up on Jeff Alger's comments concerning Apple overhauling the pricing
structure and continuing with MacApp/Bedrock:
 
Apple:
Yes, we asked for cross platform development, faster compiler times, better
tools, etc. BUT we did not ask for SYMANTEC to provide it. I would like to see
Apple support Bedrock/MacApp by taking the lead in product development,
ownership, support, and transition from MacApp to Bedrock. I would like see
MacApp 3.0x releases and bug fixes (on ET0) until Bedrock ships. You have a
large investment in MacApp and so do we. We are very willing to let it evolve,
but Apple might be the right one to make it happen. I do not feel comfortable
waiting for Symantec to release Bedrock. The last time THINK worked with MacApp
was version 2.0x wasn't it?
 
MADA, or any other type group, can't support MacApp IMHO. Apple makes a lot of
statements about the importance of developers and here's a chance to prove it.
Give us the tools to "break on through to the other side" with you. Many of us
subscribe to ETO to have one-stop-shopping for our tools. Don't change this.
 
As many times as Apple has spun-off and returned Claris, there should be some
precedent set for recognizing a mistake and correcting it. End this platform
confusion and provide developers a path for the future.
 
Thanks,
 
Ken Duncan
From: D4887@AppleLink.Apple.COM (Advanced Comm Eng, G G Apple,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Performance tests...
Date: 26 Dec 92 22:19:00 GMT
Organization: AppleLink Gateway


 
----------------------------------------------------------------------------
>I have read in the THINK Pascal oop Manual (page 24) that oop is
>not really suited for highly algorithmic applications... It is not
>suited for computational programs...
 
    Au contraire, In my opinion, OOP is the only reasonable (and most useful)
way to do highly algorithmic applications.  However, doing so sometimes
requires a differently way of lookiing at your algorithms.  A few years ago,
before I got involved with the Mac, I developed a highly flexible universal
(ok, at least versatile) non-OOP modem simulator in Turbo Pascal on the PC for
a spook project.  This was a highly algorithmic program intended for long Monte
Carlo simulation runs.  I later ported it to run in a terminal window in Turbo
Pascal on the Mac.  The biggest change was when I later used Prototyper to
expand it and turn it into a real Mac application that was event driven with
Mac look and feel and Multifinder friendly.
 
    A friend of mine was doing DSP-32 cards for the PC.  I wrote some drivers
and we got a Mac Nu-bus card together using the same DSP.  After getting
somewhat familiar with MacApp, I realized the immense potential for OOP in this
environment and wished I would have had it when I was systems manager of a
program that used the world's most powerful DSP (a VHSIC processor for MILSTAR
ground terminals).  I then did the MacApp 2.0 graphical block-linking program
that is demoed on the Phoenix MADA CD.  Due to other priorities, we never got
the Nu-bus DSP and the block-linking program together.  One of my goals has
alwas been to get the modem simulator program running on a DSP, marry it with
the graphical block-linker, and get the whole mess into MacApp 3 (maybe BedRock
by then).  This would give us an extremely high level of simulation flexibility
that would be difficult or impossible to acheive otherwise.
 
    The point is that OOP is a very critical component of this endeavour and
now I would not even consider doing it any other way.  I fully expect that
there will be no algorithmic performance degradation whatsoever because any
OOP-performance hits will be mainly in the interface and control, not in the
core algorithm code.  If designers are taking performance hits, its because
they simply don't know how to design algorithm code to work properly in an OOP
environment.
 
    If I had time, I would write a book on this subject.  Just don't let anyone
disuade you from using OOP for algorithm-performance reasons.  You simply have
to know how to use it.
 
G. Gordon Apple, PhD    D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA
From: KVICTOR@AppleLink.Apple.COM (Victor Consulting, Ken Victor,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: TPopup not drawing properly
Date: 27 Dec 92 01:27:00 GMT
Organization: AppleLink Gateway

I'm having a slight problem with some popups in a dialog.  I have 3 TPopups in
a moveable modal dialog box.  If i bring up another moveable modal dialog
window on top of this first mm window, when i closeandfree the 2nd mm dialog,
the popups in the bottom (1st) window are greyed out when they shouldn't be.
 
the interesting thing about this is that if i do a process switch while my 1st
window is up, when i return to my app, the popups are properly black, and not
grey.
 
i've traced this as far as Draw1Control (in the toolbox) which seems to be
drawing it grey...
 
any clues? help? advice?
 
thanx,
Ken Victor
(415) 964-9870
From: KVICTOR@AppleLink.Apple.COM (Victor Consulting, Ken Victor,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: TPopup not drawing proper
Date: 31 Dec 92 02:12:00 GMT
Organization: AppleLink Gateway

here's a copy of the response i got from matt clark (thank you) and my response
to him.
 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Item    6800549                         29-Dec-92        09:18PST
 
From:   D3423                           MapPower, Victor Siegle,PRT
 
To:     KVICTOR                         Victor Consulting, Ken Victor,PAS
 
------------------------------------------------------------------------------
 
Sub:    Re: TPopup not drawing properl
 
I  have had this problem in the past.  I remember it beling related to not
having the Popup 'MENU' resource number listed under the 'MBAR' resource.
Here's a snippet from an application of ours.
 
//  file: App.h
#define mPreferences   28    //Preferences
#define mHlpFontName   1000  //help font name
#define mHlpFontSize   1001  //help font size
 
//  file: MApp.r
resource 'MBAR' (kMBarHierarchical, "kMBarHierarchical")) {
   { //pull-right menus
     mPreferences;
     //popups
     mHlpFontName; mHlpFontSize;       //   LIST ALL POPUPS USED HERE
   }
};
 
Also, don't forget to make the MenuID equal to the menu resource number
(modifiable using ResEdit).
 
Good luck.
 
Matt Clark, MapPower, AppleLink:D3423
 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Item    0598836                         30-Dec-92        18:04PST
 
From:   KVICTOR                         Victor Consulting, Ken Victor,PAS
 
To:     D3423                           MapPower, Victor Siegle,PRT
 
------------------------------------------------------------------------------
 
Sub:    Re2: TPopup not drawing proper
 
Matt,
 
thanx for your link re: popups not drawing properly.  it fixed my problem!!!
 
The real problem was that my popups had a menuID and resource number <
mLastMenu.  When I increased this to 1000+ it solved my problem.
 
BTW, in MacAPP 2, popups needed to be in the kMBarNotDisplayed MBAR resource
and NOT in the kMBarHierarchical resource.  If they were, you would get
unexplained crashes when dismissing a dialog that had popups.  I haven't looked
at the MacApp 3 code to know if this is still the case.  But, they seem to work
properly in kMBarNotDisplayed.  (They also seemed to work in kMBarHierarchical
as in your example, but i personally feel more comfortable with them in
kMBarNotDisplayed).
 
Thanx again,
Ken Victor
From: JOHN.OLSEN@AppleLink.Apple.COM (Olsen, John D,APD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Saving in Excel format?
Date: 28 Dec 92 23:09:00 GMT
Organization: AppleLink Gateway

Hi,
 
I have recently begun to deal with this problem myself.
 
First get the MS Excel SDK from Microsoft or your local Computer Literacy et.
al. (if you  are lucky enough to live near one).
 
Second decide what you want to do -- if all you want is to import _DATA_ (i.e.,
no formulas, formating, etc...) then it is easy to handle via the type/creator.
If you want to get more complex then dig into the BIFF section (Binary
Interchange File Format) and get ready to byt swap everything since the default
is DOS/Intel file format with the bytes reversed.
 
The SDK is very typical of Microsoft -- fairly complete reference but no good
examples to tie it all together. They do include a disk but the last version I
had did not deal with BIFF at all (I had the last beta before final and have
not yet gotten my final.)
 
Good luck,
 
John.Olsen
 
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: Sat, 26 Dec 1992 02:23:47 GMT

      The fact that Apple has announced the demise of MacApp before
Bedrock is even released is a bad sign.  Remember, Bedrock is still
vaporware.  Before Symantec can deliver a development environment,
they must 1) come up with a usable C++ compiler for the Mac platform, 
something they have not yet been able to do despite acquiring Zortech,
2) integrate that compiler with some kind of environment, probably the
one from Think C, 3) make Bedrock work in that environment, and 4)
produce a manual that makes these tools usable.  

      These tasks may take a few years to complete.  It's entirely
possible that there will be a long hiatus during which there will be NO
commercially supported tools for the development of complex Mac
applications.  This can only accelerate the move to Windows.

      Yes, Symantec could sell Bedrock for use with MPW/C/Cfront,
but that would make the market so small that Bedrock wouldn't sell
through Symantec's dealer channels, just as MPW doesn't sell through
dealers.  Symantec wouldn't derive any marketing advantage from their
established dealer channels, and they aren't set up for high-priced
low-volume products sold through an in-house sales force.  So that
doesn't make business sense.

      It's almost as if Apple were killing off the Mac, like they
killed off the Lisa.  Is Scully really betting the company on 
Power PC, the "strategic alliance" with IBM, and "personal digital
assistants"?  Some published interviews indicate that he is thinking
along those lines.  

      Apple has not yet provided a credible statement of direction 
which would encourage developers to continue investing effort in
its Mac platform.  Perhaps it will do so.  Meanwhile, the Windows
development kit is widely available at low cost.

					John Nagle
From: H_HADDON@ACAD.FANDM.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Bedrock News
Date: 22 Dec 92 13:50:00 GMT
Organization: AppleLink Gateway

From: H_Haddon@ACAD.FANDM.EDU (Harry Haddon, F & M College)
Content-Transfer-Encoding: 7BIT
To: MACAPP3TECH$@AppleLink.Apple.COM
 
The proposed price tag (10K or higher) would surely keep us from using
Bedrock unless they offered a 95% discount for educational users
(seriously!). Education is not the only market that may be affected by a
high price tag - small in-house developers and struggling consultants are
two others that come to mind.
 
MacApp has been an excellent framework for educational software
development, allowing me to turn out full-featured Macintosh applications
in less time than conventional development methods. Cross-platform
development is not that important to us, but being able to take full
advantage of new Macintosh features such as QuickTime, OCE, etc. is.  We
need a framework that keeps pace with the latest Macintosh developments and
fully supports them as they are released. We would also like to be able to
sell our applications to other institutions without framework royalties.
 
Does anyone know who at Apple or Symantec is involved with establishing
licensing strategies for Bedrock? An e-mail address would be great.
 
Harry
From: D0220@AppleLink.Apple.COM (American Zettler, David Every,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Bedrock News & Beyond
Date: 21 Dec 92 17:57:00 GMT
Organization: AppleLink Gateway


    I would imagine a Taligent Based Framework, would have a lot in common with
MacApp (considering where many of the people came from)... the difference
probably being that the OS (and its routines) are optimized for the framework
(or are part of the framework itself). So this is where I want to be.... when
it becomes availible... and of course there will be a couple of years lag time
until the new computer/OS is accepted at large.
 
    The toughest part OOP is all the lost productivity. Yes, MacApp is saving
me time over traditional procedural developement... and it has sheltered me
from the toolbox (somewhat)... now I get to spend my time figuring out how the
framework wants something done, instead of how the toolbox wants something
done... and when I go to a different framework I get to learn it over again. I
have gained productivity short term, and been given a taste of the future...
but like giving a starving child a single meal, what about tommorow?
 
    There is Component Workshop, which I hear from everyone is great... except,
it is too damn pricey for the average small developer. Which (to me) means it
is unlikely to be accepted as a standard. And if it isn't likely to become a
standard, why would I spend my time learning an environment that wont help my
Resume? And this also brings up the question about how long the company will be
around (do we really need another proprietary, high priced development
environment, even if it is really good?)... Instead of trying to grab market
share the company is trying to make money off a first generation, unproven,
product... good luck... I sincerely hope they have good V.C.
 
    MacApp... apple has let the ball drop on 2.0 (no support, or good
translation tools)...  we hear the same for 3.0... but its O.K. because we have
Bedrock (Yet another framework). At least this framework is cross platform, so
it will look good on a resume, and there is a chance that the development
environment will be easy to work with. Think-Environments are easy(er) to work
with than MPW. (MPW is fine, but just a tad archaic... ObjectMaster is good
editing, but is not an integrated environmnent... and many things, like
renaming a method are still an impossibility (more work than its worth).) Of
course Bedrock is not optimized for Macintosh/Toolbox, nor is it optimized for
an OOP based OS... and things us OOP developers need, like; dynamic linking,
auto-magic memory/object managment, source code, and cheap licensing fees, and
a low cost environmnet... are still a huge '?'
 
    But we should wear peril sensitive sunglassed (the kind that turn black
when danger is near, so we dont have to see it)... Dont look towards tommorow,
face the day, and be thankful for the OOP tools you've got.
 
 
    Dave Every.