Recent

Author Topic: inserting var behaves differently than const  (Read 3270 times)

MartynX

  • Newbie
  • Posts: 2
inserting var behaves differently than const
« on: June 03, 2017, 08:55:28 am »
I recently installed v.1.6.2 on my Win10 Pro laptop and have not attempted any customization of the IDE Code Editor.

Typing a new procedure, if I add a local const block, after I press return immediately after const, the editor inserts a line break then two spaces:  this is fine because it's the way my Delphi has always worked.

However, if I type var[return], the editor adds a line break and then inserts a tab character, leaving the caret in column 5. (5?)  Why is there this difference between var and const and how can I change this so that I get a linebreak + 2 spaces, like const?  Nothing I've tried in the Options pop-up seems to cure this.

In Editor | General | Tab | Tab and Indent, 'Tab to spaces' is checked.

TIA, Martyn

Handoko

  • Hero Member
  • *****
  • Posts: 5131
  • My goal: build my own game engine using Lazarus
Re: inserting var behaves differently than const
« Reply #1 on: June 03, 2017, 10:09:14 am »
Hello Martynx,
Welcome to the forum.

Have you tried the current stable release 1.6.4 (February 27, 2017)? Or maybe the development version 1.8.0RC1.

On my Linux Lazarus 1.6.4 Gtk2, it works correctly.

You can get the installers here:
https://sourceforge.net/projects/lazarus/files/
« Last Edit: June 03, 2017, 10:11:37 am by Handoko »

MartynX

  • Newbie
  • Posts: 2
Re: inserting var behaves differently than const
« Reply #2 on: June 03, 2017, 10:53:02 am »
Thanks.

I uninstalled v1.6.2, deleted the Lazarus folder in my user AppData folder and installed v1.6.4.

That seems to have fixed the problem with var sections but unfortunately introduced another one which 1.6.2 did not have:

If I start the IDE, so that it pops up a new Project 1 + default form, and then immediately select File | Close All, the Project1 form closes but then the IDE menu bar at the top repaints continuously and Lazarus's CPU usage stays at 25% (this is a 2-core i5 Intel).  If I then go to File | New console application, the repainting stops and the IDE pops up the "Project Changed Save changes to project 1?" dialog, but whether it's talking about the project the IDE opened when it started or the new console one, it doesn't say.

Should I start a new thread about this menu-repainting problem?

Handoko

  • Hero Member
  • *****
  • Posts: 5131
  • My goal: build my own game engine using Lazarus
Re: inserting var behaves differently than const
« Reply #3 on: June 03, 2017, 11:03:47 am »
Have you tried to restart your computer?

What you said sounds like a serious bug. Any serious bug usually will be fix soon.

You may consider to start a new thread.

Cyrax

  • Hero Member
  • *****
  • Posts: 836
Re: inserting var behaves differently than const
« Reply #4 on: June 03, 2017, 12:33:33 pm »
Thanks.

I uninstalled v1.6.2, deleted the Lazarus folder in my user AppData folder and installed v1.6.4.

That seems to have fixed the problem with var sections but unfortunately introduced another one which 1.6.2 did not have:

If I start the IDE, so that it pops up a new Project 1 + default form, and then immediately select File | Close All, the Project1 form closes but then the IDE menu bar at the top repaints continuously and Lazarus's CPU usage stays at 25% (this is a 2-core i5 Intel).  If I then go to File | New console application, the repainting stops and the IDE pops up the "Project Changed Save changes to project 1?" dialog, but whether it's talking about the project the IDE opened when it started or the new console one, it doesn't say.

Should I start a new thread about this menu-repainting problem?

If I recall correctly, that bug was fixed in the trunk and the fix is in the release candidate of 1.8.0. Maybe you can try the release candidate to check if it works.

CCRDude

  • Hero Member
  • *****
  • Posts: 596
Re: inserting var behaves differently than const
« Reply #5 on: June 07, 2017, 07:24:20 am »
I can confirm this for Win32. Had this bug new in 1.6.4, and seen it fixed in the trunk :)

 

TinyPortal © 2005-2018