On Dec 5, 2012, at 4:01 PM, Vincent Snijders <[email protected]> wrote:
> 2012/12/5 Andrew Brunner <[email protected]>: >> . >> >> On Dec 5, 2012, at 2:52 PM, Juha Manninen <[email protected]> wrote: >> >>> On Wed, Dec 5, 2012 at 9:48 PM, Andrew Brunner <[email protected]> >>> 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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
