reposition a TextCtrl don't work as expected

Hi list,

I've got a frame that contains a TextCtrl and an underlying
ObjectListView (each in sizers). This TC is used to query a
column and must resize & reposition upon the sorted column.

Until here, everything works fine: I resize a column and the TC
resizes itself, I sort on another column and the TC resizes &
reposition upon the right column.

However, on a frame resize it's all wrong: TC goes back to the
zero position until the next column header click.

Several print statements show that measures & size are good,
but the TC don't reposition correctly.

I bind EVT_SIZE and recalculate size & position each time; I also
tried different places for "event.Skip()" but it changed nothing.

However, suppressing the "event.Skip()" works (for the TC, of course
the OLV don't resize).

How can I have it to work properly?

JY

···

--
A woman's a woman until the day she dies, but a man's only a man as
long as he can. -- Moms Mabley

I (finally) find it out: a wx.CallAfter did the trick, sorry for
the noise.

···

On Tue, 27 Dec 2011 22:33:12 +0100 "Jean-Yves F. Barbier" <12ukwn@gmail.com> wrote:

How can I have it to work properly?

--
You will be dead within a year.

Don't have the textctrl in a sizer, always position and size it in your own code. If you need to reserve some space for it in the sizer then add a spacer to the sizer instead of the textctrl. Continue to call Skip in the EVT_SIZE handler so the sizer can still manage the layout of the OLV.

···

On 12/27/11 1:33 PM, Jean-Yves F. Barbier wrote:

Hi list,

I've got a frame that contains a TextCtrl and an underlying
ObjectListView (each in sizers). This TC is used to query a
column and must resize& reposition upon the sorted column.

Until here, everything works fine: I resize a column and the TC
resizes itself, I sort on another column and the TC resizes&
reposition upon the right column.

However, on a frame resize it's all wrong: TC goes back to the
zero position until the next column header click.

Several print statements show that measures& size are good,
but the TC don't reposition correctly.

I bind EVT_SIZE and recalculate size& position each time; I also
tried different places for "event.Skip()" but it changed nothing.

However, suppressing the "event.Skip()" works (for the TC, of course
the OLV don't resize).

How can I have it to work properly?

--
Robin Dunn
Software Craftsman

That could result in some flicker depending on what other events may be happening between the two moves. (The TC will be moved by the sizer and then moved again with the code you call via wx.CallAfter.)

···

On 12/27/11 1:47 PM, Jean-Yves F. Barbier wrote:

On Tue, 27 Dec 2011 22:33:12 +0100 > "Jean-Yves F. Barbier"<12ukwn@gmail.com> wrote:

How can I have it to work properly?

I (finally) find it out: a wx.CallAfter did the trick, sorry for
the noise.

--
Robin Dunn
Software Craftsman

There's effectively a visible flickering, and if you stare at it you
see the TC very briefly on/off @ position zero then @ the right
position - but you have to know it to notice, even on my old XP2600+
(and I don't know how to achieve that another way)

···

On Tue, 27 Dec 2011 13:52:25 -0800 Robin Dunn <robin@alldunn.com> wrote:

> I (finally) find it out: a wx.CallAfter did the trick, sorry for
> the noise.
>

That could result in some flicker depending on what other events may be
happening between the two moves. (The TC will be moved by the sizer and
then moved again with the code you call via wx.CallAfter.)

--
To be loved is very demoralizing.-- Katharine Hepburn

> How can I have it to work properly?

Don't have the textctrl in a sizer, always position and size it in your
own code.

Hmmm, I don't know if I fully understand.

In fact the TC is in a sizer because my first attempt was to resize
a panel placed just before it, but it failed; then I tried with an
empty StaticText and it worked - then I re-read the TC doc and
suppressed the ST. Now I directly TC.SetSize & TC.SetPosition.

Continue to call Skip in the EVT_SIZE handler so the sizer
can still manage the layout of the OLV.

I can't achieve what I want without this call (or I make the frame
fixed, but that not an option:)

···

On Tue, 27 Dec 2011 13:49:41 -0800 Robin Dunn <robin@alldunn.com> wrote:

--
Q: What is the sound of one cat napping?
A: Mu.

How can I have it to work properly?

Don't have the textctrl in a sizer, always position and size it in your
own code.

Hmmm, I don't know if I fully understand.

In fact the TC is in a sizer because my first attempt was to resize
a panel placed just before it, but it failed; then I tried with an
empty StaticText and it worked - then I re-read the TC doc and
suppressed the ST. Now I directly TC.SetSize& TC.SetPosition.

In other words, you want to manage the size and position of the textctrl yourself. If you put it in a sizer then you will have to fight with the sizer to manually manage the size and position, as you've discovered already. So instead, do not put it in any sizer and just do the SetSize and SetPosition.

If you need to reserve some space in the sizer such that it is kept empty (so the sizer doesn't put other widgets there) then add a spacer to the sizer. A spacer is simply a wx.Size or a tuple of 2 integers that you add to the sizer just like you would add a widget.

Continue to call Skip in the EVT_SIZE handler so the sizer
can still manage the layout of the OLV.

I can't achieve what I want without this call (or I make the frame
fixed, but that not an option:)

Right, which is why I said that you should call Skip()

···

On 12/27/11 2:25 PM, Jean-Yves F. Barbier wrote:

On Tue, 27 Dec 2011 13:49:41 -0800 > Robin Dunn<robin@alldunn.com> wrote:

--
Robin Dunn
Software Craftsman

>
> In fact the TC is in a sizer because my first attempt was to resize
> a panel placed just before it, but it failed; then I tried with an
> empty StaticText and it worked - then I re-read the TC doc and
> suppressed the ST. Now I directly TC.SetSize& TC.SetPosition.
>
In other words, you want to manage the size and position of the textctrl
yourself. If you put it in a sizer then you will have to fight with the
sizer to manually manage the size and position, as you've discovered
already. So instead, do not put it in any sizer and just do the SetSize
and SetPosition.

At this time, I don't know very much how to do that and the widget
isn't stabilized: it is a panel in a frame and sizer relative to the
panel - but when it'll be finished, the frame will disappear because
it'll be only used as a component.
Also, the searching TC presence depends on a call parm.

As it is the block of code that'll be the most used into my pgm,
(in fact I can't do nothing without it) I try to make it work the way
I want before any other consideration.

When the whole thing will be finished I'll put it on the web as
an Alpha version because it relies on many domains (wx, python,
postgresql, stocked procedures, views, etc) and I'm sure I'll do many
errors I hope people will help me to correct (AND explain!) at this
time.

If you need to reserve some space in the sizer such that it is kept

No, I don't need that.

empty (so the sizer doesn't put other widgets there) then add a spacer
to the sizer. A spacer is simply a wx.Size or a tuple of 2 integers
that you add to the sizer just like you would add a widget.

JY

···

On Tue, 27 Dec 2011 17:49:31 -0800 Robin Dunn <robin@alldunn.com> wrote:
--
Mieux vaut tard que jamais!
[ Better late than never ]

Hi Jean-Yves,

In fact the TC is in a sizer because my first attempt was to resize
a panel placed just before it, but it failed; then I tried with an
empty StaticText and it worked - then I re-read the TC doc and
suppressed the ST. Now I directly TC.SetSize& TC.SetPosition.

In other words, you want to manage the size and position of the textctrl
yourself. If you put it in a sizer then you will have to fight with the
sizer to manually manage the size and position, as you've discovered
already. So instead, do not put it in any sizer and just do the SetSize
and SetPosition.

At this time, I don't know very much how to do that and the widget
isn't stabilized: it is a panel in a frame and sizer relative to the
panel - but when it'll be finished, the frame will disappear because
it'll be only used as a component.

I assume you are building it as a component/class and just have it on the frame for testing.

Also, the searching TC presence depends on a call parm.

So, one can see the TC or not and it will float over the column, correct?

Isn't that a bit confusing to a user that the search control is there, not there or in a different position depending on what I want/need to search on? Wouldn't a fixed position be easier to use and maybe have a combobox/choice to select what one is searching/filtering on, in this case the cb could even offer options to do searches across multiple columns.

But on the other hand I might not get your use case at all:-)

Werner

···

On 12/28/2011 03:33 AM, Jean-Yves F. Barbier wrote:

On Tue, 27 Dec 2011 17:49:31 -0800 > Robin Dunn<robin@alldunn.com> wrote:

Hi Werner,

> At this time, I don't know very much how to do that and the widget
> isn't stabilized: it is a panel in a frame and sizer relative to the
> panel - but when it'll be finished, the frame will disappear because
> it'll be only used as a component.

I assume you are building it as a component/class and just have it on
the frame for testing.

No, it is a complete component I derived from OVL example (remember:
I didn't programmed for a lot of time, I'm not used to oop, and my
approach is non conventional: I begin by picking what I need, trying
to understand it, so I'm in a blur for "some" time and one day, like
a puzzle, everything's fine:)

> Also, the searching TC presence depends on a call parm.

So, one can see the TC or not and it will float over the column, correct?

Yes (except that it is not visible/invisible: it exists or not).

Isn't that a bit confusing to a user that the search control is there,
not there or in a different position depending on what I want/need to
search on? Wouldn't a fixed position be easier to use and maybe have a
combobox/choice to select what one is searching/filtering on, in this
case the cb could even offer options to do searches across multiple columns.

No: from my own experience (and softwares tests, a lot:) and the
observation/questioning of other, it must stay simple and ergonomic.
As it'll be used a the central part of an ERP, 95% of researches are
standalone ones (you search the name of the client OR its number but
not both, etc); the remainder 5% (essentially stats & accounting)
will be treated differently.

But on the other hand I might not get your use case at all:-)

Your email address says you live in france: you should know we like
to split hair °<;-)

JY

···

On Wed, 28 Dec 2011 09:46:57 +0100 werner <wbruhin@free.fr> wrote:
--
I wouldn't mind dying, it's that business of having to stay
dead that scares the shit out of me. -- R. Geis

Hi Jean-Yves,

Hi Werner,

At this time, I don't know very much how to do that and the widget
isn't stabilized: it is a panel in a frame and sizer relative to the
panel - but when it'll be finished, the frame will disappear because
it'll be only used as a component.

I assume you are building it as a component/class and just have it on
the frame for testing.

No, it is a complete component I derived from OVL example (remember:
I didn't programmed for a lot of time, I'm not used to oop, and my
approach is non conventional: I begin by picking what I need, trying
to understand it, so I'm in a blur for "some" time and one day, like
a puzzle, everything's fine:)

Same here, most of the time still pretty "blury" but making progress - for me all this is just a hobby but still like to get things to be done "correctly".

...

No: from my own experience (and softwares tests, a lot:) and the
observation/questioning of other, it must stay simple and ergonomic.
As it'll be used a the central part of an ERP, 95% of researches are
standalone ones (you search the name of the client OR its number but
not both, etc); the remainder 5% (essentially stats& accounting)
will be treated differently.

ERP, that is pretty big stuff, I believe there is at least one OpenSource one out there did you consider/looked at it.

In my own stuff I do a lot of these look ups with a control which is a "textctrl" with a combobox arrow to the right, a popup is opened when one clicks on the arrow or if one types into the TC. The popup contains a search control which receives the text one typed or was in the textctrl when one clicked on the arrow and it has an OLV with whatever number of columns. The search is done over all the columns as this works for my use case.

Guess what this control is used in ..., I am sure you guessed by now. It is in libui.searchctrl and how one uses it can be seen in controllers.d_book for e.g. self.authorSc or self.publisherSc. While working with Mike on this I have added the ability to add/modify an entry from the search control by passing in an appropriate dialog (could still do with some clean up) which allows to maintain e.g. publishers (could be suppliers, producers, accounts .....).

But on the other hand I might not get your use case at all:-)

Your email address says you live in france: you should know we like
to split hair �<;-)

Where in France are they doing that;-) . Lucky we get some good food and wines and not only split hear down in the South West:-) .

