ControlFrame implementation's distinction between in-proc and out-of-proc Controls

[ERDI Gergo <cactus cactus rulez org>]

Hi,

[this is going to be a bit complicated -- it certainly took me some time
to understand how, and why, bonobo_object() works]

libbonoboui's Bonobo::ControLFrame implementation has code like this:

		frame->priv->inproc_control = (BonoboControl *)
			bonobo_object (ORBit_small_get_servant (control));

However, of course, this has nothing to do with wether control is in-proc
-- this only tests if it's an in-proc Bonobo component that is based on
libbonoboui's Bonobo::Control implementation. Why? Because in order for
bonobo_object() to return a non-0, its input argument either has to be a
BonoboObject*, or a Servant that is implemented by a subclass of
BonoboObject* (since this is where the magic key is set on the servant)

So what this all boils down to, if you have an in-proc Control that is
implemented not via the stock implementation in libbonoboui,
inproc_control will be set to 0. However, when later
bonobo_control_frame_get_remote_window is called, it will barf because it
thinks the control is out-of-proc:

		if (plug && !frame->priv->inproc_control) {
			g_warning ("ARGH - serious ORB screwup");
			frame->priv->inproc_control = bonobo_plug_get_control (plug);

So I'm looking for suggestions :)


-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= cactus cactus rulez org =---'
I am an expert in electricty. My father held the chair of applied electricity at the state prison.