TVirtualStringTree in TScrollBox at pos greater than 32767

Hi

I have a ScrollBox and I populate it with lot's of TLables and TVirtualStringTrees... I create  a long report with heading (TLabel) and data grid (TVirtualStringTree)  and it works fine. By default I have 10+ reports and show the ones that have any data. So, sometimes I show all of them, sometimes just 1 or 2 (each has label/name of report and virtual tree for data).
So, they are all already in the scroll box, I just hide/show the ones I need.

The problem is that in very rare cases the first few reports have a couple of thousand lines/nodes, so the scroll box can quickly get to 50.000 in height. The problem is, that virtual trees don't go after 32767 point! Meaning all treeviews that should be located on positions 32767+ get stuck on that position, but all the labels get positioned to a proper pos in scroll box, 50.000, 100.000+.

I searched around and found that TScrollBox used to have a problem with not extending beyond 32767, due to some Windows limitation. Either this was true in earlier Delphi version, I use D2006, because TLabel has no problem being position beyond 32767 position mark.

So, is it a limitation of ScrollBox that affects TVirtualStringTree or is it TVirtualStringTree limitation? Any suggestions how to overcome it?

You can test with simple, TScrollBox and put TLabel and TVirtualStringTree inside. Then set:
Label1.Top := 35.000;
VirtualStringTree1 .Top := 35.020;

Open in new window

and it won't work, tree view will be shown higher than label.

As said, this happens in rare occasions, but it does, so I don't want to change the whole logic of how the scroll box works (I found some suggestions to trick the user with how the visible area of scroll box is presented to show the controls correctly as though they appear below 32767 mark, bu they are actually juts near the top - this is not what I want to do).

Thank you
Delphi_developerAsked:
Who is Participating?
 
Delphi_developerConnect With a Mentor Author Commented:
OK, thank you, I appreciate your effort. I will look into different way to go.
0
 
MerijnBSr. Software EngineerCommented:
If it's it just TVirtualTree which won't go lower then 32767, as a workaround put a TPanel for each TVirtualTree in the TScrollBox, and put the virtual trees in the panels?
0
 
Delphi_developerAuthor Commented:
Thank you for suggestion,  but it doesn't seem to work, it's Top is also set to 32767 and not beyond.

Any other suggestions?
0
Take Control of Web Hosting For Your Clients

As a web developer or IT admin, successfully managing multiple client accounts can be challenging. In this webinar we will look at the tools provided by Media Temple and Plesk to make managing your clients’ hosting easier.

 
MerijnBSr. Software EngineerCommented:
Are there any components which can be set further then 32767?
0
 
Delphi_developerAuthor Commented:
Yes, TLabel works OK and can be positioned beyond 100.000 pos, it seems like the only one. TEdit and TButton don't go beyond that point, either.
0
 
MerijnBSr. Software EngineerCommented:
TLabel does not have a handle, while TEdit and TButton do (TLabel inherits from TGraphicControl and not TWinControl). All nice, but this doesn't help you with your problem.

It seems this is a limitation in SetWindowPos() the Windows API Delphi uses to position the controls. So I'm afraid that even if someone can think of a work around, it will probably mean that it will mean you can't use Delphi in the 'normal' way, will bring some hassle.

Let's see if we can tackle this the other way round, can you split the reports up some way, so you won't get past 32767 pixels?
0
 
Delphi_developerAuthor Commented:
No, can't split them. It happens as soon as I have 3 reports with 1000 records. It's rare, but it does happen. I only noticed this when testing for limits, memory consumption... was testing much larger situations, where it could get to 300.000 pixels... and noticed this 32767 limit.

It's just before release date, so I'm looking for a fix, that does not require 2-4 weeks dev time (dev, test, sign off, beta...). I was looking for a replacement component, but so far nothing, there are wrappers around TScrollBox, meaning they have the same limitation.
0
 
MerijnBConnect With a Mentor Sr. Software EngineerCommented:
Since the problem isn't in Delphi but in the Windows API, you will probably not be able to work around this from Delphi perspective I'm afraid.

Maybe you can cheat by hiding parts of the report which are currently not in view or something?
0
 
MerijnBSr. Software EngineerCommented:
Maybe you can give this a shot. Put panels in your scrollbox, but don't position them manually, just set all their align's to alClient. What I see here is that there tops are still stuck to 32767, but visually it seems ok.

Place your controls within the panels, as long as the panels themselves don't get larger then 32767 you might have something working.
0
 
MerijnBSr. Software EngineerCommented:
Previous comment has typo, align = alTop, not alClient!

Or you could even try not using panels at all, don't set the tops of the controls, just use align = alTop only.
0
 
Delphi_developerAuthor Commented:
I tried alTop already, at the beginning, but hiding/showing controls and letting Delphi handle and align properly, was never working good. The order was not always correct and sometimes the controls just didn't align alTop, before repainting, resizing the ScollBox - just didn't work good. Manually aligning them works every time.
But even with alTop, when the length of controls pass 32767 mark, it doesn't work - they get positioned on the same mark.

Thanks, but I'm not using panels, anyway.
0
 
Delphi_developerAuthor Commented:
No solution provided.
0
All Courses

From novice to tech pro — start learning today.