[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnome-components
Subject:    ControlFrame implementation's distinction between in-proc and
From:       ERDI Gergo <cactus () cactus ! rulez ! org>
Date:       2002-07-24 17:16:01
[Download RAW message or body]

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.

_______________________________________________
gnome-components-list mailing list
gnome-components-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-components-list
[prev in list] [next in list] [prev in thread] [next in thread]