• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: AUCarbonViewControl::HandleEvent bug? (Marc Poirier)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: AUCarbonViewControl::HandleEvent bug? (Marc Poirier)


  • Subject: RE: AUCarbonViewControl::HandleEvent bug? (Marc Poirier)
  • From: Michael <email@hidden>
  • Date: Thu, 6 Feb 2003 13:58:48 -0800

Mark,

I think you are right... I think this is an oversight. I have tried running the code both ways, and it doesn't seem to make too much difference (well, it only makes a difference if you are in the same control twice where the TellListener() won't be executed, and that case is pretty much handled by kEventControlClick anyway. I do think that the listener code should be invoked regardless (just like the controlClick case).

I would be curious to know if this makes a difference for your plugin. We will be revisiting this code in the future because there are a lot of minor problems such as this that need to be fixed. As always, we greatly value and appreciate your feedback. Please let us know if you find any similar problems.

Thanks,

Michael Hopkins
Core Audio Engineering

Message: 13
Date: Thu, 6 Feb 2003 01:37:56 +0100 (CET)
From: Marc Poirier <email@hidden>
To: email@hidden
Subject: AUCarbonViewControl::HandleEvent bug?

In AUCarbonViewControl.cpp, in the AUCarbonViewControl::HandleEvent()
method, there is this:

case kEventControlClick:
if (mLastControl != this) {
if (mLastControl != NULL)
mLastControl->Update(false);
mLastControl = this;
} mOwnerView->TellListener(mParam, kAudioUnitCarbonViewEvent_MouseDownInControl, NULL);
break; // don't return true, continue normal processing
case kEventControlHit:
if (mLastControl != this) {
if (mLastControl != NULL)
mLastControl->Update(false);
mLastControl = this;
mOwnerView->TellListener(mParam, kAudioUnitCarbonViewEvent_MouseUpInControl, NULL);
}
break; // don't return true, continue normal processing


But shouldn't that actually be:

case kEventControlClick:
if (mLastControl != this) {
if (mLastControl != NULL)
mLastControl->Update(false);
mLastControl = this;
} mOwnerView->TellListener(mParam, kAudioUnitCarbonViewEvent_MouseDownInControl, NULL);
break; // don't return true, continue normal processing
case kEventControlHit:
if (mLastControl != this) {
if (mLastControl != NULL)
mLastControl->Update(false);
mLastControl = this;
} mOwnerView->TellListener(mParam, kAudioUnitCarbonViewEvent_MouseUpInControl, NULL);
break; // don't return true, continue normal processing

(notice the that in second to last line above, TellListener() is moved
outside of the if (mLastControl != this) statement)


I think that this is a bug and should be changed to the second version
above, but maybe I am misunderstanding the code. Either way, I would
appreciate a confirmation of which is correct, I'm deep in automation woes
lately...


Marc
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • RE: AUCarbonViewControl::HandleEvent bug? (Marc Poirier)
      • From: Marc Poirier <email@hidden>
  • Prev by Date: Re: VST Wrapper
  • Next by Date: Re: VST Wrapper
  • Previous by thread: Debugging AU in Logic 5.5.0.609 ng ?
  • Next by thread: RE: AUCarbonViewControl::HandleEvent bug? (Marc Poirier)
  • Index(es):
    • Date
    • Thread