DB runs in close loop when clicking on a sizer

Hi Julian,
Just find while trying to explore different elements of my project that
clicking on a sizer in the element tree produces a 100% cpu closed loop, too.

I can simply create the situation having a containment structure like this

wxFrame->wxBoxSizer->wxPanel->wxBoxSizer

and opening the tree until the second sizer and then click on it. In my first
observation I said the there is no memory consumption, but this was wrong.
As there are 1G build in and memory seems to be allocated in small chunks I
have to look a bit longer on xosview to see it. BTW, when I tried to add the
sizer to scrolled window, it would have been the second in the hirachy ...

Sorry, that I didn't see that earlier today but until now I nearly only used
the source editor for my experiments.

Regards,

Thomas

--
Dipl.-Ing. Thomas Zehbe
INGENION GmbH
Kuhweide 6
31552 Apelern
Fon: 05043 / 40 57 90 4
Fax: 05043 / 40 57 90 7

Hi Thomas,

Not quite sure what you mean - does DB actually hang, or do you mean it
just consumes CPU but still works? I haven't been able to make it hang
yet using the structure you mentioned.

Is there a standard CPU monitor with SuSE?

Thanks,

Julian

Thomas Zehbe wrote:
> Hi Julian,
> Just find while trying to explore different elements of my project that
> clicking on a sizer in the element tree produces a 100% cpu closed loop, too.
>
> I can simply create the situation having a containment structure like this
>
> wxFrame->wxBoxSizer->wxPanel->wxBoxSizer
>
> and opening the tree until the second sizer and then click on it. In my first
> observation I said the there is no memory consumption, but this was wrong.
> As there are 1G build in and memory seems to be allocated in small chunks I
> have to look a bit longer on xosview to see it. BTW, when I tried to add the
> sizer to scrolled window, it would have been the second in the hirachy ...
>
> Sorry, that I didn't see that earlier today but until now I nearly only used
> the source editor for my experiments.
>
> Regards,
>
> Thomas
>
>
>
>

--
Julian Smart, Anthemion Software Ltd.
28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
www.anthemion.co.uk | +44 (0)131 229 5306
Tools for writers: www.writerscafe.co.uk
wxWidgets RAD: www.anthemion.co.uk/dialogblocks

Hi Julian,
> Not quite sure what you mean - does DB actually hang, or do you mean it
> just consumes CPU but still works? I haven't been able to make it hang
> yet using the structure you mentioned.
Sorry that I wasn't precise enough. DB actually hangs. There is no more
reaction to mouse or keyboard events. And it is not repainted after a portion
of the window was coverd by another app.

I just checked the behaviour again taking 3.07 and 3.07b using the same
project. Attached to this mail you see a small screenshot showing the
structure I'm talking about. The steps are
1 open the project
2 klick on the Lager frames arrow to see the wxBoxSizerV
3 klick on the wxBoxSizerV arrow to the wxPanel
3a klick on the wxPanel to first make the frame visible in the wysiwyg edit
panel
4 klick on the wxPanel arrow to see the next wxBoxSizerV
5 than do a single or double click on the wxBoxSizerV
With 3.07b DB hangs, with 3.07 not.

Leaving out step 3a DB doesn't hang but shows the frame for the first time in
the editor!
Having done a double click in step 5 the "next" wxBoxSizerH is already visble.
Clicking on this wxBoxSizerH in this state makes DB hang.
Having done a single click in step 5 and making a double click on the
wxBoxSizerV or a single click an the arrow in front of it makes the next
wxBoxSizerH visible. Clicking on this wxBoxSizerH in this state makes DB
hang.
Seems to me that it makes a difference wether the top level element is already
visible in the editor or not.

Perhaps this receipt helps you reproduce the hang.
Took another, older project and it behaves the same.
>;
> Is there a standard CPU monitor with SuSE?
There are more, but since years I use xosviev. If you have a distribution disk
just seach for xosview. It shows the states of load, cpu(s), mem, swap, net,
disk and ints in standard config using numbers and vu-meter like bars. I have
it on all six desktops at a time to see whats going on. After installation
you find it under system->;monitoring(in german ÜBerwachung).

If you can't find it I could send you the rpm if I find it on the disk.

Regards,

Thomas

