Closed GoogleCodeExporter closed 8 years ago
The combination of using the word "dynamic" and including "DynamicVariables" in
you
example may unintentionally misdirect readers.
The problem exhibts when the variable "FontSize" is not a number.
I can't find a relationship between the problem and the "DynamicVariables"
parameter.
Original comment by djmcnz@gmail.com
on 19 Dec 2009 at 7:30
Yes, you are right.
Actually, the direct cause that shows the error is not "DynamicVariables". The
reason for the direct cause is that FontSize is 0.
When using Calc, even if it defines the value fixed like "Formula=20", Calc
certainly
returns 0 once at the time of loading of a skin.
In order to try dynamic font size, there is no method except using
"DynamicVariables", and it is a formula to use Calc for this approach. That is,
the
occurrence of the error doesn't escape if it tries to change the font size
dynamically.
The problem which I point out is not about the defect of one function, and it is
about the practical trouble by the collision of some functions.
I am not sure but I think that it should check off of an error message about
FontSize. Because this error doesn't have the meaning so much. Is there on
earth a
user who defines it by mistake as "FontSize=0"?
Original comment by kenz0.sa...@gmail.com
on 19 Dec 2009 at 9:55
I believe this is the error I get upon satart after install. dried the zip and
the
download .exe both with same unusable install, app just shows fine lines on
screen,
any ideas. did not find help in forums through search. Using Win7Pro
Original comment by alkon...@gmail.com
on 3 Jan 2010 at 9:46
I'd change it so as not to indicate the error when DynamicVariables=1 and
FontSize=0.
Original comment by spx268
on 3 Feb 2010 at 3:27
Changed in r328.
Original comment by spx268
on 4 Feb 2010 at 7:19
Thank you for taking care of this issue.
Although I reported the problem which mentioned DynamicVariables as the example
here,
it is not actually the problem limited to DynamicVariables.
A definition like "FontSize=", "FontSize=0", "FontSize=ABC" should be ignored
as an
invalid definition. However, it is substance of the problem that such an invalid
definition is not ignored.
Now, as for DynamicVariables, it seems that the problem was solved by r328.
However,
on DynamicVariables=0, an error message still appears by invalid definition.
To prevent the user's confusion, I think that it should not display an error
message
by an invalid definition and should set a default value.
Original comment by kenz0.sa...@gmail.com
on 4 Feb 2010 at 2:12
A result of "FontSize=", "FontSize=0", "FontSize=ABC" will be 0 because these
are
converted loose by ConfigParser. It's possible to change it in FontSize so that
the
default value (=10) is used instead of 0.
(However, even if you'd like to use "FontSize=0" dynamically by
DynamicVariables=1,
10 is used instead.)
Original comment by spx268
on 5 Feb 2010 at 7:05
Yes, I was also concerned about the point. It is inconvenient that the default
value
(FontSize=10) is set on DynamicVariables=1 as you say.
So, does the following behavior become possible?
- "FontSize=" or "FontSize=ABC" is evaluated as invalid definition so the default
value is set.
- "FontSize=0" is evaluated as valid definition, but it is invisible. (error message
is not needed)
These are irrespective of setting of DynamicVariables and are common behavior. I
think that this behavior is natural and is proper solution for now.
How do you think about this?
Original comment by kenz0.sa...@gmail.com
on 5 Feb 2010 at 11:07
I agree.
I'd try to change the loose parsing to the strict.
Original comment by spx268
on 5 Feb 2010 at 2:06
Try this.
- CHANGED: ConfigParser now reads value strictly. Note that this change affects
the
reading of various skin setting values.
For instance:
- OK
FontSize=10
FontSize=0
- NG (uses default value instead)
FontSize=
FontSize=ABC
FontSize=20ABC (has been parsed as "FontSize=20" until now.)
Original comment by spx268
on 7 Feb 2010 at 3:50
Attachments:
I have confirmed accurate behavior now.
Thanks. I appreciate it.
Original comment by kenz0.sa...@gmail.com
on 7 Feb 2010 at 7:35
Changed in r330.
Original comment by spx268
on 8 Feb 2010 at 2:19
Original issue reported on code.google.com by
kenz0.sa...@gmail.com
on 7 Nov 2009 at 1:45