[SOLVED] something is funny between 1.2 and 1.4 Lazarus

[munair]

You seem to like writing more than reading. I follow Bart.

Bart wrote me

Code: [Select]

As was pointed out to you this is because you supply an empty path to FindAllFiles.
See my fix, I supply CurrentDir as the path.
when I do not supply an empty path to findAllFiles that is precisely  what SetCurrentDir does it supplies FindAllFiles to the directory that is set by that function call.
I still say it is lazarus 1.4.0 because the FPC is the same this I am not supplying a path to FindAllFiles. is DEAD wrong again that is what SetCurrentDir does

That behaviour was changed in 1.4. So you may argue that this is a bug in 1.4, while others may argue it was a bug in 1.2.6

By the by, I get:

The following package failed to load:

uniqueinstance_package
See Project -> Project Inspector

when I try to load your project on Linux.

[userx-bw]

Not realy related but I see lots of code like:

Code: [Select]

  if Stayontop.Checked = true

This is a rather redundant style of coding.
There is no need to compare the value of a boolean against true or false.
Just a simple if Stayontop.Checked is enough.
If it would not be enough then there would be no end to it, since (Stayontop.Checked = true) itself is a boolean, and by your programming logic it should be compared to either true or false, and so on.

Code: [Select]

  if ((((Stayontop.Checked = true)=true)=true)=true)=true) ... ad infinitum

Further more:

Code: [Select]

procedure TForm1.StayontopClick(Sender: TObject);
begin
  if Stayontop.Checked = false
    then
     begin
     Stayontop.Checked:=true;
     FormStyle:=fsStayOnTop;
     end
      else
  if Stayontop.Checked = true
       then
        begin
        Stayontop.Checked:=false;
        FormStyle:= fsNormal;
        end;
end;

Why the "if Stayontop.Checked = true" after the else, what other value could it possibly have, since you already know that it is not false.
AFAIK booleans don't come as true, false or maybe 

This accomlishes the same and it reads a lot better:

Code: [Select]

procedure TForm1.StayontopClick(Sender: TObject);
begin
  if not Stayontop.Checked  then
     FormStyle:=fsStayOnTop;
  else
    FormStyle:= fsNormal;
  Stayontop.Checked:=not Stayontop.Checked;
end;

Bart

yes all I had to do was write it like this -- because an if statement always checks for true

Code: [Select]

if (StayOnTop.Checked) then
       begin
                FormStyle:=fsNormal;
                StayOnTop.Checked:=false;
       end
   else
     begin
              StayOnTop.Checked:=true;
              FormStyle:=fsStayOnTop;
     end;

the only thing that is going on in this is if true dto this and if not true do that-
where you did backwards logic
if not true to that and if true do this
instead
all I did was add something that didn't need to be there because the IF Statement checks for true already -- adding :=true was just a redundant argument for the IF Statement is all -- my bag 

another simple example by check for true first is this: in menu.checked or not check check

Code: [Select]

procedure TForm1.MIRandomClick(Sender: TObject);
begin
  if (MIRandom.Checked) then
      MiRandom.Checked:=false
  else
      MIRandom.Checked:=true;
end;     

// where this will give you the same results it just looked funny to you
procedure TForm1.MIRandomClick(Sender: TObject);
begin
  if (MIRandom.Checked = true) then
      MiRandom.Checked:=false
  else
      MIRandom.Checked:=true;
end;     



regardless of how one writes it.  it all stays the same basic yes no, on off logic