On 11/12/2012 17:55, Andrew Brunner wrote:
So the question becomes... Is the use of int64 actually ubiquitous on
a 32bit system? If so, it may stand to reason that the values of
Progress bar be expanded to Int64 even on 32bit systems.
http://bugs.freepascal.org/view.php?id=23471
I am *not* generally opposing the change.
Ins any case, the range must be a type, that has the same size on all
Platforms (Int64 is ok / ptrint is not).
Using a variable size type will create problems for any project that is
cross platform and developed by a team (it be a question of time until
some team member on a 64 bit system uses a value, that does not compile
on 32 bit).
The reason given in the issue IMHO is in this case not valid. And
without reason, it is harder to make the right decision.
"It (int64) must be supported, because the OS could accept it" is
no reason in itself.
In this particular case there is no functionality gained.
Most of the time if an OS accepts some value (or a greater range), this
will also add functionality. This is not the case, when the limit (set
by the screen) is below the sub-range already used.
The only reason I see, is that user code can use TStream values without
having to scale them in the user code. (scaling still happens, either in
the LCL, or OS, or both)
So the question is what is more important.
- For the few cases, were it is used with tstream the user code will be
simpler.
- For all other cases user code stays as it is, but there is more code
to maintain in many widgetset's code (adding maintenance).
My guess is that Delphi may have that because of those visual-binding
stuff. So if one wanted to link TProgressbar.VAlue to
TSomeFileOrStreamHandlingComponent.Position, and want to do that in the
form designer (which from the videos embarcadero publishes, apparently
can be done), then for embarcadero it is much easier to create the code
for the visual bindings.
If the requester wants to contribute something of that kind: cool.
Otherwise lets see if there are other (valid / based on functionality
affected) reasons. Or if it is only simplifying the occasional code
using TStream (which still can be reason enough)
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