> Thanks,
>
> Julian
>
> Thomas Zehbe wrote:
> > Hi Julian,
> > Just find while trying to explore different elements of my project that
> > clicking on a sizer in the element tree produces a 100% cpu closed loop,
>; > too.
> >
> > I can simply create the situation having a containment structure like
> > this
> >
> > wxFrame->wxBoxSizer->wxPanel->wxBoxSizer
> >
> > and opening the tree until the second sizer and then click on it. In my
> > first observation I said the there is no memory consumption, but this was
> > wrong. As there are 1G build in and memory seems to be allocated in small
>; > chunks I have to look a bit longer on xosview to see it. BTW, when I
> > tried to add the sizer to scrolled window, it would have been the second
> > in the hirachy ...
> >
> > Sorry, that I didn't see that earlier today but until now I nearly only
> > used the source editor for my experiments.
> >
> > Regards,
> >
> > Thomas

--
Dipl.-Ing. Thomas Zehbe
INGENION GmbH
Kuhweide 6
31552 Apelern
Fon: 05043 / 40 57 90 4
Fax: 05043 / 40 57 90 7

Hi Thomas,

Sigh - one step forward, one back. I wonder if you could send me the
project to save me some time.

Many thanks,

Julian

Thomas Zehbe wrote:
> Hi Julian,
>
>> Not quite sure what you mean - does DB actually hang, or do you mean it
>> just consumes CPU but still works? I haven't been able to make it hang
>> yet using the structure you mentioned.
>>
> Sorry that I wasn't precise enough. DB actually hangs. There is no more
> reaction to mouse or keyboard events. And it is not repainted after a portion
> of the window was coverd by another app.
>
> I just checked the behaviour again taking 3.07 and 3.07b using the same
> project. Attached to this mail you see a small screenshot showing the
> structure I'm talking about. The steps are
> 1 open the project
> 2 klick on the Lager frames arrow to see the wxBoxSizerV
> 3 klick on the wxBoxSizerV arrow to the wxPanel
> 3a klick on the wxPanel to first make the frame visible in the wysiwyg edit
> panel
>; 4 klick on the wxPanel arrow to see the next wxBoxSizerV
> 5 than do a single or double click on the wxBoxSizerV
> With 3.07b DB hangs, with 3.07 not.
>
> Leaving out step 3a DB doesn't hang but shows the frame for the first time in
> the editor!
> Having done a double click in step 5 the "next" wxBoxSizerH is already visble.
> Clicking on this wxBoxSizerH in this state makes DB hang.
>; Having done a single click in step 5 and making a double click on the
> wxBoxSizerV or a single click an the arrow in front of it makes the next
> wxBoxSizerH visible. Clicking on this wxBoxSizerH in this state makes DB
> hang.
>; Seems to me that it makes a difference wether the top level element is already
> visible in the editor or not.
>
> Perhaps this receipt helps you reproduce the hang.
>; Took another, older project and it behaves the same.
>;
>> Is there a standard CPU monitor with SuSE?
>;>
> There are more, but since years I use xosviev. If you have a distribution disk
> just seach for xosview. It shows the states of load, cpu(s), mem, swap, net,
> disk and ints in standard config using numbers and vu-meter like bars. I have
> it on all six desktops at a time to see whats going on. After installation
> you find it under system->;monitoring(in german ÜBerwachung).
>
> If you can't find it I could send you the rpm if I find it on the disk.
>
> Regards,
>
> Thomas
>
>
>> Thanks,
>>
>> Julian
>>
>;> Thomas Zehbe wrote:
>>
>>> Hi Julian,
>>> Just find while trying to explore different elements of my project that
>>> clicking on a sizer in the element tree produces a 100% cpu closed loop,
>;>> too.
>>>
>>> I can simply create the situation having a containment structure like
>>> this
>>>
>>> wxFrame->wxBoxSizer->wxPanel->wxBoxSizer
>>>
>>> and opening the tree until the second sizer and then click on it. In my
>>> first observation I said the there is no memory consumption, but this was
>>> wrong. As there are 1G build in and memory seems to be allocated in small
>;>> chunks I have to look a bit longer on xosview to see it. BTW, when I
>>;> tried to add the sizer to scrolled window, it would have been the second
>>> in the hirachy ...
>>>
>>> Sorry, that I didn't see that earlier today but until now I nearly only
>>> used the source editor for my experiments.
>>;>
>>> Regards,
>>>;
>>> Thomas
>>>
>
>
>
> ----------------------------------------------------------
>

