Re: [glade--]How to access sibling widgets?
Christof Petig <[email protected]>
| Newsgroups | gmane.comp.gnome.glademm |
|---|---|
| Organization | Adolf Petig GmbH & Co. KG |
| Message-ID | <[email protected]> |
Enrico Scholz wrote:
> Hello,
Hi
>
> when having a widget tree like
>
> | window1
> | `- vbox1
> | |- entry1
> | `- entry2
>
> marking entry1/entry2 as public and generating a separate class and file
> for them, how can I access entry1 from entry2?
>
> glade-- creates the following code
>
> | window1_glade::window1_glade(...)
> | {
> | ...
> | _data = new GlademmData(get_accel_group());
> |
> | entry1 *entry1 = Gtk::manage(new class entry1(_data));
> | entry2 *entry2 = Gtk::manage(new class entry2(_data));
> | ...
> | }
>
> which does not give any information about 'entry1' to 'entry2'.
>
> When modifying glade-- to generate other constructors which are taking
> the parent-object as an argument, code like
>
> --- window1_glade.cc
> | entry1 *entry1 = Gtk::manage(new class entry1(*this));
> | entry2 *entry2 = Gtk::manage(new class entry2(*this));
this is indead the way we usually go, perhaps once adding C++ specific
flags to widgets is a piece of cake I'll provide a switch. You can
address this by putting the new widgets into a dummy window each and
creating them as custom widgets ("entry1(*this)").
Another alternative is to provide the pointer by a later called function
(set_parent(*this)), call this from the parent's ctor.
>
> --- entry2.hh
> | class window1_glade;
> | class entry2 : public entry2_glade
> | { ...
> | entry2(window1_glade &data) : entry2_glade(data)
>
> could be created and 'entry1' would be accessible through 'data.entry1'. I do
> not know why 'window1.get_accel_group()' was encapsulated in a GlademmData
> object, but it would be still accessible through 'data.get_accel_group()'.
The encapsulation was to provide future API compatibilty once more than
a single accel_group would need to get passed around. Luckily nothing so
far showed up.
>
> The documentation mentions GMM_* macros, but they do not seem to exist
> anymore.
I killed them for good reasons ... please do not use them to bypass
every safety C++ has to offer. Did I forget to discourage them in the doc?
Christof