[vlc-devel] wxSpinCtrl use for integer values under WIN32

[Mark Moriarty]

Impacts preferences_widgets.cpp, open.cpp, possibly other wxwindows modules.

I committed a change earlier today, a hack to preferences_widgets.cpp for
WIN32 only.  The change consisted of reversing the order of the range of
values in the SpinCtrl call, changing them from -100000000,100000000 to
100000000,-100000000.  This corrected a problem that Trax had noted, though
there remains a similar problem if you do a File -- OpenCaptureDevice, and
select the Advanced settings.

With the above change, under Windows the integer-related wxwindows
Preference up-arrows now increment, and the down-arrows decrement.  While
this indeed worked, it did not make sense.

With nudges from Dnumgis and Trax I poked a bit more.  Under Windows, the
wxwindows interface, if you do a File -- Open anything, then check the
"caching" box, you will find anomalous behavior.  In Open.cpp the code
shows:
   caching_value->SetRange( 0, 1000000 );

But if you try to put in, say, 20000, and touch either of the SpinCtrl
arrows, it immediately reverts to 16960.

It looks like under Windows the integer spin control is being interpreted as
a normal Windows 16 bit integer, something that should be valued between
-32768 and +32767, and that giving it larger ranges is driving it outside of
spec.  In the case of Preferences, where the range was specified as +/-
100,000,000 it operated with a complete reversal -- up arrow decremented,
down arrow incremented.  In the case of caching, the directionality is OK
but it is clearly clipping.


Spinctrl may be doing some kind of modulus arithmetic, though I am not
certain.  The remainder of 1000000 is:
30*32768 = 983040
1000000 - 983040 = 16960

And 16960 is the upper limit that spin control is recognizing for cache.

So, the commit I made earlier today does work, but overall this should be
fixed.  wxSpinCtrl should get corrected one way or another.  We can make
sure that the range for SpinCtrl values is stipulated as being between
-32768 and + 32767 (no 1000000 kind of values), or switch to some other kind
of specifier.  Wxwidgets may be doing good range checking, but we're clearly
supplying it invalid ranges under windows.

(Trax pointed out that it is nice to be able to spec higher than 32K for
ports, though I don't know how serious a deficiency it would be.  For
heavy-duty users the command-line should still be fine -- this really only
limits people who need to work through the wxwindows Settings -- Preferences
interface.  Similarly, I don't know if there is some kind of v4l wxwindows
support under *nix, in which case a large number may be needed for frequency
-- that can be handled via an ifdef similar to my prior commit.)

As always, I could be totally off the mark in what I've written, but have
spent a fair amount of time checking.

Thanks, Dnumgis and Trax, for your inputs.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20050129/24514dc3/attachment.html>