Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2009-09

Last-minute 0.9.28 nominations

9 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Alexander Klenin

These are not critical, but would be nice to have in 0.9.28:

1) r21841 (TAChart: Fix growing of zoomed-in extent upon each chart repainting) This fixes minor but annoying bug.

2) http://bugs.freepascal.org/view.php?id=14190 (TBarChart crashed with DivisionByZero)
This fixes a crash. The bug was probably assigned to me by mistake, but I still thing attached patch is worth applying.

3) http://bugs.freepascal.org/view.php?id=14652 (Object Inspector: Generated method name may contain invalid chars)
This is not reviewed, and the solution in attached patch is perhaps not complete,
but I am confident that the patch is nevertheless correct and fixes a real bug.

Alexander S. Klenin

Reply by email

Maxim Ganetsky
to Alexander Klenin

Alexander Klenin ?????:

Show quoted text 17 lines
These are not critical, but would be nice to have in 0.9.28: 1) r21841 (TAChart: Fix growing of zoomed-in extent upon each chart repainting) This fixes minor but annoying bug. 2) http://bugs.freepascal.org/view.php?id=14190 (TBarChart crashed with DivisionByZero) This fixes a crash. The bug was probably assigned to me by mistake, but I still thing attached patch is worth applying. 3) http://bugs.freepascal.org/view.php?id=14652 (Object Inspector: Generated method name may contain invalid chars) This is not reviewed, and the solution in attached patch is perhaps not complete, but I am confident that the patch is nevertheless correct and fixes a real bug.

One more candidate:

4) http://bugs.freepascal.org/view.php?id=12344 (Renaming a component will change the editor line number)
This issue is not major but rather annoying.

Best regards, Maxim Ganetsky mailto:

Reply by email

Martin
to Maxim Ganetsky
Maxim Ganetsky wrote 6 lines
One more candidate: 4) http://bugs.freepascal.org/view.php?id=12344 (Renaming a component will change the editor line number) This issue is not major but rather annoying.

There are pro and contra to this one:

- pro: one issue less
- pro: TextBetweenPoints will not be released, and changed to a slightly changed implementation in the next release

- contra: the fix affects everything that uses "OnCodeBufferChanged" (plus possible anything I have overlooked, even though I don't think I did) OnCodeBufferChanged is used for *any* change that is originated by codetools (except for identifier completion).
This includes the renaming, and insertions of components. Also the insertions of units into uses. For those three it is correct not to move the caret (or keep it in the text).
I don't know if there are any other changes originating through OnCodeBufferChanged, and if any of them need the caret to move (havent found any yet) => if there are, they are broken now.

If Mattias can confirm that OnCodeBufferChanged can always and safely keep the caret where it is, then maybe ok, but otherwise.... (Codetooljumps, such as jump to error location are done elsewhere and not affected)

Best Regards
Martin

Reply by email

Mattias Gaertner
to Martin
Show quoted text 29 lines
Maxim Ganetsky wrote: > One more candidate: > > 4) http://bugs.freepascal.org/view.php?id=12344 (Renaming a > component will change the editor line number) > This issue is not major but rather annoying. > There are pro and contra to this one: - pro: one issue less - pro: TextBetweenPoints will not be released, and changed to a slightly changed implementation in the next release - contra: the fix affects everything that uses "OnCodeBufferChanged" (plus possible anything I have overlooked, even though I don't think I did) OnCodeBufferChanged is used for *any* change that is originated by codetools (except for identifier completion). This includes the renaming, and insertions of components. Also the insertions of units into uses. For those three it is correct not to move the caret (or keep it in the text). I don't know if there are any other changes originating through OnCodeBufferChanged, and if any of them need the caret to move (havent found any yet) => if there are, they are broken now. If Mattias can confirm that OnCodeBufferChanged can always and safely keep the caret where it is, then maybe ok, but otherwise.... (Codetooljumps, such as jump to error location are done elsewhere and not affected)

Yes.
That means if a line is inserted and the caret is behind then the caret is moved accordingly. The caret should never move to the insert position.
Some codetools functions make suggestions for new Caret, but it is up to the calling function to apply it.

Mattias

Reply by email

