<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7036.0">
<TITLE>wxSpinCtrl use for integer values under WIN32</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P><FONT SIZE=2 FACE="Arial">Impacts preferences_widgets.cpp, open.cpp, possibly other wxwindows modules.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">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.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">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.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">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:</FONT></P>
<P><FONT SIZE=2 FACE="Arial"> caching_value->SetRange( 0, 1000000 );</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">But if you try to put in, say, 20000, and touch either of the SpinCtrl arrows, it immediately reverts to 16960.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">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.</FONT></P>
<BR>
<P><FONT SIZE=2 FACE="Arial">Spinctrl may be doing some kind of modulus arithmetic, though I am not certain. The remainder of 1000000 is:</FONT>
<BR><FONT SIZE=2 FACE="Arial">30*32768 = 983040</FONT>
<BR><FONT SIZE=2 FACE="Arial">1000000 - 983040 = 16960</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">And 16960 is the upper limit that spin control is recognizing for cache.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">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.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">(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.)</FONT></P>
<P><FONT SIZE=2 FACE="Arial">As always, I could be totally off the mark in what I've written, but have spent a fair amount of time checking.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Thanks, Dnumgis and Trax, for your inputs.</FONT>
</P>
<BR>
<BR>
<BR>
</BODY>
</HTML>