Am trying to find a workaround. The external lib requires a
TargetEventRef to which it will install carbon event handlers. We
have subclassed a canvas and its handle on a non-composited window
provides a valid TargetEventRef and all things work without a glitch.
However, the handle of a canvas is 0 when it lives on a composited
window.
So we create a HIObject, its HIFrame is tied to a REALcontrolInstance
and is added to the windows content view. The MacOS toolbox does not
complain, all is well. Further, the external lib does not complain
either when the HIObject is presented. But it looks like there are no
carbon events send to the HIObject. We had seen that this occurred
with other plugins we wrote, and we were forced to create and send
carbon events to the HIObject, driven by the REALcontrol behavior
callbacks.
It is not conceivable to construct rich Carbon events involving user
keystrokes, but wonder whether we are forgetting something that could
trigger the HIObject to receive events from the main event loop.
Any suggestions?
Unfortunately, the REALcontrol does not provide valid control handles
(ControlRef/HIViewRef) either, which to me is a major show-stopper
for our plugin, and makes the RB-framework for Mach-O inferior to the
RB-framework for Windows. On windows, a REALcontrol, or a canvas do
provide valid control handles (HWNDs) making it quite easy to
subclass "toolbox classes" for getting messages from the event loop.
We use the canvas, and given that it provides already a handle on a
non-composited window, it should be an easy fix to provide a handle
when it lives on a composted window. Wouldn't it?
Alfred
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
