Hello fredvs,
you wrote on Mon, 30 Mar 2020 13:50:54 -0700 (MST):
> OK warning disabled for those 2 cases.
> I did use {$warnings off}/{$warnings on} vs {$warn 4110 off}.
>
> This to isolate the warnings off only for those 2 lines:
>
> {$warnings off}
> result:= (key <> 0) and (key <>
Hello Sieghard.
OK warning disabled for those 2 cases.
I did use {$warnings off}/{$warnings on} vs {$warn 4110 off}.
This to isolate the warnings off only for those 2 lines:
{$warnings off}
result:= (key <> 0) and (key <> word(not modmask));
{$warnings on}
{$warnings off}
foldlevelmask =
Hello fredvs,
you wrote on Mon, 30 Mar 2020 11:12:11 -0700 (MST):
> About range check error:
>
> > > msedatalist.pas(891,18) Warning: (4110) Range check error while
> > > evaluating constants (-193 must be between 0 and 255)
>
> Many thanks for your explanations.
> It seems that the
Ooops, in previous mail, please read: (warning 4110 in place of warning
6060):
About range check error:
> > msedatalist.pas(891,18) Warning: (4110) Range check error while
> > evaluating constants (-193 must be between 0 and 255)
Many thanks for your explanations.
It seems that the
Hello Seignard.
> Yes I was thinking to do that but it is **lot of work**, +- 500 cases to
> fix, sometimes in complicated code.
It was terminated yesterday, after lot of cups of coffee,
checking every case individually and following your advice: adding a last
else statement + comment.
> else;
Hello fredvs,
you wrote on Fri, 27 Mar 2020 18:30:11 -0700 (MST):
> I can understand that in a case of the variable is part of the procedure,
> like this:
...
> begin
> case b of // here warning
> 1: writeln('hello');
> end
> end;
...
> But for this, when the variable is
Hello fredvs,
you wrote on Sun, 29 Mar 2020 08:36:10 -0700 (MST):
> So, about those famous 2 last warnings:
>
> I propose this to make the compiler happy:
...
> > msedatalist.pas(891,18) Warning: (4110) Range check error while
> > evaluating constants (-193 must be between 0 and 255)
>
>
The same for the last warning:
Changing with this:
modmask = abs(shift or ctrl or alt or $1000 or pad);
...
result:= (key <> 0) and (key <> word((not modmask)));
Gives the warning:
mseactions.pas(763,34) Warning: (4110) Range check error while evaluating
constants (-63489 must be between 0 and
What is very strange is that I get also a warning with this (see abs()
added):
const
foldhiddenbit = 7;
foldhiddenmask = abs(1 shl foldhiddenbit);
currentfoldhiddenbit = 6;
currentfoldhiddenmask = abs(1 shl currentfoldhiddenbit);
foldlevelmask = byte(not (foldhiddenmask or
> why not just replace byte with integer
I just try it and with this you get 8 new warnings...
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
why not just replace byte with integer , i am not sure
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
why not just replace byte with integer , i am not sure
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Sorry I am a never-give-it-up...
So, about those famous 2 last warnings:
I propose this to make the compiler happy:
- First warning:
> msedatalist.pas(891,18) Warning: (4110) Range check error while evaluating
> constants (-193 must be between 0 and 255)
Point to:
foldlevelmask =
> OK,asap, first lots of cups of coffee and then I will jump into it.
Top chrono!
Done in commit 2da0695 following the Sieghard advises:
Not using {$warn 6060 off} but fixed for real, adding this statement at end
of case:
else; // Case statment added to make compiler happy...
Ok now
> Yes and did not find any problem.
ok , thats cool :)
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
> did you try compiling with fpc 3.0.4 with all these changes?
Yes and did not find any problem.
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
did you try compiling with fpc 3.0.4 with all these changes? just to
be sure of backward compatibility .
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
> yes , every things works fine so far ;)
Yep, excellent news!
So MSEgui will be fully compatible with last generation of ARM devices (that
is what promised by FPC team).
About trunk-warning fixes, it seems that there is not lot of candidate to do
it.
OK,asap, first lots of cups of coffee and
yes , every things works fine so far ;)
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Hello Code DZ.
Me too I was desperate, without to make MSEgui compatible with fpc trunk,
sure MSEgui will disappear.
But thanks to Sven (who knows maybe that I never give up) MSEgui is still on
the road.
Did you try to compile MSEide with fpc trunk, are layout problems all ok
now?
Fre;D
--
well done fred :D
In a moment, I lost hope , and eventually you did it :)
thanks for your effort
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re-re-hello Sieghard.
> I propose to add a - possibly empty, but AT LEAST commented! - default
> (else) clause.
You are right.
I will revert the last commit (that disabled the warning for many units) and
re-commit the code with warning on.
And if somebody want to do the fixes adding "else" in
Re-hello Sieghard.
> I propose to add a - possibly empty, but AT LEAST commented! - default
> (else) clause.
Yes I was thinking to do that but it is **lot of work**, +- 500 cases to
fix, sometimes in complicated code.
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
Hello Sieghard.
I totally agree with you, sometimes the warnings helps.
I can understand that in a case of the variable is part of the procedure,
like this:
procedure test;
var
b: 1..10;
begin
case b of // here warning
1: writeln('hello');
end
end;
Here I understand
Hello fredvs,
you wrote on Fri, 27 Mar 2020 15:04:49 -0700 (MST):
> With last fpc 3.3.1 trunk, there are warnings in case like this:
>
> procedure test;
> var
> b: 1..10;
> begin
> case b of // here warning
> 1: writeln('hello');
> end
> end;
>
> " Warning: (6060) Case
With last fpc 3.3.1 trunk, there are warnings in case like this:
procedure test;
var
b: 1..10;
begin
case b of // here warning
1: writeln('hello');
end
end;
" Warning: (6060) Case statement does not handle all possible cases."
In MSEgui there is lot of code that is
Hello fredvs,
you wrote on Wed, 18 Mar 2020 15:18:20 -0700 (MST):
> Hello Sieghard and others.
>
> Just by curiosity, do you have try the enum program example with Delphi ?
> Sadly I dont have delphi installed any more.
No, sorry, at least not an even marginally recent version.
Only Delphi 6
Hello Sieghard and others.
Just by curiosity, do you have try the enum program example with Delphi ?
Sadly I dont have delphi installed any more.
Here the test program:
PROGRAM enumtest;
type
tabulatorkindty =
(tak_none := 1,tak_left,tak_right,tak_centered,tak_decimal);
var
kind:
Hello fredvs,
you wrote on Sun, 15 Mar 2020 16:53:12 -0700 (MST):
> > What a glaring omission, no?
>
> Yes.
Thank you for your support.
> Also I am not totally convinced by the arguments to defend the choice of 0
> as initialization of a enum var.
> Imho, it would be much more logic to
> What a glaring omission, no?
Yes.
Also I am not totally convinced by the arguments to defend the choice of 0
as initialization of a enum var.
Imho, it would be much more logic to initialize with the first item and I do
not see what could be the problems.
Here the answer in fpc mailing-list
l.
Fre;D
De : Sieghard
Envoyé : dimanche 15 mars 2020 23:25
À : mseide-msegui-talk@lists.sourceforge.net
Objet : Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs,
you wrote on Fri, 13 Mar 2020 17:19:37 -0700 (MST):
> With
Hello fredvs,
you wrote on Fri, 13 Mar 2020 17:19:37 -0700 (MST):
> With your code I get this:
>
> $ /home/fred/weird/weirdtest
>
> low: we_2, value: 2; high: we_decade, value: 20
> 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
> we_2: 2Runtime error 107 at $00401293
>
> To resume, a enum variable is initialized with the first item of the enum.
Fake news, this is true:
To resume, a enum variable is initialized with 0.
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk
Hello.
An interesting post here:
http://free-pascal-general.1045716.n5.nabble.com/Re-New-Warnings-with-fpc-gt-3-2-0-fredvs-td5735027.html
To resume, a enum variable is initialized with the first item of the enum
list.
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
Hello Sieghard.
> Have a lot of fun!
With your code I get this:
$ /home/fred/weird/weirdtest
low: we_2, value: 2; high: we_decade, value: 20
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
we_2: 2Runtime error 107 at $00401293
$00401293
$0040104F
Hello fredvs,
you wrote on Thu, 12 Mar 2020 18:02:03 -0700 (MST):
> > Why could that drive someone crazy, ?
>
> Huh, I was talking about all the possibilities that enum gives and the
> difficult task to choose the best one.
An enum (C-speak) aka enumeration is just that: An enumeration of
Hello Sieghard.
> Why could that drive someone crazy, ?
Huh, I was talking about all the possibilities that enum gives and the
difficult task to choose the best one.
The "new illegal-nil-none item" in the enum can be placed everywhere but
imho at end will give shorter code and so less chance to
Hello fredvs,
you wrote on Thu, 12 Mar 2020 02:22:15 -0700 (MST):
> > BTW, I'd suggest to use the word "illegal"
>
> Ha, ok, in last commit I did use "none" or "nil", I will change it asap.
The name has no function, so I think it should be chosen on intended
function. If the member is used
> if not fixed.
Yes, as written in a previous mail, I let, for the sport, 2 Warnings to fix.
This is the first, the second is not bad too.
;-)
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing
> scrollbarclicked = ord(sba_end) + 1; // not a "good boy" code.
Imho, it is not a "good boy" code because later there is:
---> if kind = scrollbarareaty(scrollbarclicked) then // this gives a
warning with fpc 3.2.0, not fpc 3.0.4.
OK, I stop before to become (stay) completely crazy.
Fre;D
>Sorry I dont find now the code that demonstrate that it was easier if
> "sba_none" was placed at end.
OK, I found it.
This was a original code (see scrollbarclicked new added constant):
type
scrollbarareaty = (sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end);
const
scrollbarclicked =
Hello everybody!
We could also make something like this:
type
TOption = (optNil = -1, optOne, optTwo, optThree);
TValidOption = optOne..optThree;
var
o: TOption;
begin
o := optNil;
for o := Low(TValidOption) to High(TValidOption) do
;
end.
Regards.
Roland
--
Sent from:
Sorry to monopolize.
But re-re ooops.
In previous mail, when I did try to explain why I opted to place the new
"sba_none" at end, I did choose a wrong example.
Of course the order of enum has no influence on bu1:= low(scrollbarareaty)
to high(scrollbarareaty).
But, (trust me), it was more easy
Re-ooops.
In previous mail:
>Take this original example:
>scrollbarareaty =
>(sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end,sba_clicked,sba_none)
Please read (forget sba_clicked,sba_none):
Take this original example:
scrollbarareaty =
(sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end)
Fre;D
Oops, in previous mail:
>Take this original example:
>scrollbarareaty =
>(sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end,sba_clicked,sba_none)
Please read (forget sba_none):
Take this original example:
scrollbarareaty =
(sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end,sba_clicked)
Fre;D
--
Hello Sieghard
**Many thanks** for all that clear explanation.
> BTW, I'd suggest to use the word "illegal"
Ha, ok, in last commit I did use "none" or "nil", I will change it asap.
> tabulatorkindty = (tak_illegal:= -1, tak_left, tak_right,
> tak_centered,tak_decimal);
Like explained to
Hello fredvs,
you wrote on Wed, 11 Mar 2020 02:22:07 -0700 (MST):
> Here a example maybe more clear:
Let's see...
> msedrawtext.pas(1115,48) Warning: range check error while evaluating
> constants (-1 must be between 0 and 3)
>
> This warning point to:
>
> ---> if (kind <>
Hello Roland.
> but I am sure that"tabulatorkindty(tak_nil)" can be replaced with
> "tak_nil".
;-)
OK, done in last commit b7be824.
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
Hello Fred!
Thank you for your answer, and for the schmilblick.
I don't know which order is better, but I am sure that
"tabulatorkindty(tak_nil)" can be replaced with "tak_nil".
Regards.
Roland
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
Hello Roland.
Sorry, I did commit some change following the advises of fpc-mailing list:
https://github.com/mse-org/mseide-msegui/commit/
Of course it can be changed but is is to make advance the "schmilblick".
It takes the same idea as yours, the only thing changed is that tak_nil is
placed
For me, I don't understand "tabulatorkindty(-1)". I don't understand why FPC
3.0.4 accept it without even a warning.
With FPC 3.0.4, the following code compiles without warning and works:
type
tabulatorkindty = (ak_left, tak_right, tak_centered, tak_decimal);
var
kind: tabulatorkindty;
Hello Code DZ and all others.
> so i think this list should be extended
Maybe.
But after the conversation in:
http://free-pascal-general.1045716.n5.nabble.com/New-Warnings-with-fpc-gt-3-2-0-td5734996.html
Maybe also some code should be fixed with the "good boy" way.
So the question is:
Hi fred
i don't know why martin has disable some warnings while ago and not fixing it
you may have seen this in every msegui unit :
{$if fpc_fullversion >= 030100}
{$warn 5089 off}
{$warn 5090 off}
{$warn 5093 off}
{$warn 6058 off}
{$endif}
so i think this list should be extended
Hello.
I did create a new topic about this in fpc mailing-list:
http://free-pascal-general.1045716.n5.nabble.com/New-Warnings-with-fpc-gt-3-2-0-td5734996.html
Maybe some light from there...
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
Hello Seighard.
Here a example maybe more clear:
msedrawtext.pas(1115,48) Warning: range check error while evaluating
constants (-1 must be between 0 and 3)
This warning point to:
---> if (kind <> tabulatorkindty(-1))
and tabulatorkindty is declared as:
---> tabulatorkindty =
Hello fredvs,
you wrote on Tue, 10 Mar 2020 12:52:22 -0700 (MST):
> Hello Roland.
>
> Doing this:
>
> const
> foldhiddenbit = 7;
> foldhiddenmask = byte(1) shl foldhiddenbit;
> currentfoldhiddenbit = 6;
> currentfoldhiddenmask = byte(1) shl currentfoldhiddenbit;
> foldlevelmask = byte(not
Hello Roland.
Doing this:
const
foldhiddenbit = 7;
foldhiddenmask = byte(1) shl foldhiddenbit;
currentfoldhiddenbit = 6;
currentfoldhiddenmask = byte(1) shl currentfoldhiddenbit;
foldlevelmask = byte(not (foldhiddenmask or currentfoldhiddenmask));
foldissumbit = 0;
foldissummask = $01;
Hello Fred!
For this:
msedatalist.pas(891,18) Warning: range check error while evaluating
constants (-193 must be between 0 and 255)
I would try to replace "1" with "byte(1)".
const
foldhiddenbit = 7;
foldhiddenmask = byte(1) shl foldhiddenbit; // <
currentfoldhiddenbit = 6;
Hello everybody.
I think that the proposition of Code DZ is a "must be done" (first of all,
fix the Warnings at compilation using fpc 3.0.4).
Here are all the warnings while compiling mseide with fpc 3.0.4.
You may see that all the warnings are about string type conversion in
59 matches
Mail list logo
