HDTenEightyP/NetNews huggingface dataset:
From: ARTMA.DEV@AppleLink.Apple.COM (ARTMA Med.Tech.B Glattfelder,AT,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Getting idle time
Date: 16 Dec 92 16:08:00 GMT
Organization: AppleLink Gateway


 
>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.
 
The solution as well as the problem actually are contained in this statement:
the visual element is to be animated, so it is the one who needs to get idle
time. If it's feasible to introduce an auxiliary object deriving from
TEventHandler in your design, this is an easy way to go. I have chosen that
approach for playing movies in MacApp, where a TMovie object gets installed as
a cohandler to animate the owning view (its theater).
 
Of course the first candidate object to handle idle messages that comes to a
MacAppers mind is the view, but the target management of MacApp uses the same
links in its chain as the cohandlers, and because a TView object always gets
its Superview as its next handler, you would insert all the event handlers up
to the TApplication object into the cohandler chain. Whether that's a good
design is an other issue.
 
Now if the view really doesn't want to be target, you could probably detach it
from its superview and install it as a cohandler to the application.  I don't
encourage anybody to do so, and neither did I, but after some MacBrowse
sessions I got pretty shure that setting the fNextHandler to  nil before
calling gApplication->InstallCohandler should do the job.
 
Good luck
 
Beat Glattfelder
ARTMA Biomedical Inc.
From: DRAPER@ODIN.MDA.UTH.TMC.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Re2: Bedrock News
Date: 18 Dec 92 16:25:00 GMT
Organization: AppleLink Gateway

>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 amaz
ing
>potential.  I hope it gets the market it deserves.
 
I'm very interested in Component Workshop.  Could you (or someone else
perhaps) elaborate on its content and structure.  They (the people who
wrote it) claim that it's very similar to MacApp.  Is anyone out there
using it?
 
 
 
 
 
 
      |E|J-  ED DRAPER
 rEpar|D|<-  Radiologic/Pathologic Institute
             The University of Texas M.D. Anderson Cancer Center
             draper@odin.mda.uth.tmc.edu
From: MAILER-DAEMON@alink-gw.apple.COM (Mail Delivery Subsystem)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Returned mail: Unable to deliver mail
Date: 13 Dec 92 20:11:47 GMT
Organization: AppleLink Gateway


   ----- Transcript of session follows -----
554 POST-MACAPP-BETA-3... Recipient names must be specified

   ----- Unsent message follows -----
Received: by alink-gw.apple.com (5.65/27-Sep-1991-eef)
	id AA11336; Sun, 13 Dec 92 12:11:47 -0800
	for 
Date: 12 Dec 92 23:28 GMT
From: Gateway@AppleLink.Apple.COM (to Internet/BITNET/UUCP)
Subject: Re: Memory Leaks
To: MACAPP3TECH$@AppleLink.Apple.COM (MacApp 3 Technical Discussion)
Message-Id: <9212131953.AA24329@apple.com>
X-Original-Document-Id: <9212131953.AA24329@apple.com>

From:
Organization: (Evil Eye Creature from Mars, Inc.)
To: MacApp3Tech$@Applelink.apple.com
 
In article <724192662.2890464@AppleLink.Apple.COM>,
DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD) wrote:
>
> 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.
 
