On Wed, 13 Jun 2012 14:53:44 -0700, Albrecht Schloßer <[email protected]> wrote:
>On 13.06.2012 21:57, Richard Sanders wrote: >> From the docs >> >> "int Fl_Input_::maximum_size ( ) const [inline] >> >> Gets the maximum length of the input field. >> >> Todo: >> It is not clear if this function is actually required" >> >> >> re Todo >> >> I think this is required. >> >> When the size of the contents of the input field needs to be limited, >> so it can be stored in a fixed length buffer for instance, this is >> very useful. >> >> eg Fl_Input_::maximum_size (30); >> >> When the content are transfered to a dynamic buffer, again, very >> useful. >> >> eg >> >> char *buffer = (char *)alloca(Fl_Input_::maximum_size () + 1); >> >> I vote to keep Fl_Input_::maximum_size () > >I believe that this is still available (and we're talking about >FLTK 1.3, don't we?), but here we have the problem that we need >to distinguish the number of characters and the number of bytes, >which can be different, since we have the text in UTF-8 encoding. > >I think that the current (svn) version has been fixed to use the >number of characters, so that the (fixed) buffer size mentioned >above should probably be multiplied by 4 - however, it is still >possible to use a *fixed* size. > >Albrecht I see the problem. I am more interested in Fl_Input_::maximum_size (30); setting the input character count as a way to limit the characters a user can enter, the byte count is secondy as a suitable fixed size buffer is just coding. What Fl_Input_::maximum_size () returns is imaterial to a point, as long as it is understood, again just coding. Byte count would be ideal but character count would also work, as you say multiplied by 4. All in all Fl_Input_::maximum_size () dealing in characters rather than bytes would (I think) the most useful. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
