lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] wx wine non-anomaly


From: Vadim Zeitlin
Subject: Re: [lmi] wx wine non-anomaly
Date: Thu, 21 Sep 2017 17:31:38 +0200

On Thu, 21 Sep 2017 14:44:51 +0000 Greg Chicares <address@hidden> wrote:

GC> This is curious but not anomalous, and I don't know whether or not it's
GC> really interesting to anyone but me.
GC> 
GC> Since I abandoned msw, I've run msw builds of lmi only under wine, and
GC> the not-an-emulator runs lmi almost perfectly, but there's one problem
GC> that actually makes lmi really hard to use: the "Policy" listbox's
GC> contents are shown in a seemingly random order. I've borne this stoically
GC> for many months, but today I decided I had to fix it, and it turned out
GC> to be surprisingly easy:
GC> 
GC> -                        <style>wxLB_SINGLE</style>
GC> +                        <style>wxLB_SINGLE|wxLB_SORT</style>
GC> 
GC> The curiosity is that the listbox contents seem always to have been
GC> sorted on a native msw platform. (Or, conceivably but not likely, they
GC> were listed in the corresponding files' timestamp order, which happened
GC> to be alphabetical elsewhere in the past, but isn't now, perhaps due to
GC> SSD queuing...but that seems far-fetched.)

 The link to SSD does seem a bit far-fetched, but the fact that the items
appeared to be sorted before may only be due to the files being sorted
alphabetically when iterating over the directory in fetch_product_names(),
I don't see any other explanation. In particular, I'm quite sure that the
listbox doesn't sort the items on its own, even under not-not-an-emulator.

GC> I'll add wxLB_SORT to all '*.skin' files soon.

 This does seem to be the right thing to do anyhow, of course.


 BTW, while looking at this code, I've noticed this comment in
mvc_controller.cpp:

        // WX !! Append(wxArrayString const&) "may be much faster"
        // according to wx online help, but that seems untrue: its
        // implementation just uses a loop.

Saying that the documentation is untrue doesn't appear to be true (any
longer?) as I was pretty sure, and confirmed it before posting this, that
Append(wxArrayString) overload, which forwards to AppendItems(), which
calls DoAppendItems(), which calls DoInsertItems() should indeed be
noticeably faster than calling Append() in a loop. Of course, the
difference will likely be only noticeable for hundreds of items and not
just a few, but this is generic code which is used for all list boxes, so
if the speed of inserting into them is ever a concern, it could be worth
changing this (and, of course, I could do it if you'd like, as it's rather
trivial).

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]