The Swatch application is also handy for finding about leaky apps, just let
it
run in a window, and check out if the free heap numbers are mysteriously
ticking down even if you are not doing anything.  Even better, if you could
figure out the size of the chunks that decrease, it might even give an
indication what is really leaking (sometimes).
 
Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
From: PARKS.W@AppleLink.Apple.COM (Parks, William,APD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: TEditText Cursor color???
Date: 16 Dec 92 03:15:00 GMT
Organization: AppleLink Gateway

Hello,
 
    I have tried to add a color background to a couple of dialogs.
 
    These dialogs have several TEditText views. The cursor in the TEditText
views is diplayed in the same color as the subviews color which makes it hard
to see. How do I change the cursor's color back to black?
 
    This seems like it ought to be relatively easy but I'm stumped.
 
                Suggestions would be appreciated. Thanks
 
 
                            Bill Parks
From: D1037@AppleLink.Apple.COM (Jasik Designs, Steve Jasik,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: 12/11/92 Dbgr update notice oo
Date: 11 Dec 92 18:29:00 GMT
Organization: AppleLink Gateway

To all Jasik debugger users,
 
Seasons Greeting,
 
I have posted a patch file to 'The Debugger' in the
'Debugger Discussion' form.
 
path =
'Developer Support:
   Developer talk:
     Debugger discussion:
     The Debugger discussion:12/11/92 Jasik patch file
 
A) It contains a newer version of PatchLink that supports
segments > 64K and no longer loses the types of local vars
in C and C++ programs that are of the form '^^structName'.
 
-------
 
B) It patches the 10/4/92 version of The Debugger and
   fixes the following problems (newest fixes last):
 
1) Debugger hung when reading a SYM file with C++ names.
 
2) When using System 7.1 with a large number of open files,
The Debugger would blow up when deleting a task.
It was overwriting one of it's internal tables.
 
3) If the name of a procedure exceeded 63 characters, then
 The Debugger blew up when one did a 'command-click' in the source window.
 
4) When booting with 'PC Exchange' or QuickDraw GX installed,
  INITs which used CurApName+8 as a flag for Macsbug would blowup.
 
5) Debugger blows up on 256K ROM Macs (II, IIx, IIcx, SE/30) when
   when running with System 7.1
 
6) Revised handling of the interaction between ObjectMaster & the
   MPW Shell or ToolServer so ObjectMaster is the primary 'Shell'
 
7) Revised handling of Think C V5 projects so Debugger doesn't blow up
   when processing their symbol table.
 
8) Add a new message so that bus Errors at Boot time are less
   mysterious.
 
9) adds logic to support OCE
 
10) adds support for ThC V6-Alpha 1
 
11) May fix problems on Quadra's with AppleShare active
 
ooo ALSO ooo
 
There is a conflict with the new CD-ROM V4 software and The Debugger.
I have tracked it down, and the next release of The Debugger will
 contain a fix to xDbgr_Startup.
 
For now, the way to fix the problem is to load The Debugger BEFORE
Foreign File Access by renaming 'xDbgr_Startup' to '!xDbgr_Startup' or such.
 
 
Steve
From: mspace@netcom.com (Brian Hall)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Bedrock Alpha by '93 WWDC
Date: 16 Dec 92 08:09:23 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

WVUCENIC@AppleLink.Apple.COM (No Bugs SW, Wayne Vucenic,PAS) writes:

>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.)

It is hard to get technical when they are not willing to disclose enough
information to pose intelligent (and technical) questions!

On the other hand, I am sure glad I went.  And it was something to see
(what seemed like )100+ people there.  Most meetings I have attended
hovered in the 25 pern range.

There was also mention made of where TCL fits in, which is a first as far
as I can tell.  All previous announcments only mentioned a MacApp 
migration path.

Brian Hall, M/SS
(working on my third commercial TCL based app)

-- 
 
 \ | /   | Brian Hall                 mspace@netcom.com
 - : -   | Mark/Space Softworks       Applelink: markspace
  /|\    |                            America Online: MarkSpace
 |-+-|   |
