On 09/04/11 12:47, Manolo Gouy wrote:
>>> I see here, that there is a bug on OS X with the BROWSE_SAVE_FILE
>>> mode when the filter() function is used: the filter string needs to
>>> end with a "\n"; without it the program crashes. Do you see
>>> that as well ?
>>
>> Sounds like I should add a check for this in filter()
>> and append a trailing \n if it's missing.
>>
> Please, don't do that. With r.9029, the requirement for a terminal
> \n is removed.
Oh, OK.
I guess that explains why I couldn't replicate ;)
since I updated to latest SVN before testing.
I forgot you ported my Mac version of FNFC to cocoa,
so there's a bit of new stuff in there.
Manolo -- while looking into this, playing around with
examples/native*.cxx program, I noticed a different problem.
If I run that app and do these steps:
1) File -> Save As, filter appears
2) File -> Open, *filter is missing*
3) File -> Save As, *filter is missing*
The filter being missing is the problem.
In the example code, it sets the filter() once
at the beginning of the app, the assumption being
it remains in effect for the widget unless changed.
But it seems the way the FNFC mac code is written,
it doesn't re-apply the filter on subsequent calls
to posting the dialog. filter() shows the string still set,
but internally the code is skipping calling prepareMacFilter()
I think because _filt_total is getting reset to zero in show(),
just after post() is called.
I could change the example program to always call filter()
before calling show(), which does fix the problem,
but I'm not sure it should need to.
Perhaps _filt_total shouldn't be reset to zero in show()?
Or instead, maybe the checks for _filt_total in post()
should be replaced with checks to see if filter() is NULL/""
and if not, call prepareMacFilter() so that the filter
gets re-applied.
Opinions? Or perhaps other options?
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