--
Julian Smart, Anthemion Software Ltd.
28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
www.anthemion.co.uk | +44 (0)131 229 5306
Tools for writers: www.writerscafe.co.uk
wxWidgets RAD: www.anthemion.co.uk/dialogblocks

Hi Julian,
I just send it to julian at anthemion.co.uk.

Regards,

Thomas

Am Mittwoch, 30. August 2006 10:14 schrieb Julian Smart:
> Hi Thomas,
>
> Sigh - one step forward, one back. I wonder if you could send me the
> project to save me some time.
>;
> Many thanks,
>
> Julian
>
> Thomas Zehbe wrote:
> > Hi Julian,
> >
> >> Not quite sure what you mean - does DB actually hang, or do you mean it
> >> just consumes CPU but still works? I haven't been able to make it hang
> >> yet using the structure you mentioned.
> >
> > Sorry that I wasn't precise enough. DB actually hangs. There is no more
> > reaction to mouse or keyboard events. And it is not repainted after a
> > portion of the window was coverd by another app.
> >
> > I just checked the behaviour again taking 3.07 and 3.07b using the same
> > project. Attached to this mail you see a small screenshot showing the
> > structure I'm talking about. The steps are
> > 1 open the project
> > 2 klick on the Lager frames arrow to see the wxBoxSizerV
> > 3 klick on the wxBoxSizerV arrow to the wxPanel
> > 3a klick on the wxPanel to first make the frame visible in the wysiwyg
> > edit panel
>; > 4 klick on the wxPanel arrow to see the next wxBoxSizerV
> > 5 than do a single or double click on the wxBoxSizerV
> > With 3.07b DB hangs, with 3.07 not.
> >
> > Leaving out step 3a DB doesn't hang but shows the frame for the first
>; > time in the editor!
> > Having done a double click in step 5 the "next" wxBoxSizerH is already
> > visble. Clicking on this wxBoxSizerH in this state makes DB hang.
>; > Having done a single click in step 5 and making a double click on the
> > wxBoxSizerV or a single click an the arrow in front of it makes the next
> > wxBoxSizerH visible. Clicking on this wxBoxSizerH in this state makes DB
> > hang.
>; > Seems to me that it makes a difference wether the top level element is
> > already visible in the editor or not.
> >
> > Perhaps this receipt helps you reproduce the hang.
>; > Took another, older project and it behaves the same.
>; >
> >> Is there a standard CPU monitor with SuSE?
>; >
> > There are more, but since years I use xosviev. If you have a distribution
> > disk just seach for xosview. It shows the states of load, cpu(s), mem,
> > swap, net, disk and ints in standard config using numbers and vu-meter
> > like bars. I have it on all six desktops at a time to see whats going on.
> > After installation you find it under system->;monitoring(in german
> > ÜBerwachung).
> >
> > If you can't find it I could send you the rpm if I find it on the disk.
>; >
> > Regards,
> >
> > Thomas
> >
> >> Thanks,
> >>
> >> Julian
> >>
> >> Thomas Zehbe wrote:
> >>> Hi Julian,
> >>> Just find while trying to explore different elements of my project that
> >>> clicking on a sizer in the element tree produces a 100% cpu closed
> >>> loop, too.
> >>>
> >>> I can simply create the situation having a containment structure like
> >>> this
> >>>
> >>> wxFrame->wxBoxSizer->wxPanel->wxBoxSizer
> >>>
> >>> and opening the tree until the second sizer and then click on it. In my
> >>> first observation I said the there is no memory consumption, but this
> >>> was wrong. As there are 1G build in and memory seems to be allocated in
> >>> small chunks I have to look a bit longer on xosview to see it. BTW,
> >>> when I tried to add the sizer to scrolled window, it would have been
> >>> the second in the hirachy ...
> >>>
> >>> Sorry, that I didn't see that earlier today but until now I nearly only
> >>> used the source editor for my experiments.
> >>>
> >>> Regards,
> >>>
> >>> Thomas
> >
> > ----------------------------------------------------------

--
Dipl.-Ing. Thomas Zehbe
INGENION GmbH
Kuhweide 6
31552 Apelern
Fon: 05043 / 40 57 90 4
Fax: 05043 / 40 57 90 7