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.

Thanks.

Andrew Brunner,

Aurawin LLC
512.574.6298
http://aurawin.com/

Aurawin is great new way to store and share your pictures, videos, and more, featuring our innovative Pure Cloud social computing platform.

Andrew Brunner 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.

Juha

.

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.

to change the

2012/12/5 Andrew Brunner :

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?

Vincent

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

Andrew Brunner wrote

The design time vales are all zeros anyways.

ProgressBar.Position can be set also at design time.

Juha

Does anybody have an screen or printer, with so many pixels? ;-) [That's why Integer is way enough for a progress bar]

DoDi

Point 1. The IDE input could reject values beyond 2g. It probably does that already.

Point 2. caveat emptor.

Point 2 is implement and wait and see who's exposes any flaws.

I assert that this change must be adopted. I want to be able to use the native progress bar instead of scaling downwards. It's so much less than ideal. Plus the fix is not hard. It's just decs.

There are absolutely no forms out there with values of position beyond 2g today. Globally.

multi-monitors spread horizontally??

waldo kitty wrote

multi-monitors spread horizontally??

C'mon...
Please take a calculator and check how much is 2^31.

Juha

You are serious ?!? There is no correlation between the actual number of pixels on a screen and the drawing of the progress bar by the host operating system.

Obviously I have graphical data that needs progress representation beyond the 2g limit... But we need to be serious here. The progressbar is painted by the os. There is scaling that happens by the ui component. Hence the need for expansion in the user realm.

In the time it took to convince you there is a problem the solution could have been adopted.

Please this isn't about pixels, it's about efficient scaling onto 64bit systems. Hence a flaw.

How wide would that row be, at say 120 dpi? <BG>

DoDi

How that? A control on screen is painted pixel-by-pixel, you cannot have fractions of pixels on the screen.

Obviously I have graphical data that needs progress representation beyond the 2g limit...

Somebody else may have graphics data in Extended form, spanning much more than Integer or Int64, or only a fraction of 1. Should a simple component take care of all imagineable number types?

But we need to be serious here. The progressbar is painted by the os. There is scaling that happens by the ui component. Hence the need for expansion in the user realm.

When the progress bar is scaled to percents, then every user should be able to convert his numbers into a percentage.

DoDi

Hans-Peter Diettrich wrote

A control on screen is painted pixel-by-pixel, you cannot have fractions of pixels on the screen.

Actually you can, but it is more of an optical illusion. :) eg: floating point calculation for anti-aliased drawing. With AggPas I can draw a 0.4 pixel wide line.

Regards,
- Graeme -

Andrew Brunner wrote

In the time it took to convince you there is a problem the solution could have been adopted. Please this isn't about pixels, it's about efficient scaling onto 64bit systems. Hence a flaw.

I think the streaming issues will turn down your suggestion. I remember there has been some similar issues, I don't remember which. Still, the ProgressBar position must often be scaled. This 64-bit integer is not a special case.
For example I can have a value range from 0.0 to 1.0, yet I can show it in a ProgressBar by multiplying by 100 and converting to integer.

Say you have a range from 0 to 1,000,000,000,000.
Just divide it by 1000 and you are in Integer range again. Something like :

  ProgressBar.Max := 1000000000;

...

  ProgressBar.Position := MyInt64Value div 1000;

Juha

Andrew Brunner wrote

I assert that use of anything but ptrint in the factory with respect to tprogressbar is a flaw. And it's a quick fix.

It is not a flaw, you need to scale your number to fit the provided size.

Hans-Peter Diettrich wrote

How wide would that row be, at say 120 dpi? <BG>

This is not relevant to the I stated before, the
progressbar component of the host operating system scales the Min/Max/Position values and converts it to the client area of the aggregate value.

So basically, with the Progressbar on 64bit systems the current progress bar won't accept values except longint. This is a flaw. This must be a 64bit position. Otherwise this Lazarus component is relegated to the least common denominator of 32bit oses.