Vincent Snijders
to Alexander Klenin: These are not critical, but would be nice to have in 0.9.28: 1) r21841 (TAChart: Fix…
Alexander Klenin wrote 5 lines
These are not critical, but would be nice to have in 0.9.28: 1) r21841 (TAChart: Fix growing of zoomed-in extent upon each chart repainting) This fixes minor but annoying bug.

Merged.

Show quoted text 5 lines
2) http://bugs.freepascal.org/view.php?id=14190 (TBarChart crashed with DivisionByZero) This fixes a crash. The bug was probably assigned to me by mistake, but I still thing attached patch is worth applying.

Committed by Mattias and merged.

Show quoted text 7 lines
3) http://bugs.freepascal.org/view.php?id=14652 (Object Inspector: Generated method name may contain invalid chars) This is not reviewed, and the solution in attached patch is perhaps not complete, but I am confident that the patch is nevertheless correct and fixes a real bug.

Committed by Mattias and merged.

Vincent

Reply by email

Vincent Snijders
to Mattias Gaertner: On Fri, 25 Sep 2009 23:53:16 +0100 Yes. That means if a line is inserted and the caret is…
Mattias Gaertner wrote 39 lines
On Fri, 25 Sep 2009 23:53:16 +0100 Martin wrote: > Maxim Ganetsky wrote: >> One more candidate: >> >> 4) http://bugs.freepascal.org/view.php?id=12344 (Renaming a >> component will change the editor line number) >> This issue is not major but rather annoying. >> > There are pro and contra to this one: > > - pro: one issue less > - pro: TextBetweenPoints will not be released, and changed to a > slightly changed implementation in the next release > > - contra: the fix affects everything that uses "OnCodeBufferChanged" > (plus possible anything I have overlooked, even though I don't think > I did) OnCodeBufferChanged is used for *any* change that is > originated by codetools (except for identifier completion). > This includes the renaming, and insertions of components. Also the > insertions of units into uses. For those three it is correct not to > move the caret (or keep it in the text). > I don't know if there are any other changes originating through > OnCodeBufferChanged, and if any of them need the caret to move > (havent found any yet) => if there are, they are broken now. > > If Mattias can confirm that OnCodeBufferChanged can always and safely > keep the caret where it is, then maybe ok, but otherwise.... > (Codetooljumps, such as jump to error location are done elsewhere and > not affected) Yes. That means if a line is inserted and the caret is behind then the caret is moved accordingly. The caret should never move to the insert position. Some codetools functions make suggestions for new Caret, but it is up to the calling function to apply it.

So, I merged it.

Vincent

Reply by email

Maxim Ganetsky
to Vincent Snijders: So, I merged it. Vincent

Vincent Snijders ?????:

Show quoted text 42 lines
Mattias Gaertner schreef: > On Fri, 25 Sep 2009 23:53:16 +0100 > Martin wrote: > >> Maxim Ganetsky wrote: >>> One more candidate: >>> >>> 4) http://bugs.freepascal.org/view.php?id=12344 (Renaming a >>> component will change the editor line number) >>> This issue is not major but rather annoying. >>> >> There are pro and contra to this one: >> >> - pro: one issue less >> - pro: TextBetweenPoints will not be released, and changed to a >> slightly changed implementation in the next release >> >> - contra: the fix affects everything that uses "OnCodeBufferChanged" >> (plus possible anything I have overlooked, even though I don't think >> I did) OnCodeBufferChanged is used for *any* change that is >> originated by codetools (except for identifier completion). >> This includes the renaming, and insertions of components. Also the >> insertions of units into uses. For those three it is correct not to >> move the caret (or keep it in the text). >> I don't know if there are any other changes originating through >> OnCodeBufferChanged, and if any of them need the caret to move >> (havent found any yet) => if there are, they are broken now. >> >> If Mattias can confirm that OnCodeBufferChanged can always and safely >> keep the caret where it is, then maybe ok, but otherwise.... >> (Codetooljumps, such as jump to error location are done elsewhere and >> not affected) > > Yes. That means if a line is inserted and the caret is behind then the > caret > is moved accordingly. The caret should never move to the insert > position. > Some codetools functions make suggestions for new Caret, but it is up to > the calling function to apply it. > So, I merged it.

Thanks. Hope it won't break things.

Best regards, Maxim Ganetsky mailto:

Reply by email