HDTenEightyP/NetNews huggingface dataset:
From: D4887@AppleLink.Apple.COM (Advanced Comm Eng, G G Apple,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: HC XCMDs in MacApp 3?
Date: 17 Dec 92 00:05:00 GMT
Organization: AppleLink Gateway


    Has anyone done a HyperCard XCMD interface for MacApp 3.0?  I know there
was something called XLink Access, but I haven't located it yet and don't know
if it would do what I want anyway.  I want to be able to include XCMDs such as
the PlayMovie XCMD for MacroMind Director.  Thanks.
 
G. Gordon Apple   D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA
From: GILLAM.R@AppleLink.Apple.COM (Richard Gillam,GEIS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Bedrock News
Date: 17 Dec 92 15:15:00 GMT
Organization: AppleLink Gateway

Vinko--
 
I'll second both of your comments.  I think the comments about what the
development environment ought to be are pointing right to Component Workshop.
I've seen it demonstrated, and it seems to be frialy immature, but with amazing
potential.  I hope it gets the market it deserves.
 
As for the second comment about carrying the framework around as part of the
operating system, this seems to be pointing toward SLM.  One of the things SLM
will hopefully give us is the ability to have all our MacApp (Bedrock) code in
a DLL, rather than carried individually with every application.
 
Rich Gillam
GE Information Services
From: DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Memory Leaks
Date: 12 Dec 92 20:28:00 GMT
Organization: AppleLink Gateway

Hi Peter,
 
On the Developer CD's, there is *somewhere* a 'dcmd' 'Leaks' which should be
copied/pasted into the 'Debugger Prefs' of MacsBug.
I didn't have time/occasion to experiment with this.
 
Hoping this hint helps!
Willy
From: BARBOSE@AppleLink.Apple.COM (Amoco Technology, Jeff Barbose,VAR)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: TDialogView in Ad Lib
Date: 15 Dec 92 23:27:00 GMT
Organization: AppleLink Gateway

Ken,
 
In the attribs window, make a window a Dialog by clicking the radiobutton
"Dialog".
 
This doesn't make it a TDialogView, but rather adds a TDialogBehavior to the
window's/view's behavior lists.
 
Voila!  Instant dialog.
 
Jeff
 
Newsgroups: comp.sys.mac.oop.macapp3
From: ksand@apple.com (Kent Sandvik )
Subject: Re: Stack size in MacApp
Date: Wed, 16 Dec 1992 00:31:09 GMT
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.macapp3

In article <724452986.7524418@AppleLink.Apple.COM>,
D6431@AppleLink.Apple.COM (OptImage Interactive Svcs,PRT) wrote:
> I need a Large stack in my MacApp Application.  Is there any way I can increase
> my stack size on application start up??

No problems, actually the stack is set to 24k by default. Look inside the
MacApp library, in the Memory.r file, and you should find the 
following resource:

resource 'mem!' (kBaseMacApp,
#if qNames
	"BaseMacApp",
#endif
	purgeable) {
	6 * 1024,		// Add to temporary reserve
	6 * 1024,		// Add to permanent reserve
	24 * 1024		// Base stack size. MacApp sums this entry for all 'mem!'
resources to
                    // determine what it should set the stack limit to at
application
                    // startup.
};

Copy that one to your .r file, modify the stack size to your liking
and Rez.

I actually recommend exploring the library folder, like the Memory.r
and the Defaults.r files. You could take stuff/resources, and modify them
to
your liking.


Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
From: DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: TAppl.InstallCohandler mo
Date: 11 Dec 92 18:04:00 GMT
Organization: AppleLink Gateway


 
Indeed, Mark, debug versions (of frameworks and our own applications - MacApp
and others) should be defensive programmed (which save a lot of time), i use
the following technique taking your example:
 
TFoo::Something()
{...
#if qDebug
   if (!IsObject(aCohandler)) {
     SysBreakStr("TFoo::Something - aCohandler is invalid!");
    return; }
#endif
...
}
 
I prefer to jump into SADE with an own error message (eventually with the
returned OSErr error-code) than wasting my time searching the reason of the
crash which can occur later. I use the same technique before calling Failures
(Failure statement outside the if/endif).
 
SADE must be started up, but i think this is no problem because when working
with MacApp 3.x, we need a lot of meg's (i don't like limited resources! - *The
sky's the limit!*).
 
Of course there are alternatives (jumping into MacsBug, ...).
 
Willy
From: GER.XSE0039@AppleLink.Apple.COM (Germany - C Brinkschulte Berlin,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Bug In TDynamicArray (MA3.0.1)
Date: 15 Dec 92 17:19:00 GMT
Organization: AppleLink Gateway

Hi, MacAppers,
 
There is a Bug in MacApp 3.0.1 in the class "TDynamicArray".
 
The problem arises when a TDynamicArray is cloned while an Iterator which was
used for the TDynamicArray is stil in scope. TDynamicArray has a field named
fIteratorPtr, which contains a linked list of Iterators currently in use for
the TDynamicArray. When a TDynamicArray gets cloned, both (the old and the
cloned Array's) fIteratorPtrs point to the same Iterator. If the CArrayIterator
is destructed, the fIteratorPtr of the cloned TDynamicArray points to an
invalid Memory-Address.
 
The solution is to override TObject::Clone in TDynamicArray and set the
fIteratorPtr-field of the cloned Array
to NULL.
 
TObject* TDynamicArray::Clone () // override
{
    TDynamicArray* clonedArray = (TDynamicArray*) inherited:Clone ();
    clonedArray->fIteratorPtr = NULL;
    return clonedArray;
}
 
A Workaround is to manually set the fIteratorPtr of the CDynamicArray to NULL
after cloning a TDynamicArray.
 
TDynamicArray* aDynamicArray = new TDynamicArray;
aDynamicArray->IDynamicArray (0, sizeof (myStruct));
 
[...]
 
TDynamicArray* clonedArray = aDynamicArray->Clone ();
clonedArray->fIteratorPtr = NULL;
 
 
I am not part of MacAppTech$ anymore, because it has flooded my In-Box too
much, so please send a copy of any replys directly to me (thanks).
 
 
Carsten Brinkschulte
GER.XSE0039
From: shaevel@Apple.COM (Jeff Shaevel)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MacApp or MPW?
Summary: Which to use?
Date: 15 Dec 92 05:50:03 GMT
Organization: Apple Computer Inc., Cupertino, CA

I'm an experienced Unix C programmer looking to get into serious
Macintosh C and C++ programming, but I can't quite figure out 
whether I should get MacApp or MPW.  Any hints?  Suggestions?

Please e-mail, since I have little chance to read news, but would
appreciate exchanging e-mail with anyone who has a second to discuss
this matter with me.

Thanks.

Jeff
shaevel@apple.com
-- 
===================================================================
Jeff Shaevel        :-)-: (comedy/tragedy)    Love may be blind, 
shaevel@apple.com                             but lust is autistic.
"Hey! Shut up you STUPID OLD BITCH!" - Tony Whitcomb, SHEAR MADNESS
From: EDS.TECH.DEV@AppleLink.Apple.COM (EDS, Doug McCubbrey,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Adlib Questions
Date: 15 Dec 92 00:45:00 GMT
Organization: AppleLink Gateway

Nick, or anyone,
We have been using AdLib as our prototyping tool lately.  Its pretty cool.
The handlers are great, however we have ran into a slight problem.  We have
5 people working on our prototyping effort.  We have divided up the effort
so that each person has a range of resource ids to work in, including BHVR ids.
This results in an app with BHVR resources of several ids. It looks like only
the handlers of the first resource id, i.e. 1000, ever get called.
For some reason the handlers from the other ids do not seem to be getting
called.
 
Has Anybody seen this before, and if so, is there a clean fix.  If not, could
we get the template for the BHVR resources so we could write a tool to combine
them into a single resource at rez time.
 
Thanks,
Chip Schoch , EDS
From: MADA@AppleLink.Apple.COM (MADA Admin, Steve Mann,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MADA Meeting at MacWorld
Date: 17 Dec 92 16:33:00 GMT
Organization: AppleLink Gateway

MADA will be hosting a meeting at MacWorld in San Francisco in Moscone Center's
room 252, Wednesday January 6 at 7 PM.  Speakers will include representatives
from Component Software, Sierra Software Innovations, and Electron Mining.  It
should be an excellent agenda.
 
We will also be showing our face to developers Wednesday Jan. 6th and and
Friday Jan. 8th from 10AM until noon at APDA's Developer Support table in the
tools exhibit.  Stop by and say hello.
From: GILLAM.R@AppleLink.Apple.COM (Richard Gillam,GEIS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Getting idle time in a view
Date: 15 Dec 92 18:48:00 GMT
Organization: AppleLink Gateway

Hail, O gods of MacApp programming--
 
My application has a window with a number of views in it.  One of those views
needs to get idle time so that a visual element within it can be animated.
This view is not the target view of the window; it is a peer to it.
 
Because the view is not in the target chain, it doesn't get time automatically.
And if I try to put it into the cohandler chain, all kind of things get messed
up, and I wind up in an endless loop that eventually crashes the system with a
28 error.
 
What's the right answer?  I never want the animated view to be the target view,
because clicking on it doesn't do anything, but I don't know how to make it get
idle time.  Am I missing something obvious here?  I can't believe the people
who designed MacApp didn't account for this case.
 
How do I do what I want to do here?  Please enlighten me.
 
Rich Gillam
GE Information Services
From: NAVARRETE@AppleLink.Apple.COM (Navarrete, Ed)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: EMail etiquette proposal
Date: 19 Dec 92 00:02:00 GMT
Organization: AppleLink Gateway

hello,
 
Due to the tremendous number of e-mails I get everyday I would like to suggest
some guides that could be used on MacAppTech$ when sending links.  Maybe this
could come up for discussion at the MADA meeting at SF MacWorld.  I think the
reason most people leave Tech$ is due to the load and losing private E-mails.
By following some guidelines I think this would help decrease this frustration
level.
 
Ed Navarrete/DTS
Apple Computer, Inc.
 
This is from a set of guidelines proposed at Apple:
 
===================================
 
 
E-mail overload faces all of us, and a great number of messages do not directly
contribute to the ongoing successful of our jobs.  In addition it is often
difficult to determine the content of an e-mail from the title alone.
And in order to maintain a high level of responsiveness we need to be able to
filter the highest priority e-mails by scanning the titles/subject heading.
 
o Here are the guidelines:
When addressing an e-mail message please begin the title/subject line with one
of the following prefixes...
 
  Prefix    Meaning
  FYI:      For Your information, non-essential info, but of possible interest
  PI:       Personal information directed to an individual, no response req'd
  R:        This e-mail requires a direct response and is required reading
 
If you send an e-mail message to more than one person, add a "$" to the prefix
to indicate that the e-mail is being broadcast to a group.
 
In addition, if the e-mail involves a deadline, please include that date.  If
you see a date in the title/subject line of an e-mail, always consider it to be
the deadline, schedule or due date.
 
   Examples:  FYI$:  Local MADA meeting
              PI$: Thank you for your response
              R$: How do I ...
 
Finally, please consider these 'e-mail etiquette' ideas when creating mail:
 
o One-minute-emails! - develop the practice of writing e-mails that fit on one
page and can be read in under a minute.  Enclosed longer documents if needed.
o Intelligible titles - make sure the title makes sense and gives a hint at the
content of the link (i.e. "I'm at Comdex till 1/22", _not just_ "Outta here!").
o Assume appreciation - respond to e-mails with _content_ only; simple "thank
you for your reply" messages are not needed (unless really called for).
o Compress wisely - do not compress small files (i.e. under 100k) as this
requires several extra steps for the reader to download, decompress and read.
From: VELOCIO@AppleLink.Apple.COM (Maurer, Joseph)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Re[2]: password in MacApp
Date: 11 Dec 92 17:43:00 GMT
Organization: AppleLink Gateway

Robert,
 
AddResMenu(mh,'FONT') has a not-so-well-known property hardcoded into it, that
allows you to make some fonts "invisible": Font names starting with a "." (like
driver names) or with a "%" will not be included in the menu!
 
Hope that helps(tm),
 
Joseph Maurer
From: DIGIMATCH@AppleLink.Apple.COM (3M, Ran Bedekar,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: TDialogView in Ad Lib
Date: 16 Dec 92 13:22:00 GMT
Organization: AppleLink Gateway

Ken,
 
> How would one assign a target in TWindow?
 
Select the window, and choose TWindow from the 'Class Hierarchy' menu.  This
will bring up a dialog with all of the TWindow fields including the target ID.
 
Regards,
Nick Nallick
From: DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: EMail etiquette proposal
Date: 19 Dec 92 14:34:00 GMT
Organization: AppleLink Gateway

Hi all,
 
> I think the problem "in the large" is an AppleLink problem ...
 
Right! During daytime i'm working with the MEMO-software of VOLVO-VERIMATION.
In this software, it is possible to divide my memo's into *files* (groups),
thus possible to select, download, ... only those memo's with specific *file*-
ID('s).
 
I know this is a (big) change in AppleLink, but using this we (or AppleLink)
can select, download the links into folders (within a specific folder - ie *
Mailings*) with names equal to the ID (ie MacApp2, MacApp3, Bedrock, C++,
ViewEdit, MADA, Jobs, BAMADA, *Mac Toolbox Component*-names, APDA, ...).
And since we are *limited* to 31 characters, it is possible to suffix the names
with ie Problems, Questions, Bugs, Info, News, Meeting, Hints, ...
Of course here we are again: naming conventions ...
 
This is only a rainy dark saturday idea ...
Still ... learning a little bit ...
Willy
From: ENS.CC@AppleLink.Apple.COM (ENS Computer Consulting,CAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: TPopup Testing
Date: 16 Dec 92 23:07:00 GMT
Organization: AppleLink Gateway

Attn: MacApp 3.0 Tech $
SentBy: Paul Ens
 
TPopup Testing                                       12/16/92   10:53 AM
 
Holiday Greetings everyone,
 
I have a TPopup that uses a MenuHandle that has its various menu items
enabled/disabled by a number of sources. Anyhow, when I show a popup with this
MenuHandle on a dialog box, I want to default it to the first enabled menu
item.
 
How do I test a MenuHandle (or a TPopup) to see if an item is dimmed or not?
The toolbox provides Enable/DisableItem routines, but not a GetDimStatus
routine. I can't seem to find anything in MacApp itself that allows me to
check this.
 
Ideas?
 
Thanks so much,
 
Paul Ens
ENS Computer Consulting
Saskatoon, Sk CANADA
 
Newsgroups: comp.sys.mac.oop.macapp3
From: ksand@apple.com (Kent Sandvik )
Subject: Re: EMail etiquette proposal
Date: Sat, 19 Dec 1992 22:19:11 GMT
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.macapp3

As in any organized anarchical environment it's really hard to define
any rules. All we could hope is that people appreciate and understands
the other end concerning  net etiquette.

However, I do think that it would be handy is someone should post monthly
a summary of the most asked questions, style:

* What's the admin address for our group that one sends a message to to
join
this group?

* Who should you post if you want to terminate your MacAppX.Tech$
membership?

And in addition, all the classical 'memory exhausted', "TDialogView does
not
work", and so on questions.

I'm sure that would to some degree help concerning cleaning up the amount
of postings. I would like to start doing it, but due to organizational
changes and PowerPC work over here I don't have any spare time. Yes, I'm
moving
to another engineering department...

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
From: D6431@AppleLink.Apple.COM (OptImage Interactive Svcs,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: includes in CPlus
Date: 18 Dec 92 16:56:00 GMT
Organization: AppleLink Gateway

Help!! I Have a MacApp Problem;
 
I am trying to compile my MacApp program with additional custom C libraries
that were created in MPW C. The Libraries and their header files are stored in
a seperate directory on my drive. I added to my .MAMake file the line:
 
    OtherCPlusOptions = -i "MyHardDrive:Additional_Header_for_My_C_Libraries"x
            -i"MyHardDrive:Still_More_Additional_Header_for_My_C_Libraries"
 
This enabled the CFrontTool to find header files from these external libraries
that I included in my .cp files that it normally would not find.
 
Here is the problem: in these C Library header files that I'm including, they
contain addtional includes of their own (These C Libraries that I'm using are
arranged in a complex yet elegant network in their directory; there are many,
many libraries and they all work off each other).  These include statements
contain not just the name of the header file to include but also a partial path
name.  The CFront tool doesn't like these partial path names!!  It likes full
path names or even root file names, but it chokes on partial path names and
says it cannot find the file.  Why does the MPW C compiler accept partial path
names in the include statements but the CFront tool chokes on them.  I'm trying
to avoid changing the include statements because there are hundreds of files to
contend with.  My colleage that wrote these libraries had no way of knowing
that the partial path names would cause me problems in MacApp, because as I
mentioned above the MPW C compiler doesn't.  Is there some way I can tell the
CPlus Tool to accept partial path Names??? Any help would be much appreciated.
 
Jay Bartot @OptImage Interactive Services
 
Newsgroups: comp.sys.mac.oop.macapp3
From: ksand@apple.com (Kent Sandvik )
Subject: Re: Getting idle time in a vie
Date: Wed, 16 Dec 1992 00:26:06 GMT
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.macapp3

In article <724446629.4345396@AppleLink.Apple.COM>,
SCHALK1@AppleLink.Apple.COM > By the way, the cohandler chain works as
well, but is not the preferred way of
> doing things (maybe you get the crash because you forget to remove the
> cohandler when you close the window?).

Long time ago (12 months feels like eternity in this business) the story
was that cohandlers should be reserved for framework internal use, and 
behaviors is the way to go. I'm not yet sure about all the issues
related to Bedrock transitions, but so far using behaviors is also
a possible good idea for 'you know what'.

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
From: SCHALK1@AppleLink.Apple.COM (Euro Tech Svcs, OOP Spec)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Opening Files using MacApp
Date: 15 Dec 92 18:31:00 GMT
Organization: AppleLink Gateway

Ett,
 
That's a good solution. You can use TFile.SpecifyWithTrio() to initialize a
TFile object with the volume, folder and name (I presume you already have that
information). Use TFile.ReadData() to read from the data fork.
 
There is also a global routine TFile *NewFile() that can be used to create a
TFile object.
 
Regards,
 
Jeroen Schalk
Object Programming Specialist
European Technology Services
Apple Computer Europe
From: ksand@apple.com (Kent Sandvik )
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: SLM & Dinker
Date: 15 Dec 92 00:45:26 GMT
Followup-To: comp.sys.mac.oop.macapp3
Organization: (Evil Eye Creature from Mars, Inc.)

In article <724362445.5470812@AppleLink.Apple.COM>,
D4978@AppleLink.Apple.COM (Third Point Sys, Thomas Collins,PAS) wrote:
> Is there a difference between SLM and Dinker or could one consider SLM a
> superset of Dinker?

Dinker and SLM are two very different concepts. They have both overlapping
features and things that the other part does not. Dinker is not supported 
by Apple. SLM is.
  

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
From: WVUCENIC@AppleLink.Apple.COM (No Bugs SW, Wayne Vucenic,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Bedrock Alpha by '93 WWDC
Date: 16 Dec 92 05:33:00 GMT
Organization: AppleLink Gateway

I just got back from a public meeting at Apple with Karl May of Apple, and
Steve Levine, Symantec's Bedrock Product Marketing Manager.
 
Unfortunately, the meeting was pretty non-technical (discussions of why you
would want to use an application framework, and why Apple and Symantec are
working together, etc.)
 
I did hear two things that I haven't heard before:
 
1) Source code will be available, but maybe not as part of the standard
product.
 
2) The "goal" is to have an early developer's release (basically an alpha) for
the Mac and for Windows, in time for the 1993 WWDC.
 
 
Wayne Vucenic
No Bugs Software
"Mac Contract Programming in Silicon Valley Since 1986"
From: to5232@iscsvax.uni.edu
Newsgroups: comp.sys.mac.oop.macapp3
Subject: What is MACAPP?
Date: 20 Dec 92 17:20:53 -0600
Organization: University of Northern Iowa

Can someone explain to me what is MACAPP?  I am new to this newsgroup and I
seem to get the impression that MACAPP is a development program.  Please E-Mail
explanations to me, unless of course you feel that this type of explanation
would benefit the group.

Thanks,
From: DJDE@AppleLink.Apple.COM (Don Johnston Dev Equip,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: address
Date: 18 Dec 92 16:20:00 GMT
Organization: AppleLink Gateway

To the great members of MacApp3Tech$:
 
    What's the admin address for our group that one sends a message to to join
this group?
 
                        John Burkey
                        Software Engineer
                        DJDE
From: MADA@AppleLink.Apple.COM (MADA Admin, Steve Mann,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Job Openings
Date: 19 Dec 92 00:48:00 GMT
Organization: AppleLink Gateway

*******************************************************************************
MADA MAKES NO WARRANTIES ABOUT THESE POSITIONS OR THE HIRING FIRM. WE PROVIDE
THIS LISTING MERELY AS A SERVICE TO THE MACAPP COMMUNITY.
*******************************************************************************
Decision Consultants Inc. is looking for 6 MacApp Programmers in Dallas, Texas.
Call Bernadette at 214/386-8777, fax your resume to 214/386-0741, or mail your
resume to DCI, 5000 Quorum, 410, Dallas, TX 75240.