Re: Wrapping VSTGUI for Dummies
Re: Wrapping VSTGUI for Dummies
- Subject: Re: Wrapping VSTGUI for Dummies
- From: Art Gillespie <email@hidden>
- Date: Fri, 3 Oct 2003 09:13:11 -0400
A to the FX,
/**
* AG: The best-kept secret about VST's gui handling (or so it
would seem).
* The proper way to inform a VST UI (including VSTGUI) of offsets
is
by getting
* a pointer to the editor's bounds rect and setting it.
Where'd you get this from..? I've not seen this anywhere in the VST
docs.
Is the fact that effEditGetRect takes a double-indirected pointer for
no
obviously good reason some bizarre Steinberg hint for this?
Yep, check the #elif MAC section of CFrame's constructor for the big
tipoff (and the pointer-to-pointer CRect parameter is a dead giveaway,
too). Offsets are set there in CDrawContext that are used elsewhere in
vstgui #elif MAC drawing sections to get the offsets right. I'd be
willing to bet 90% of plug-ins don't do this, though (probably why the
VST window in Mac Classic Logic was the only window that had the
plug-in settings at the *bottom*). VST strikes again.
The only bug I've found with this is in CTextEdit's #elif MACX section,
where they forgot to use the offsets to create the bounds for the
platform-specific text control (this is why CTextEdit still gives most
people trouble once they get everything else working jake). Easy
enough to patch by adding the appropriate offsets.
/**
* AG: THE SMART WAY TO DO THIS IS TO USE CONTROL EVENTS ON THE
CARBON PANE
Why is that necessary? Any good reason why window events won't work? I
have
seen some odd bugs with this in Cocoa hosts, particularly for VSTis
that
use the Carbon eventpipes themselves, but what is wrong with
installing a
window event handler?
Probably not necessary, just smart, and in keeping with the notion that
the window doesn't belong to the CarbonUI... the Carbon pane does. In
any case, the way the wrapper was originally (see commented-out
sections of CreateUI and original HandleEvent()), didn't work with
Cocoa hosts (and I suspect some others). The window would only receive
the first mouse click after receiving focus
Obviously there are cases where you *need* to use Window Handlers, e.g.
if you need to know when the host has gotten around to honoring your
SizeControl(mCarbonPane) call, so you can reset an OpenGL context's
drawable to the resize graphics port, etc., you'd have to handle
kEventWindowBoundsChanged. Generally, though, I've found life goes
better using the control event handlers for mouse, draw, etc.
Best,
Art
>>0xBA
Regards,
Angus.
=======================================================
Angus F. Hewlett, Technical Director
FXpansion Audio UK Ltd - http://www.fxpansion.com
=======================================================
_______________________________________________
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.
_______________________________________________
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.