Werner

···

On 12/28/2011 02:40 PM, Jean-Yves F. Barbier wrote:

On Wed, 28 Dec 2011 09:46:57 +0100 > werner<wbruhin@free.fr> wrote:

> No, it is a complete component I derived from OVL example (remember:
> I didn't programmed for a lot of time, I'm not used to oop, and my
> approach is non conventional: I begin by picking what I need, trying
> to understand it, so I'm in a blur for "some" time and one day, like
> a puzzle, everything's fine:)

Same here, most of the time still pretty "blury" but making progress -
for me all this is just a hobby but still like to get things to be done
"correctly".

Yesbutno: as I answered Robin (about flickering) my 1st goal is
to have this important widget behave exactly the way I want it to,
even the ugly way - then I'll fix minor issues.

> No: from my own experience (and softwares tests, a lot:) and the
> observation/questioning of other, it must stay simple and ergonomic.
> As it'll be used a the central part of an ERP, 95% of researches are
> standalone ones (you search the name of the client OR its number but
> not both, etc); the remainder 5% (essentially stats& accounting)
> will be treated differently.

ERP, that is pretty big stuff, I believe there is at least one
OpenSource one out there did you consider/looked at it.

Nié? If you mean some other ERP could have fit, that a no.
I tested a lot of them for years, some are easy but lack functions
or even good, but with a scurvy client' service (apisoft was like
that: almost 3 months to patch a bug that kept the same cost price
when you copied and modified a composed item:(

Some needs you to read 5 tons of docs before being used (sage: I
spent 3.5 hours on it and never succeed to create an invoice, just
because the commands were absolutely non-intuitive.)

I don't like web ERPs, they're easy to maintain because there's no
client, but they lack all the heavy client power & flexibility (and
most of them are written with the feet, and more ugly: they use
almost exclusively mysql, which is a piece of shit).

Also, my approach comes from my former activity: computer shop, that
needs some specific process (such as RMA).

99% of them use the wrong architecture: they leave the base data
accessible from the client, which is an heresy and terribly
dangerous.

This is also a self formation to DBA and some programmation skills.

In my own stuff I do a lot of these look ups with a control which is a
"textctrl" with a combobox arrow to the right, a popup is opened when
one clicks on the arrow or if one types into the TC. The popup contains
a search control which receives the text one typed or was in the
textctrl when one clicked on the arrow and it has an OLV with whatever
number of columns. The search is done over all the columns as this
works for my use case.

In the ERP case this is not what is needed, as I told you, you
search for a client's name ou client's number, but not both of them.

This would also lead to too many queries as my DB follows the
atomicity standards: 99.999% isn't redondant (except taxes and grand
total because rates can change in time and you need your old
invoices to stay "frozen" at the time they were made).
ie: even names and firstnames are in a table and just integrity
references against clients/suppliers.

Guess what this control is used in ..., I am sure you guessed by now.
It is in libui.searchctrl and how one uses it can be seen in
controllers.d_book for e.g. self.authorSc or self.publisherSc. While
working with Mike on this I have added the ability to add/modify an
entry from the search control by passing in an appropriate dialog (could
still do with some clean up) which allows to maintain e.g. publishers
(could be suppliers, producers, accounts .....).

I try to not confuse the user, IMHO search capabilities should always
be visible as they're kinda first aid.
As I have used/tested many softwares of all qualities, I try to see
both sides of the problem: the conceptor one but also (and mainly)
the user's one.
If I can have most of users use my ERP almost without reading the
docs, then I'll consider it a win.

> Your email address says you live in france: you should know we like
> to split hair °<;-)

Where in France are they doing that;-) . Lucky we get some good food
and wines and not only split hear down in the South West:-) .

Yeah, france could be a terrific country... without poliotics nor
bureaucracy that plants idiotic laws and rules to make you mad
and reap more and more taxes (even juges are now obliged to
specialize to cover the text diarrhea).

···

On Wed, 28 Dec 2011 18:09:09 +0100 werner <wbruhin@free.fr> wrote:

--
* JHM wonders what Joey did to earn "I'd just like to say, for the
record, that Joey rules."-- Seen on #Debian