/-\|/-\  | PUI: Programming Under the Influence.
From: DIGIMATCH@AppleLink.Apple.COM (3M, Ran Bedekar,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Stack size in MacApp
Date: 16 Dec 92 23:14:00 GMT
Organization: AppleLink Gateway

Actually, you don't have to modify Memory.r in MacApp.  MacApp totals the
values of all the 'mem!' resources in your application.  You can add to the
temporary heap, the permanent heap, and the stack size by adding your own
'mem!' resource.
 
For example:
    resource 'mem!' (1000,
    #if qNames
       "MoreMemory",
    #endif
       purgeable) {
     temp,
       perm,
       stack
    };
 
where:
    temp = number of additional bytes of temporary heap
    perm = number of additional bytes of permanent heap
    stack = number of additional bytes of stack
 
Regards,
Nick Nallick
From: GOLUB@SGI.SIEMENS.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: RE: RE3: Memory Leaks
Date: 14 Dec 92 16:25:00 GMT
Organization: AppleLink Gateway

>Let's not forget ZoneRanger! I find it more useful than Swatch. It has a few
>more features and doesn't need to be loaded as an INIT. Not only can you watc
>memory get eaten up "live" but you can click on the memory and see what's in
>there! Very useful!
 
below is information about where one can find ZoneRanger, as well as a
description of what the utility does.
 
for those of you who use ZoneRanger, the next version will probably wind
up on the net around january, complete with a bunch of cool new features.
 
also, i would definitely check out the 'leaks' dcmd written by bo3b,
available on the developer cds. it will not catch all of your leaks,
but it is quite impressive in the leaks that it does catch. see its readMe
for more details.
 
also, out of fairness, the latest versions of swatch no longer require
an init, at least if you are running 6.0.7 or later.
 
-joshua golub
 
Newsgroups: comp.sys.mac.oop.macapp3
From: gtapolow@nyx.cs.du.edu (Greg Tapolow)
Subject: MAC APP 3, pascal programmer
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Sat, 19 Dec 92 16:19:16 GMT


I've recently updated from Macapp 2 to 3. I program primarily in Pascal as
a hobbyist. Do I still need to purchase MPW C++ to compile my programs?

Thanks
	Greg
--
Begining my quest for the ultimate (working)    Greg A. Tapolow
sig						gtapolow@nyx.cs.du.edu
all rights turned left				probably at albequerque
From: D4887@AppleLink.Apple.COM (Advanced Comm Eng, G G Apple,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Getting idle time in a vie
Date: 16 Dec 92 00:45:00 GMT
Organization: AppleLink Gateway


 
----------------------------------------------------------------------------
>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.
 
    Yup.  That's what happens alright.  This one keeps coming up regularly.  My
advice is don't ever install anything in the cohandler chain except a simple
cohandler object that is subclassed directly from TEventHandler.  Install it
and have its DoIdle call your View's DoIdle.  Remember to deinstall and free it
when you are through with it.
 
G. Gordon Apple   D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA
From: PETER_BOSANKO@qmrelay.mail.cornell.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Memory Leaks
Date: 12 Dec 92 18: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: "LIST... macapp3tech$" <macapp3tech$@applelink.apple.com>
 
GatorMail-Q                   Memory Leaks
Fellow MacAppers...
Is anyone out there aware of any cool tools for hunting down memory leaks?
I've got a nasty one and I'd appreciate a tool that could give me some heap
diagnostics.
From: DJDE@AppleLink.Apple.COM (Don Johnston Dev Equip,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: address
Date: 18 Dec 92 16:26: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: DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: MacApp and CPU caches
Date: 12 Dec 92 14:28:00 GMT
Organization: AppleLink Gateway

Hi Daniel,
 
I'm using own logically segment-names (ie $Menu) and they are specified in the
'res!' and the 'seg!' resources, thus avoiding UnloadSeg.
 
More segment-names results in more overhead (jump-table, segment-to-segment
jump, ..), is this important for the performance of an application?
 
Willy
From: SDOBBS@TRIVIA.COGINST.UWF.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: setting VPoints
Date: 11 Dec 92 22:03:00 GMT
Organization: AppleLink Gateway

I have seemed to found an interesting feature that I have no explanation
for.  I am attempting to create a new VPoint, and give it a value that is
the midpoint of two other points, offset by a certain amount.  Nothing
complicated.  But when I declare the point using the / operator on the
components of VPoint, the VPoint gets the value (43,43), no matter what I
divide by.  Has anyone else seen this?
 
pascal VPoint* TLink::ComputeLocation(VPoint* from, VPoint* to, VPoint* size)
{
 
/*this was my first attempt.  The later section of code is nothing  more
than this
separated out.*/
//      VPoint *location= new VPoint(*from[hSel] / 2 + *to[hSel] / 2 -
*size[hSel] / 2,
//
*from[vSel] / 2 + *to[vSel] / 2 - *size[vSel] / 2);
 
 
       VPoint location =  VPoint(*from[hSel] / 2,*from[vSel] / 2);
 
        VPoint temp =   VPoint(*to[hSel] / 2,*to[vSel] / 2);
        location = location + temp;
        VPoint temp2 =  VPoint(*size[hSel] / 2,*size[vSel] / 2);
        location = location - temp2;
 
        VPoint * loc = new VPoint( location[hSel] , location[vSel]);
 
        return(loc);
 
}
 
Steven Dobbs <sdobbs@ai.uwf.edu>
Institute For Human and Machine Cognition
University of West Florida
Pensacola, Florida
 
Man will occasionally stumble upon the truth, but most of the
time he will pick himself up and continue on.
From: H_HADDON@ACAD.FANDM.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Stack size in MacApp
Date: 16 Dec 92 14:49:00 GMT
Organization: AppleLink Gateway

From: H_Haddon@ACAD.FANDM.EDU (Harry Haddon, F & M College)
Content-Transfer-Encoding: 7BIT
To: D6431@AppleLink.Apple.COM (OptImage Interactive Svcs, PRT)
Cc: MACAPP3TECH$@AppleLink.Apple.COM
 
>I need a Large stack in my MacApp Application.  Is there any way I can incre
ase
>my stack size on application start up??
 
The correct way to add stack space is to add a 'mem!' resource to your
application's resource file:
 
resource 'mem!' (1000,
#if qNames
        "Additional Memory Requirements",
#endif
        purgeable) {
        0,                              // Add to temporary reserve
        0,                              // Add to permanent reserve
        0                               // Add to stack space
};
 
Put the amount of additional space required in place of the last 0 above.
 
Harry
From: ksand@apple.com (Kent Sandvik )
Subject: Re: Memory Leaks
Date: Sat, 12 Dec 1992 23:28:40 GMT
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.macapp3

In article <724192662.2890464@AppleLink.Apple.COM>,
DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD) wrote:
> 
> 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.

The Swatch application is also handy for finding about leaky apps, just let
it
run in a window, and check out if the free heap numbers are mysteriously
ticking down even if you are not doing anything.  Even better, if you could
figure out the size of the chunks that decrease, it might even give an
indication what is really leaking (sometimes).

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
From: DIGIMATCH@AppleLink.Apple.COM (3M, Ran Bedekar,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Adlib Questions
Date: 15 Dec 92 15:01:00 GMT
Organization: AppleLink Gateway

Chip,
The 'BHVR' resource that Ad Lib creates is pretty simple.  It's a count (2
bytes) followed by one or more behaviors.  TBehaviorApp::IBehaviorApp() (source
provided with Ad Lib) converts each resource in your app to a stream and reads
the behaviors.
If there are multiple behaviors in the resource, they will all be added to the
application object.  Likewise, if there are multiple BHVR resources, they all
are added to the application.
 
Having said all of that, I don't think that it is your problem.  The 'BHVR'
resource is a general purpose mechanism to add any kind of behaviors to your
application object.  For your prototyping, you are adding THandlerBehaviors to
objects by using the 'Handlers' window in Ad Lib.  There is no reason why
multiple handler behaviors will not work, if they are set up properly.  I
suspect that one of your handlers is blocking a message by not forwarding it.
For each message that you provide a handler for (e.g., Key Down or Setup Menus)
you can specify a number of actions (e.g., Send Event or Enable Menu) to be
performed.  Normally, the last action should be 'Forward Message' to 'Self'.
This will let the object that owns the behavior, and the object's other
behaviors, have a shot at the message.  If you don't forward the message, it
will not be propagated.  This is analogous to calling the inherited member
function when overriding a class.
 
 
Regards,
Nick Nallick
From: ksand@apple.com (Kent Sandvik )
Subject: Re: MAC APP 3, pascal programmer
Date: Sat, 19 Dec 1992 22:13:54 GMT
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.macapp3

In article <1992Dec19.161916.9766@mnemosyne.cs.du.edu>,
gtapolow@nyx.cs.du.edu (Greg Tapolow) wrote:
> 
> 
> I've recently updated from Macapp 2 to 3. I program primarily in Pascal as
> a hobbyist. Do I still need to purchase MPW C++ to compile my programs?

No, unless you are using Think Pascal, then you are hosed. Anyway, the
release notes should have a line how to disable a couple of makefile
lines so the build process won't complain about a missing C++ compiler
(really not needed).

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: MACAPP.ADMIN@AppleLink.Apple.COM (Design Methodology,Joel Norvell,VCA)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: EMail etiquette proposal
Date: 19 Dec 92 00:04:00 GMT
Organization: AppleLink Gateway

Hi Ed,
 
It's really a question of who wants to put the bell on the cat.
 
I am not on MacApp3tech$ or MacApp2tech$ specifically so I can track my mail.
I download the archives on a weekly basis. You also can read MacApp3tech$ on
netnews now, you know.
 
I think the problem "in the large" is an AppleLink problem, not a netiquette
issue. I say reform AppleLink (the application) not the poor customers.
 
If you want to try to get people to use your convention, that's reasonable. But
I think it will be very difficult to make it stick.
 
Also I think the place to discuss any such issue is on-line, not at a meeting.
That's because the interested parties are already (and almost always) present.
 
Best regards,
 
Joel Norvell
MacApp.Admin
From: LEIGH@AppleLink.Apple.COM (Daniels, Leigh,APD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: RE- Memory Leaks
Date: 13 Dec 92 21:04:00 GMT
Organization: AppleLink Gateway

Attn: Bosanko" <Peter_Bosanko|"Peter
Attn: MacApp3Tech$
SentBy: Leigh Daniels
 
        Reply to:   RE: Memory Leaks
Peter,
 
I sent you a copy of Ramadillo but thought it might not reach you because of
the way internet mail is handled. I've posted it on AppleLink with the
following path:
 
Developer Support:Developer Talk:New Information-All:Leak
Detection-Ramadillo 0.8.
 
Hope this helps you. I've found it useful.
 
**Leigh
From: ATOMIKA@AppleLink.Apple.COM (ATOMIKA Analysetechnik GmbH,DE,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Vanishing Scrollbars
Date: 14 Dec 92 18:53:00 GMT
Organization: AppleLink Gateway

Recently I stepped over a problem with the defined size of windows. My question
is: Bug or feature?
 
Our app defines several Windows. As long as the window size from the View is
smaller than the screen thay are displayed on, everything works fine. But if
the screen is smaller than the window, weird things happen. I detected that
problem on a PB160. It has 640x400 pixels instead of 640x480 that the 13"
monitor has. Most resizable windows did not show their horizontal scrollbar. It
seems that the window is drawn smaller but the software still assumes its
original size and thus the scrollbars and the drawing are out of synch.
 
We resize most windows when they are opened through data from the document to a
different size so we may define them in a smaller size. We use the information
of the window size mainly for "ConstrainWindowSize" and are able to live with
that problem.
 
BUT:
Is that weird behavior really a feature and do we have to define the windows to
the smallest screen size we want to run on? Or is it a bug, that MacApp does
not keep the Scroller and the Window in synch when the screen is too small?
 
Christian Scholze
ATOMIKA Analysetechnik GmbH
Munich, Germany
From: KODAKEN@AppleLink.Apple.COM (Eastman Kodak, K Wieschhoff,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: TDialogView in Ad Lib
Date: 15 Dec 92 17:55:00 GMT
Organization: AppleLink Gateway

Attn: MacApp 3 Tech$
SentBy: Ken Wieschhoff
 
                       Subject:                               Time:1:02 PM
  OFFICE MEMO          TDialogView in Ad Lib                  Date:12/14/92
 
 
How do I create one?  I saw icons for TView but not TDialogView.
 
Also,  How would one assign a target in TWindow?
 
Thanks in advance(tm),
 
->Ken