|
List Info
Thread: Re: Problem with Sizer initialize when using XRC
|
|
| Re: Problem with Sizer initialize when
using XRC |
  United States |
2007-06-05 10:48:44 |
|
May be to clarify:
I would like to use the DB functionality to name a size and refer to
it like any other control that I can name, but:
- The sizer name gets declared in the source, but not initialized
- so my work-around is to name the panel/window that contains the
sizer and get the sizer object with GetSizer() from there
- once I have the sizer, it allows me to add controls that do not have
a handler for the XRC file
... if the sizer that I need is a few levels down, this would probably
not work.
Cees.
--- In anthemion-devtools%40yahoogroups.com">anthemion-devtools yahoogroups.com, Julian Smart <julian ...>
wrote:
>
> Hi,
>
> Phillip Seaver wrote:
> > I don't think he's necessarily talking about getting the top-level
> > sizer. I've been picking a control that's directly contained by the
> > sizer and calling GetSizer() on it to set the variable that's defined
> > in DB. It works fine manually, but it would be nice if DB could do
> > it.
> >
> I'm confused - surely wxWindow::GetSizer() returns that window's
> top-level sizer, rather than a sizer that contains that window?
>
> (By top-level sizer I mean the sizer that's a child of any given window
> that does its own sizer layout, not one sizer per whole dialog.)
>
> Regards,
>
> Julian
>
__._,_.___
.
__,_._,___
|
| Re: Re: Problem with Sizer initialize
when using XRC |
  United States |
2007-06-05 11:15:08 |
|
On Jun 5, 2007, at 8:48 AM, motormuizen wrote:
> May be to clarify:
>
> I would like to use the DB functionality to name a size and refer to
> it like any other control that I can name, but:
> - The sizer name gets declared in the source, but not initialized
> - so my work-around is to name the panel/window that contains the
> sizer and get the sizer object with GetSizer() from there
> - once I have the sizer, it allows me to add controls that do not have
> a handler for the XRC file
> ... if the sizer that I need is a few levels down, this would probably
> not work.
>
> Cees.
But you could work around the "few levels down" problem by having a
dummy control (maybe a wxStaticText) in your XRC. Your code can find
that and call GetContainingSizer on it to get the sizer you want,
after which you can delete the dummy and add in the controls which
you need to configure programmatically.
There are very few cases where one wants to access sizers directly,
though, so ISTM that having DB generate the access would be a mis--
feature.
Regards,
John Ralls
__._,_.___
.
__,_._,___
|
| Re: Re: Problem with Sizer initialize
when using XRC |
  United States |
2007-06-05 12:15:21 |
|
On 6/5/07, John Ralls < jralls%40ceridwen.fremont.ca.us">jralls ceridwen.fremont.ca.us> wrote:
>
> On Jun 5, 2007, at 8:48 AM, motormuizen wrote:
>
> > May be to clarify:
> >
> > I would like to use the DB functionality to name a size and refer to
> > it like any other control that I can name, but:
> > - The sizer name gets declared in the source, but not initialized
> > - so my work-around is to name the panel/window that contains the
> > sizer and get the sizer object with GetSizer() from there
> > - once I have the sizer, it allows me to add controls that do not have
> > a handler for the XRC file
> > ... if the sizer that I need is a few levels down, this would probably
> > not work.
> >
> > Cees.
>
> But you could work around the "few levels down" problem by having a
> dummy control (maybe a wxStaticText) in your XRC. Your code can find
> that and call GetContainingSizer on it to get the sizer you want,
> after which you can delete the dummy and add in the controls which
> you need to configure programmatically.
>
> There are very few cases where one wants to access sizers directly,
> though, so ISTM that having DB generate the access would be a mis--
> feature.
>
> Regards,
> John Ralls
I use it to hide groups of controls, e.g., and to trigger a re-layout
occasionally. I don't think it's a misfeature to have something that
most people don't use. I'm sure there are a few controls (at least)
that most people never use. 
The problem is that DB allows you to create a variable for the sizer
but then doesn't initialize it to point to the sizer. Like I said,
it's really not hard to do manually, but it would be nice for it to be
done automatically. I probably would have mentioned it when I ran
across it the first time, but I was on a tight deadline at the time
and just needed to get things working. 
Phillip
__._,_.___
.
__,_._,___
|
| Re: Re: Problem with Sizer initialize
when using XRC |
  United States |
2007-06-05 13:02:49 |
|
On Jun 5, 2007, at 10:15 AM, Phillip Seaver wrote:
> On 6/5/07, John Ralls < jralls%40ceridwen.fremont.ca.us">jralls ceridwen.fremont.ca.us> wrote:
> >
> > On Jun 5, 2007, at 8:48 AM, motormuizen wrote:
>
> I use it to hide groups of controls, e.g., and to trigger a re-layout
> occasionally. I don't think it's a misfeature to have something that
> most people don't use. I'm sure there are a few controls (at least)
> that most people never use. 
>
> The problem is that DB allows you to create a variable for the sizer
> but then doesn't initialize it to point to the sizer. Like I said,
> it's really not hard to do manually, but it would be nice for it to be
> done automatically. I probably would have mentioned it when I ran
> across it the first time, but I was on a tight deadline at the time
> and just needed to get things working. 
>
> Phillip
No, what DB allows you to do is to specify the variable name when
generating pure C++ and to make it a member variable; if you leave
the "variable name" blank, DB generates a variable name for the sizer
(e.g., itemBlockSizer2) as a temporary. XRC doesn't have a facility
for exposing the temporary that it creates, and because sizers aren't
derived from wxWindow, the FindWindow won't find them, so attaching a
name to the sizer in XRC would be pointless.
I think it would be a misfeature to generate the code (and the
necessary dummy control) needed to access the sizer as we've been
discussing for every sizer. I suppose it would be OK if it was only
generated in the cases where a member variable is declared.
Notice that you can control pretty finely whether a particular
section is generated as plain C++, C++ for XRC, or XRC only.
Regards,
John Ralls
__._,_.___
.
__,_._,___
|
[1-4]
|
|