[Lazarus] Tprogressbar and positional info as ptrint.

[Martin]

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)