[Lazarus] Tprogressbar and positional info as ptrint.

[Andrew Brunner]

On Dec 5, 2012, at 4:01 PM, Vincent Snijders <vincent.snijders at gmail.com> wrote:

> 2012/12/5 Andrew Brunner <atbrunner at aurawin.com>:
>> .
>> 
>> On Dec 5, 2012, at 2:52 PM, Juha Manninen <juha.manninen62 at gmail.com> wrote:
>> 
>>> On Wed, Dec 5, 2012 at 9:48 PM, Andrew Brunner <atbrunner at aurawin.com> wrote:
>>>> I'm getting overflow exceptions on values greater than integer.  Can someone revise all values from integer to ptrint so on 64 bit systems it will be valid.
>>> 
>>> You can scale the value in your code before using it for ProgressBar's Position.
>>> Integer has 2^31 positive values which should be enough for all the
>>> positions shown in a graphical component.
>> 
>> It is far more important to realize that on 64bit systems the GUI components can scale.  I have already tested ptrint on Ubuntu x64. It only took a few minor tweaks.
>> 
>> I can provide diff if interested.  But changes to windows callback for comctrls will be needed as well.
>> 
>> I assert that use of anything but ptrint in the factory with respect to tprogressbar is a flaw.  And it's a quick fix.
> 
> And won't that break streaming a form to lfm or lrs? Especially when
> created on a 64 bits system and using on a 32 bits system?
> 

The design time vales are all zeros anyways.  So in my case position is that of a buffer or file stream.  Zero. At runtime the value is set at what the system can do. 

So I will not or have not experienced overflow when dealing with my projects post ptrint revision