On Nov 19, 2009, at 6:40 AM, Jacek Kałucki wrote:
>> Why can't you you a series of dSizers? What requirements don't they
>> satisfy? If you want to get the GridSizer portion working, I see no
>>
> I'm using dGridSizer because I can (could if it'll work).
> My layout is quite simple so I can use dSizers, but where is benefit
> of
> using large amount of dSizers instead one?
There is no reason that a grid sizer should not work as well as a
series of nested sizers.
>> problem with it. However, the 2 items I mentioned earlier about
>> mixing
>> wx calls and putting things into the __init__ method could lead to
>> your
>> error. You may want to try making though changes and see if that
>>
> I just created my control like Dabo creates his own, like e.g.
> dSpinner.
> It uses __init__() and Bind() methods too. What's wrong with that?
Several things. First off, there is a lot of processing that happens
in the __init__() of classes to incorporate all of the framework
behaviors, and doing things in the wrong order can break stuff. That's
why we've added beforeInit(), initProperties(), initEvents(),
afterInit() and afterInitAll(): those are areas where you can add code
to your classes and not have to worry about breaking anything.
As far as using Bind() goes, you've now bypassed the Dabo event
system, so you run a very good chance of getting your UI out of sync.
If there is a wx control that you are using that we haven't wrapped
yet, then of course you have no choice, but if it is a control that
has been wrapped for Dabo, you should really use the Dabo events, or
the results may be unpredictable.
> Of course I can add properties to my class and put my code in
> afterInit() method.
> Second, it's not final of control use, but it belongs to Dabo
> extension
> module I created,
> that contains features and extensions missing in Dabo itself.
Are these missing items things that are only useful to your
application? If not, you should consider discussing them in the dabo-
dev list to see if they are helpful additions that might be shared
with others.
> So I shouldn't use afterInit() and other methods, because they are
> reserved for subclasses.
> But every action could lead me to error, afraid :(
You are always much safer using the public methods instead of
modifying the private implementation methods. Always.
>> corrects your error. Also, why are you calling the superclass
>> createItems method? What does it (PageEditBase.createItems) do?
>>
> Hmm, it does the same what self.super() do, that is put by Dabo
> AppWizard
> at the end of each edit page in createItems() code end :)
> I mean it does do nothing. Just for case.
> The generated code:
> self.Sizer.layout()
> self.itemsCreated = True
> is redundant too, because it exist in dPage._createItems() method.
> What does it do in AppWizard generated code?
I'll leave that for Paul to answer. I only use AppWizard for quick
apps that I don't need to extend or modify.
> But lets back to the subject.
> I tried to create control manually step by step, by creating panel,
> then adding controls and binding to grid sizer - without success.
> I did use containers of controls based on dPanel in dGridSizers
> successfully but they are in expanded columns.
> Why this case didn't work - I don't know.
It worked - the columns do appear to have expanded. But without being
able to run the code, I can't really test it to figure out what is
wrong. One quick suggestion (and this is just a wild guess): what if
you add a weight to all your gridsizer.append() calls? You have the
'expand' setting, but no weight. If you add a parameter of 1 for the
weight, does it change the visual appearance?
-- Ed Leafe
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/[email protected]
