Hi list,
My purpose is simple: I've a list that can be sorted by clicking on a column
header, and I'd like it to be already sorted at opening - but I can't find
how to send a fake event to the wanted column to achieve that.
JY
--
Fourth Law of Thermodynamics:
If the probability of success is not almost one, it is damn near zero.
-- David Ellis
Although this doesn't answer your question on how to "fake" an event:
When you say "opening" do you mean initializing the panel and the
listctrl and showing that panel?
In wxPython Demo 2.8.11.0 -> Core Windows/Control -> ListCtrl -> line
131 (or somewhere around there) you will see "#self.SortListItems(0,
True)". The zero is the column number in the ListCtrl(). If you un-
comment out that line you will see the demo sort column zero. Because
SortListItems() is called before Show(True) the listctrl's column will
be sorted before you visibly see the listctrl widget.
You could put self.listctrl.SortListItems( columnToSort, True ) in an
event handler like OnUpdateUI(self, event) or OnPaint(self, event)
I assumed you are talking about wx.ListCtrl, as ListBox does not have
headers (to my knowledge)
http://objectmix.com/python/34459-wxpython-how-add-sorting-listctrl.html
On Nov 27, 1:29 pm, "Jean-Yves F. Barbier" <12u...@gmail.com> wrote:
My purpose is simple: I've a list that can be sorted by clicking on a column
header, and I'd like it to be already sorted at opening - but I can't find
how to send a fake event to the wanted column to achieve that.
JY
In fact I'm not directly using a ListCtrl, I use a VirtualObjectListView,
but knowing what I was looking far with your answer, I found
"SetSortColumn" that seems to be a wrapper to "SortListItems" and worked.
Thanks!
On Sun, 27 Nov 2011 15:28:17 -0800 (PST) DevPlayer <devplayer@gmail.com> wrote:
Although this doesn't answer your question on how to "fake" an event:
When you say "opening" do you mean initializing the panel and the
listctrl and showing that panel?In wxPython Demo 2.8.11.0 -> Core Windows/Control -> ListCtrl -> line
131 (or somewhere around there) you will see "#self.SortListItems(0,
True)". The zero is the column number in the ListCtrl(). If you un-
comment out that line you will see the demo sort column zero. Because
SortListItems() is called before Show(True) the listctrl's column will
be sorted before you visibly see the listctrl widget.You could put self.listctrl.SortListItems( columnToSort, True ) in an
event handler like OnUpdateUI(self, event) or OnPaint(self, event)I assumed you are talking about wx.ListCtrl, as ListBox does not have
headers (to my knowledge)
--
Humans do claim a great deal for that particular emotion (love).
-- Spock, "The Lights of Zetar", stardate 5725.6
By the way there is a style flag wx.LB_SORT. Whether the widget your
using and if it could apply to a column I couldn't tell you.
...
In fact I'm not directly using a ListCtrl, I use a VirtualObjectListView,
but knowing what I was looking far with your answer, I found
"SetSortColumn" that seems to be a wrapper to "SortListItems" and worked.
As you use a VirtualOLV I assume your data comes out of a database, if that is the case it might be faster to let the database do the sorting.
Werner
On 11/28/2011 12:59 AM, Jean-Yves F. Barbier wrote:
My personal preference is to offload as much processing from a server
as possible. I prefer db servers to mostly retrieve/send and archive
data. Sorting for UI purposes, to me, is more a client side thing.
Personally I've never written any app where users would notice
performance issues. All app's I've ever developed where for a user
base well below 20 users max. As to web apps I've done, to be honest,
were very amateurish aka nuke.
This is the case: sorting in the widget changes the DB query (in fact it
is mandatory to do so, otherwise you would have holes in the sorted list).
My goal was just to have the widget behave like its column was clicked,
for visual coherence; fortunately VOLV SetSortColumn do this:)
On Mon, 28 Nov 2011 11:00:52 +0100 werner <wbruhin@free.fr> wrote:
As you use a VirtualOLV I assume your data comes out of a database, if
that is the case it might be faster to let the database do the sorting.
--
Blackout restrictions apply.
I am not sure what you mean.
Are you saying that when python sorts the data on the client verse the
database query sorts the data on the db server you can lose data?
Can you explain why it's mandatory and how do you get holes in the
list. I ask because I have not heard of this.
On Mon, Nov 28, 2011 at 9:47 AM, Jean-Yves F. Barbier <12ukwn@gmail.com> wrote:
This is the case: sorting in the widget changes the DB query (in fact it
is mandatory to do so, otherwise you would have holes in the sorted list).
I am not sure what you mean.
Are you saying that when python sorts the data on the client verse the
database query sorts the data on the db server you can lose data?
No, I mean when python is sorting on a small list from DB,
you'll "loose" (won't see) rows as you're working on a window and
not on the whole DB.
Imagine you have a spreadsheet with some columns and 30,000 lines,
it is sorted on the 1st column: cliNb (an integer).
If you go anywhere into the list and re-sort only a small
amount of lines, lets say lines: cliNb=[500-600], but this
time on familyName.
You now have holes in your window of sort, because for example
cliNb=1 has a familyName that should be appear this window.
Can you explain why it's mandatory and how do you get holes in the
list. I ask because I have not heard of this.
This is what I do:
* I set total Nb of rows to "SELECT count(*) FROM mytable", lets say
it is 1,500,000 (so my VRULE reflect the real size of the table)
* I read a small sorted list of rows from mytable (~400 rows) in
cache
* When the vovl ask for rowItem (list index), I do several things:
*Is rowItem cached?
*YES: Am I at the beginning of the list?
*YES: *continue
*NO: *shift rowItem to have a correspondance with the cache
index (ie: rowItem=45,247 => cacheIdx=204)
*NO: *Calculate beginning|end of cache offset
*Fill cache from DB
*Return a Storage object containing all columns values
So, for the reason above, even if rowItem is cached but the
sorting column has changed, I issue a new DB query with the new
order.
I must say that python have some drawbacks I don't like that makes it
unpleasant to work with: asserting that None = False (really, who
made THIS?!), or the lack of switch/case, or far worse: the fact
that a pgm written 1.5 years ago don't work anymore because of
internal changes - so I'll finish and debug my actual project, and
rewrite it into, may be Erlang, as I just discovered wx is ported
under this language (LUA isn't possible as virtual functions aren't
ported:(
On Mon, 28 Nov 2011 16:50:03 -0500 Dev Player <devplayer@gmail.com> wrote:
--
A woman takes off her claim to respect along with her garments.
-- Herodotus
not much to add here -- but I'll bite:
I must say that python have some drawbacks I don't like that makes it
unpleasant to work with: asserting that None = False (really, who
made THIS?!), or the lack of switch/case, or far worse: the fact
that a pgm written 1.5 years ago don't work anymore because of
internal changes - so I'll finish and debug my actual project, and
rewrite it into, may be Erlang,
there may be some wonderful advantages to Erlang, but I can't see the issues you mentioned as big Python warts:
> asserting that None = False
None is not the same as False. Try--
None == False
it evaluates to False (just like Lua (false == nil) )
None does evaluate to False in boolean expression:
if None:
for instance. But so does 0, 0.0, "", , and probably others. Personally, I'd rather that ONLY Booleans be accepted in conditionals, but it's not a big deal, and it's not unique to python -- 0 is false in a lot of languages, at least. (Erlang?)
> lack of switch/case
There are times when that would be nice, but most of the uses of switch-case I've seen in other languages would be better handled with a dict, or subclassing, or ... -- At last resort, nested elif really isn't that bad.
> a pgm written 1.5 years ago don't work anymore because of
> internal changes
really? That's quite rare -- I don't think I've had a problem with that in 13 years and Python 1.5 to 2.7. You may have hit an unlucky case.
Give it a chance, it may grow on you...
-Chris
On 11/28/2011 2:46 PM, Jean-Yves F. Barbier wrote:
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
> asserting that None = False
None is not the same as False. Try--
None == False
a=None
if not a: print("burp")
...
burp
IMHO it should only respond to something like:
if a is None:
as NULL is not a value.
Personally, I'd rather that ONLY Booleans be accepted in conditionals,
but it's not a big deal, and it's not unique to python -- 0 is false in
a lot of languages, at least. (Erlang?)
No, booleans are alone and not mixed up with numbers.
> lack of switch/case
There are times when that would be nice, but most of the uses of
switch-case I've seen in other languages would be better handled with a
dict, or subclassing, or ... -- At last resort, nested elif really isn't
that bad.
Its syntax is shorter (and more clear for me), but I that should be
a matter of habitude.
> a pgm written 1.5 years ago don't work anymore because of
> internal changesreally? That's quite rare -- I don't think I've had a problem with that
in 13 years and Python 1.5 to 2.7. You may have hit an unlucky case.
May be it was that, I'll check when possible.
On the bad side it's bloated and slow, on the good side it has a lot
of libs; I guess no language's perfect.
JY
On Mon, 28 Nov 2011 16:51:15 -0800 Chris Barker <Chris.Barker@noaa.gov> wrote:
--
Colors may fade in time.
Jean-Yves F. Barbier wrote:
a=None
if not a: print("burp")
...
burpIMHO it should only respond to something like:
if a is None:
as NULL is not a value.
Surely you must see that this is just an opinion, and not a statement of
universal correctness. It's a design decision that has to be made by
the language designer. Personally, I find it perfectly natural that 0,
False, "", None, , and {} all evaluate to 'false' in a Boolean
context. I find myself annoyed in PHP when the same thing doesn't work.
You may find it unnatural because your "native" language (Erlang?) does
not have the same philosophy. That does not make Python wrong and
Erlang right.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
+1
I would go mad if 0, False, "", None, , and {} evaluated to
something else than 'false'. It is so convenient that it feels
perfectly natural to use them in if statements. I know nothing about
Erlang, but I'll keep my Python close to me 
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 29 November 2011 04:00, Tim Roberts wrote:
Jean-Yves F. Barbier wrote:
a=None
if not a: print("burp")
...
burpIMHO it should only respond to something like:
if a is None:
as NULL is not a value.Surely you must see that this is just an opinion, and not a statement of
universal correctness. It's a design decision that has to be made by
the language designer. Personally, I find it perfectly natural that 0,
False, "", None, , and {} all evaluate to 'false' in a Boolean
context. I find myself annoyed in PHP when the same thing doesn't work.You may find it unnatural because your "native" language (Erlang?) does
not have the same philosophy. That does not make Python wrong and
Erlang right.
The other thing to remember is that it is a matter of choice & style,
each programmer is free to make such items explicit if appropriate, i.e.:
if not (None == a): # N.B. if a = 0, a = or a = '' this will
evaluate to True
if not (0 == a): # N.B. if a = None, a = or a = '' this will
evaluate to True
if len(s) > 0: # N.B. if s = 0 will cause an exception.
or even if not v in [None, '', ]: # My check for has a value, N.B.
v = 0 IS a value.
etc.,
personally I prefer to use explicit tests because of my background bit I
do have a more bit of an issue with the few languages/compilers where 0
<> 0L <> 0.0, (they are out there and cause all sort of fun).
Gadget/Steve
On 29/11/2011 8:56 AM, Andrea Gavana wrote:
On 29 November 2011 04:00, Tim Roberts wrote:
Jean-Yves F. Barbier wrote:
a=None
if not a: print("burp")
...
burpIMHO it should only respond to something like:
if a is None:
as NULL is not a value.Surely you must see that this is just an opinion, and not a statement of
universal correctness. It's a design decision that has to be made by
the language designer. Personally, I find it perfectly natural that 0,
False, "", None, , and {} all evaluate to 'false' in a Boolean
context. I find myself annoyed in PHP when the same thing doesn't work.You may find it unnatural because your "native" language (Erlang?) does
not have the same philosophy. That does not make Python wrong and
Erlang right.+1
I would go mad if 0, False, "", None, , and {} evaluated to
something else than 'false'. It is so convenient that it feels
perfectly natural to use them in if statements. I know nothing about
Erlang, but I'll keep my Python close to meAndrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
I would be happier with that (explicite is better than implicit), but remember that PYthon didn't used to ahve a bool type at all. There is a great thread in comp.lang.python titled:
PEP 285: Adding a bool type
if you are interested in the history, and some great discussion of the issues.
But key is that python is not determinein "true" or "false", but rather "something" or "nothing":
and empty list is nothing
a length-zeros string is nothing
a 0.0 is nothing
None is nothing.
All that being said, if you are not asking something or nothing, but rather, "has this value been set?" or something like that, than use:
if x is None:
do_something()
That's a very good practice, anyway.
-Chris
On 11/29/11 12:56 AM, Andrea Gavana wrote:
I would go mad if 0, False, "", None, , and {} evaluated to
something else than 'false'. It is so convenient that it feels
perfectly natural to use them in if statements.
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
if not (None == a): # N.B. if a = 0, a = or a = '' this will
evaluate to True
This really should be:
if not (a is None)...
(try == with a numpy array some day....)
personally I prefer to use explicit tests
me too.
-Chris
On 11/29/11 2:05 AM, Gadget/Steve wrote:
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
That's really hard to read. How about:
if a is not None:
Michael
On 2011-11-29 5:17 PM, Chris.Barker wrote:
On 11/29/11 2:05 AM, Gadget/Steve wrote:
if not (None == a): # N.B. if a = 0, a = or a = '' this will
evaluate to TrueThis really should be:
if not (a is None)...
On2011-11-29 5:17 PM, Chris.Barker wrote:
if not (None == a): # N.B. if a = 0, a =or a = ‘’ this will
evaluate to TrueThis really should be: if not (a is None)...That's really hard to read. How about: if a is not None: Michaela = 1
not (a is None)
True
a is not None
True
a is (not None)
False
Something = not None
a is Something
False
The two last fail because not None === True, 1 <> True
Remember **is** checks for identical items rather then equal
items.
Gadget/Steve
On 30/11/2011 1:16 AM, Michael Hipp wrote:
On 11/29/11 2:05 AM, Gadget/Steve wrote:
That's really hard to read. How about:
if a is not None:
...
>>> a = 1
>>> not (a is None)
True
>>> a is not None
True
>>> a is (not None)
False
...
The two last fail because not None === True, 1 <> True
Remember *is* checks for identical items rather then equal items.
right and "is not" is defined as a single operator in Python, so it is the exact opposite of "is", which is what we want --plus it is more readable.
-Chris
On 11/29/2011 10:05 PM, Gadget/Steve wrote:
On 30/11/2011 1:16 AM, Michael Hipp wrote:
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
if not (None == a): # N.B. if a = 0, a = or a = '' this will
evaluate to TrueThis really should be:
if not (a is None)...
That's really hard to read. How about:
if a is not None:
Michael
>>> a = 1
>>> not (a is None)
True
>>> a is not None
True
>>> a is (not None)
False
>>> Something = not None
>>> a is Something
False
>>>
The two last fail because not None === True, 1 <> True
Remember *is* checks for identical items rather then equal items.
I know what *is* does. Can you show me some example where 'a is not None' returns a different result than 'not (a is None)'? I haven't been able to find one, but my brain might have some bad sectors:
>>> a = 0
>>> a is not None, not (a is None)
(True, True)
>>> a = 1
>>> a is not None, not (a is None)
(True, True)
>>> a = None
>>> a is not None, not (a is None)
(False, False)
>>> a = False
>>> a is not None, not (a is None)
(True, True)
>>> a =
>>> a is not None, not (a is None)
(True, True)
>>> a = Exception()
>>> a is not None, not (a is None)
(True, True)
>>> a = not None
>>> a is not None, not (a is None)
(True, True)
Michael
On 2011-11-30 12:05 AM, Gadget/Steve wrote:
On 30/11/2011 1:16 AM, Michael Hipp wrote:
On 2011-11-29 5:17 PM, Chris.Barker wrote:
On 11/29/11 2:05 AM, Gadget/Steve wrote: