Recent

Author Topic: DBGrid - Impact of merging Options2 and OptionsExtra into Options  (Read 325 times)

valdir.marcos

  • Hero Member
  • *****
  • Posts: 822
DBGrid - Impact of merging Options2 and OptionsExtra into Options
« on: September 20, 2019, 02:39:27 pm »
About DBGrid, what would be the impact of merging Options2 and OptionsExtra into Options?

lucamar

  • Hero Member
  • *****
  • Posts: 2020
Re: DBGrid - Impact of merging Options2 and OptionsExtra into Options
« Reply #1 on: September 20, 2019, 03:07:28 pm »
Well, for one thing any code depending on the enumerations being what they are, like e.g. not well thought out validity tests, would stop working right.

Not really a show-stopper, but annoying if you have much code like that.
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.2/2.0.4  - FPC 3.0.4 on:
(K|L)Ubuntu 12..16, Windows XP SP3, various DOSes.

valdir.marcos

  • Hero Member
  • *****
  • Posts: 822
Re: DBGrid - Impact of merging Options2 and OptionsExtra into Options
« Reply #2 on: September 20, 2019, 05:23:36 pm »
Well, for one thing any code depending on the enumerations being what they are, like e.g. not well thought out validity tests, would stop working right.
Not really a show-stopper, but annoying if you have much code like that.
I have no code using that, but I consider a better design if DBGrid would have only one "options" instead of three.

Do you think it's worthwhile to open a feature request for that?

lucamar

  • Hero Member
  • *****
  • Posts: 2020
Re: DBGrid - Impact of merging Options2 and OptionsExtra into Options
« Reply #3 on: September 20, 2019, 05:46:23 pm »
I have no code using that, but I consider a better design if DBGrid would have only one "options" instead of three.

It's not just about your code, but about all the code ever writen using it. I guess that's why they added new properties instead of reusing the one already there: backwards (and Delphi?) compatibility. I'd also prefer just one "Options" property but I understand (more or less) why that might not be possible.

Quote
Do you think it's worthwhile to open a feature request for that?

Yes, if you think it's important enough. In the worst case it won't be implemented, leaving everything as it is now, so you loose nothing; on the other hand, it might be implemented and you (and everyone) win that.

Although I'm rather pessimistic about it: there're probably lots of code out there depending on the properties being as they are: a change would mean that, for example, code that sets the options at run-time would have to be modified, etc.
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.2/2.0.4  - FPC 3.0.4 on:
(K|L)Ubuntu 12..16, Windows XP SP3, various DOSes.

wp

  • Hero Member
  • *****
  • Posts: 6232
Re: DBGrid - Impact of merging Options2 and OptionsExtra into Options
« Reply #4 on: September 20, 2019, 05:59:03 pm »
a change would mean that, for example, code that sets the options at run-time would have to be modified, etc.
That's the least problem because the compiler will tell you what has to be changed. Setting Options at designtime (in the object inspector), however, is much worse because the form will not longer be accepted by the IDE, you not be able to open it and must correct its lfm file outside the IDE.
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10

lucamar

  • Hero Member
  • *****
  • Posts: 2020
Re: DBGrid - Impact of merging Options2 and OptionsExtra into Options
« Reply #5 on: September 20, 2019, 07:14:39 pm »
[...] the form will not longer be accepted by the IDE, you not be able to open it and must correct its lfm file outside the IDE.

You're right; I didn't think of that. One might expect the IDE to be able to open/convert old forms but that's not guaranteed at all, and even then backwards compatibillity would be a problem, as happens now with, for example, DoubleBuffered
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.2/2.0.4  - FPC 3.0.4 on:
(K|L)Ubuntu 12..16, Windows XP SP3, various DOSes.

valdir.marcos

  • Hero Member
  • *****
  • Posts: 822
Re: DBGrid - Impact of merging Options2 and OptionsExtra into Options
« Reply #6 on: September 21, 2019, 03:34:49 pm »
I have no code using that, but I consider a better design if DBGrid would have only one "options" instead of three.
It's not just about your code, but about all the code ever writen using it. I guess that's why they added new properties instead of reusing the one already there: backwards (and Delphi?) compatibility. I'd also prefer just one "Options" property but I understand (more or less) why that might not be possible.

Quote
Do you think it's worthwhile to open a feature request for that?
Yes, if you think it's important enough. In the worst case it won't be implemented, leaving everything as it is now, so you loose nothing; on the other hand, it might be implemented and you (and everyone) win that.

Although I'm rather pessimistic about it: there're probably lots of code out there depending on the properties being as they are: a change would mean that, for example, code that sets the options at run-time would have to be modified, etc.

a change would mean that, for example, code that sets the options at run-time would have to be modified, etc.
That's the least problem because the compiler will tell you what has to be changed. Setting Options at designtime (in the object inspector), however, is much worse because the form will not longer be accepted by the IDE, you not be able to open it and must correct its lfm file outside the IDE.

[...] the form will not longer be accepted by the IDE, you not be able to open it and must correct its lfm file outside the IDE.
You're right; I didn't think of that. One might expect the IDE to be able to open/convert old forms but that's not guaranteed at all, and even then backwards compatibility would be a problem, as happens now with, for example, DoubleBuffered
I understand the concerns of both of you.
I think it's a minor setback in face of a better design.
Using stable+fixes+trunk, I face that experience of properties missing or changed all the time.

Sometimes, the results worth the effort.
https://wiki.freepascal.org/Lazarus_2.2.0_release_notes#IDE_incompatibilities
https://wiki.freepascal.org/Lazarus_2.0.0_release_notes#LCL_incompatibilities
https://wiki.freepascal.org/FPC_New_Features_Trunk

I am studying "/lazarus/lcl/dbgrids.pas" to provide a patch and file a feature request.
Thanks for your time and help to discuss the subject.