Exception in TControl.DoSetBounds

[simone]

While developing an application that performs scientific calculations and displays the results graphically, I noticed that TControl.DoSetBounds raises an exception if Width or Height are greater than 100.000, as can be seen from the following code.

Code: Pascal  [Select][+][-]

1. procedure TControl.DoSetBounds(ALeft, ATop, AWidth, AHeight: Integer);
2.  
3.   procedure BoundsOutOfBounds;
4.   begin
5.     DebugLn('TControl.DoSetBounds ',Name,':',ClassName,
6.       ' Old=',dbgs(Left,Top,Width,Height),
7.       ' New=',dbgs(aLeft,aTop,aWidth,aHeight),
8.       '');
9.     RaiseGDBException('TControl.DoSetBounds '+Name+':'+ClassName+' Invalid bounds');
10.   end;
11.  
12. begin
13.   if (AWidth>100000) or (AHeight>100000) then
14.     BoundsOutOfBounds;
15.   {$IFDEF CHECK_POSITION}
16.   if CheckPosition(Self) then
17.     DebugLn(['TControl.DoSetBounds ',DbgSName(Self),
18.       ' Old=',Left,',',Top,',',Width,'x',Height,
19.       ' New=',aLeft,',',aTop,',',aWidth,'x',aHeight]);
20.   {$ENDIF}
21.   FLeft := ALeft;
22.   FTop := ATop;
23.   FWidth := AWidth;
24.   FHeight := AHeight;
25.   if Parent <> nil then Parent.InvalidatePreferredSize;
26. end;

Regarding this, I have two questions:

- While the requirement that an object cannot exceed the above value is certainly reasonable, is there a specific reason behind this atypical limit?

- Is it possible, in future versions of LCL, to avoid hardcoding this value and instead make it a public constant (for example, in the interface section), thus allowing applications using LCL to implement check mechanisms that prevent this limit from being exceeded and thus throwing the exception during program execution?

Thanks in advance.

[Thaddy]

Do you have monitors for 100000X100000 pixel resolution?
Are you using dosetbounds correct?
It is not a function you would normally use yourself as per the documentation.
https://dsiders.gitlab.io/lazdocsnext/lcl/controls/tcontrol.dosetbounds.html

It is also strictly limited to display rendering resolution, nothing else.

[jamie]

A Control is meant to be a displayable object, why would you think that you can exceed that amount of possible screen real estate?

I believe if you stay within the scrolling range (32768) you should be ok.

I think you should replan your option.

Jamie

[simone]

Do you have monitors for 100000X100000 pixel resolution?
Are you using dosetbounds correct?
It is not a function you would normally use yourself as per the documentation.
https://dsiders.gitlab.io/lazdocsnext/lcl/controls/tcontrol.dosetbounds.html

It is also strictly limited to display rendering resolution, nothing else.

If screen resolution is the reason for this limit, it should be lower.

I don't use that method directly, but I've read the code to understand the exception thrown.

Your sarcastic tone is, as usual, out of place.

[simone]

For the sake of completeness, I've found that Delphi/VCL behaves differently. No exception is raised when an arbitrary limit (100.000 in Lazaurs/LCL) is exceeded, but an obvious range check error is thrown if the value is greater than 2³² - 1 (the maximum allowed value for the Width and Height properties, which are integers).

Perhaps Delphi programmers have screens built with extraterrestrial technologies.

[Martin_fr]

Well, for starters the WM_SIZE msg of the window API uses words (~32000) for values. Some other window API calls use integer. And Windows itself uses some undocumented constant with special meaning (like minimized) in the 32K range.
However, I don't think that is the reason.

I do wonder so, with multimonitor setups you can reach higher pixel values (and I don't know if you can put gaps between monitors)....


In any case, I think I recall the limit used to be smaller.
I don't know for sure why it was added. It would be possible to do a git blame for that.

By if I had to take a guess, its to stop some undetected circular size dependencies (wrong anchors, that lead to recursive growth).

[440bx]

A "trick" I've seen in code is to set either (or both) X and Y coordinates to values that are almost guaranteed to be outside the range that can be displayed.   This is usually done as a way to hide the windowed object.

Sort of "interestingly" the 100,000 value is getting close to be borderline because there are 8K monitors (outrageously priced but they exist) and roughly 14 of those in a horizontal arrangement could reach coordinates close and maybe even including 100,000+ and, that's here on Earth, rumors are that in Ganimede they go even further than that.  The video card(s) required to drive such a setup I believe are currently available only out of this world.

[simone]

Obviously, I don't expect to create an object larger than that size!

This situation occurred in my application due to an error in a complex calculation, which I detect after my initial post.

While debugging, I noticed this limit in the DoSetBounds code and became curious. I didn't dispute the fact that there was a limit, but I wondered why it had that value.

[ASIOwner]

I can understand why these limits are in place, but there's a very valid reason these limits are too small.
I'm currently upgrading Winsoft PDFium to work with Lazarus 4.6 and ran afoul of this limitation. When the TPdfViewer component loads a document, it does so by creating one long page as a TCustomControl. When you load a very large document this component can create a page over 500,000 in height; this is for ease of moving from page to page. This is no problem with Delphi since it doesn't have this check, but it causes a fatal error when running it on Lazarus and I've lost several days pinpointing this issue.
For now I've just commented the two lines out and recompiled Lazarus to ignore the checks and allow it to run, but this isn't a perfect fix. Since the DoSetBounds procedure is Virtual, Erik at Winsoft will look into a fix they can implement in their components.
This is an all too common side effect of trying to be protective without knowledge of the potential problems it can cause. I've done similar things while trying to protect code from potential stupid actions; and then I had to make less protective changes because more flexibility was required.