NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/mac/oop/macapp3/195

Internet Message Format | 1992-12-15 | 1.7 KB

Path: sparky!uunet!stanford.edu!apple!applelink.apple.com
From: [e-mail] (3M, Ran Bedekar,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Adlib Questions
Message-ID: <[e-mail]>
Date: 15 Dec 92 15:01:00 GMT
Sender: [e-mail]
Organization: AppleLink Gateway
Lines: 27

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