The Lazarus team is glad to announce the release of Lazarus 1.6.

This release was built with FPC 3.0.0.
The previous release Lazarus 1.4.4 was built with FPC 2.6.4.

Here is the list of changes for Lazarus and Free Pascal: http://wiki.lazarus.freepascal.org/Lazarus_1.6.0_release_notes http://wiki.lazarus.freepascal.org/User_Changes_3.0.0

The release is available for download on SourceForge: http://sourceforge.net/projects/lazarus/files/

Choose your CPU, OS, distro and then the "Lazarus 1.6" directory.

Checksums for the SourceForge files:
http://www.lazarus-ide.org/index.php?page=checksums#1_6

Minimum requirements:

Windows:
98, 2000, XP, Vista, 7, 8/8.1, 10, 32 or 64 bit.
Win98 and WinNT IDE needs FPC 2.6.4 and building with flag -dWIN9XPLATFORM.

FreeBSD/Linux:
gtk 2.8 or qt4.5, 32 or 64bit.

Mac OS X:
10.5 to 10.11, LCL only 32bit, non LCL apps can be 64bit.

The svn tag is
http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_6

Here is the list of fixes for Lazarus 1.6:
http://wiki.freepascal.org/Lazarus_1.6_fixes_branch

For people who are blocked by SF, the Lazarus releases from SourceForge are mirrored at:
ftp://freepascal.dfmk.hu/pub/lazarus/releases/
and later at (after some time for synchronization) http://michael-ep3.physik.uni-halle.de/Lazarus/releases/ and
http://mirrors.iwi.me/lazarus/

Mattias

To avoid confusion, would the admin of the sourceforge project update the following line appearing on top of the project page "Looking for the latest version? *Download
lazarus-1.4.4-fpc-2.6.4-win32.exe (113.1 MB)
<https://sourceforge.net/projects/lazarus/files/latest/download?source=files>" *It still refers to 1.4.4 instead of the new 1.6.0

Dennis*

*

I changed the setting for Windows yesterday, but it still does not work. It shows the correct default when selecting the 1.6 file. I now switched to another file and back, now it works. Strange.

Mattias

I have been pondering with that idea ever since the implementation of strings for case.
This morning I remembered again why it may be useful. Consider this code vs the alternative I suggest.
Plz. do not value the code, it is just copied from the forum and frankly not the point but an illustration:

1.

    procedure TFrame00.ComboBoxChanged(Sender: TObject);

2.

    Var

3.

       x : TComboBox;

4.

    begin

5.

    If (Sender Is TComboBox) Then

6.

    begin

7.

       x := (Sender As TComboBox);

8.
9.

    case x.Name of

10.

    'ComboBox01':if x.ItemIndex = -1 then x.ItemIndex := PrjIndex else

11.

    begin

12.

    end;

13.

    'ComboBox02':if x.ItemIndex = -1 then x.ItemIndex := HubIndex else

14.

    begin

15.

    end;

16.

    'ComboBox03':if x.ItemIndex = -1 then x.ItemIndex := RimIndex else

17.

    begin

18.

    end;

19.

    'ComboBox04':if x.ItemIndex = -1 then x.ItemIndex := SpkIndex else

20.

    begin

21.

    end;

22.

    end;

23.

    End;

24.

    end;

25.
26.

Now how much nicer it would be if you could write someting along the lines of:

 1.
    procedure TFrame00.ComboBoxChanged(Sender: TObject);
 2.
    begin
 3.
    If Sender Is TComboBox Then
 4.
    case TCombobox(sender) of
 5.
         Combobox1:;
 6.
         ComboBox2:;
 7.
         ComboBox3:;
 8.
    end;
 9.
    end;

In other words, use the instance pointer as an ordinal value. It looks a lot more logical but as it stands it is of course invalid syntax. Is it possible to implement?
If so, has it any value? To me at least it looks feasable and less like syntactic sugar than some features.

Hi,
21.02.2016 13:37,
[...]

And what's wrong with just this:

if Sender = Combobox1 then
...
else if Sender = Combobox2 then
...
else

Regards,
Nikolai

No much sense for me. Just use dictionary, for example TDictionary from Generics.Collections (reminder for Sven ;P).

Hi Nikolai,

Readability. A case is often much more readable, structured. Extended else use tends to become less readable over multiple choices than a case.
I often wondered why my suggestion is not already possible.

Regards,

Thaddy

Nikolai Zhubr wrote

Hi, 21.02.2016 13:37,

That's exactly what I use (a dictionary) to circumvent this language limitation and use a case expressively.
I feel though, it is a limitation that could be solved.

It is also about notational convenience. In that sense it belongs to the language level and not in the library domain.
And it is somewhat obvious to have. (I know I am not the only one who at some point in time was surprised you couldn't easily use instance pointers as ordinals)

"" wrote

I have been pondering with that idea ever since the implementation of

strings for case.
[skip]

In other words, use the instance pointer as an ordinal value. It looks a lot more logical but as it stands it is of course invalid

syntax.

Is it possible to implement? If so, has it any value? To me at least it looks feasable and less like

syntactic sugar than some features.

Would it be possible to implement? Yes
Would that mean that instance pointers would be handled as ordinal values? No, because "case" is merely a parser construct. In principle the condition and the case labels could be anything. String constants aren't ordinal values after all either.
It might look logical but it would be a complete paradigm shift for case-statements, because the case labels are supposed to be constant values (ordinal, including enums and string constants) while variables (local, global, fields) are not constants however.

Regards,
Sven

The reason this does not work is that Combobox1, Combobox2, ... are not constants. Replacing the strings in your first example with Combobox1.Name, Combobox2.Name will also fail to compile.

Take this example:
=== example begin ===
Program Example;

{$mode ObjFPC}
Var
    C, D: TObject;
Begin
    Case ptruint(C) of
        0: ;
        1: ;
    End;
    Case ptruint(C) of
        0: ;
        1: ;
        ptruint(D): ;
    End;
End.
=== example end ===

The first case will compile, the second will not, failing with a "Constant Expression expected". So, if you would somehow know the instance pointers at compile time, you might get away with it ;-)

I knew that... It is a suggestion to extend the syntax. Sven explained how it could work.

Ewald wrote

The first case will compile, the second will not, failing with a "Constant Expression expected". So, if you would somehow know the instance pointers at compile time, you might get away with it ;-)

And there lies the problem.

Case labels do not allow duplicates. But if they are variables, then this can not be checked at compile time.
So this must either throw an exception, or add/change the evaluation of the "case" to have a precedence between the "labels", and decide if only the first or all matches are executed.