If I understand correctly what you're saying and *if* the OS requires a 64 bit number, then the Lazarus LCL code must be changed to scale the 32 bit integers given to it by the code/LFM streamed properties to 64 bit integers.

This will maintain compatibility between projects. You may not care about having your projects compile on multiple platforms without (too many) code changes, but I and others do.

I just got into this thread, but I have been using Delphi since Version 1 (and Turbo Pascal back to Version 1 before that). Imo the Min, Max and Pos parameters should all be set to the largest integer data type of the underlying OS. If this is done, the scaling issue should be taken care of automatically. There may be a latent flaw due to streaming of these parameters, however.

Don Ziesig

Donald Ziesig wrote

I just got into this thread, but I have been using Delphi since Version 1 (and Turbo Pascal back to Version 1 before that). Imo the Min, Max and Pos parameters should all be set to the largest integer data type of the underlying OS. If this is done, the scaling issue should be taken care of automatically. There may be a latent flaw due to streaming of these parameters, however. Don Ziesig

I think the streaming issue is separate. I honestly, streaming is a non issue. A developer would have to key in a 2g+ lnteger value. And the ide editor would have to store said value. Just make leave that be for now. I just don't see that a a reality for progressbar.

But typically a progress bar is used in conjunction with streams. Therefore it should handle the same size as objects like that. On 64bit oses position/size = 64bits wide. It may seem large but it is not when it represents a video stream or archive file. On 32bit systems it is 32bits wide.

Thanks.

Perhaps you could post a bug report with a sample project that demonstrates your problem and a patch.

I suspect that could save some time.

Thanks,
Reinier

Andrew Brunner wrote

But typically a progress bar is used in conjunction with streams. Therefore it should handle the same size as objects like that.

Why?
I typically set Max to 100 and calc percentage, et voila...

Bart

Andrew Brunner 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.

Ok, I have a patch for the LCL but before we get further I think we need more discussion on ptrInt vs actual use of Int64 on 32bit systems.

Great news! The widget set on GTK2 automatically scales the min/max value and just passes a fraction of the filler and GTK2 does the rest.

So the question becomes, what is the best variable to use for allowance as valid Min/Max/Position? I think at this point it is safest to use PtrInt but one could make the case for Int64 if Int64 is widely used in TStreams - even on 32bit oses.

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

Any feedback or ideas are welcome.

IMHO ptrint is the wrong choice. it invites to write code that can not be ported. and leaves unreadable LFM.

If streams use int64, and this is for the purpose of copy those values, then it must be int64 too (or qword, if it can't be negative ,and should have the full range).

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)

Ok, After looking at MSDN and the widget source code under windows, I assert there is presently an un-exposed flaw.

There is data precision truncation via Line 671 of unit ./lcl/interfaces/win32/win32wscomctrls.pp. Where NewPosition is Integer and under windows Integer is LongInt not Word.

According to Microsoft's Developer Network Page

PBM_SETPOS, PBM_SETRANGE only support signed integers up to 65,535.

So, that means that there is a clear problem here. And a general case solution is easy to form.

The best possible route would be to allow the largest Integer type and scale inside the lcl.

Next question would be, can the IDE property streamer handle Int64 values? If not, what's involved with expanding the property reader.

Scaling inside the LCL would need an algorithm that accounts for the step (Integer) too.

Andrew Brunner wrote

According to Microsoft's Developer Network Page PBM_SETPOS, PBM_SETRANGE only support signed integers up to 65,535.

See note at Embarcadero's wiki about this:
http://docwiki.embarcadero.com/Libraries/XE3/en/Vcl.ComCtrls.TProgressBar.Position

Delphi uses Integer for Pos, Min, Max.

Bart

So does Delphi read Lazarus projects?

If it does, one could make the argument about limiting scale to Word. Not to say I would agree that notion.

I think widget scaling is going to be worth the effort.