0

I have developed a program that uses a TScrollBox component to produce a "railway layout". This route is made up of many small figures, each of which represents a single segment of track (according to the idea of railway modeling).

I noticed that for quite small numbers, the software works without problems. But carrying out various debug tests, already with 3500 binaries, it starts to behave in an anomalous way, and with 5000 pieces the program crashes indecently!

I would like to specify that this first version of the software was developed with "Delphi 5 Professional", in the "Windows XP Professional" environment. I thought the problem was the small amount of RAM (3GB maximum), which does not allow you to allocate more than a certain number of pieces, although with a rough estimate I could perhaps have allocated at least 16000 pieces.

I then tried to modify the software to adapt it to "Delphi XE2", in the "Windows 8.1 Professional X64" environment, generating 64-bit code, but the problem described above still occurs.

At this point, I wonder if the problem is to be found in a possible limitation of the TScrollBox component. Is there a maximum number of components that can be placed on the TScrollBox? If so, is there any way to overcome this problem?

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Alessandro Brolis
  • 1
  • 4
    You absolutely should not create thousands of controls (windowed or not) to be displayed at the same time. If you need to display a thousands things in a canvas, you mustn't use a thousand controls, but instead you must use a single control which you paint yourself. – Andreas Rejbrand Jun 23 '22 at 16:52
  • I agree. A `TPaintBox` with a bunch of images drawn on it likely makes more sense (and use less resources) than using a `TScrollBox` with a bunch of UI controls on it. – Remy Lebeau Jun 23 '22 at 18:35
  • If you must use a `TScrollBox` with UI controls, then at least use `TGraphicControl` descendants and not `TWinControl` descendants for the pieces. – Remy Lebeau Jun 23 '22 at 19:18
  • OK, thanks. The fact is that I could also integrate each new component into a single figure, which would then be drawn in a single canvas placed in the scrollbox, but the problem would then be to extract the single "track" from the figure, to be able to move it as desired, if necessary... – Alessandro Brolis Jun 24 '22 at 07:17
  • Anyway, yes, I insert objects deriving from TImage, and therefore also from its ancestor TGraphicControl. – Alessandro Brolis Jun 24 '22 at 07:21
  • Regarding your two comments, we understand what you have done, but it's just the wrong approach. It can't scale. You need to throw away what you have and start from scratch. – David Heffernan Jun 24 '22 at 08:47
  • Thanks David Heffernan, I appreciate your answer, but I was afraid of advice like yours. Unfortunately I do not have the time, nor the desire, nor the energy, nor the knowledge to invent and implement another solution, which moreover I cannot even conceive. How could I do the dragging of the single pieces? So, I keep my solution, limited to only 3200 binaries. – Alessandro Brolis Jun 25 '22 at 17:27

1 Answers1

0

It is not a limitation of the TScrollBox, but of the OS itself.

A basic limitation imposed by the window manager is that no process can create more than 10,000 USER or GDI objects

Since probably you're using TWinControl descendants, it is most likely you're reaching that limit.

dwrbudr
  • 607
  • 4
  • 8
  • Thank you for the clarification. In fact, although I created the components with try-except, I had a distinct feeling that there was a pointer problem, and I also thought that maybe the problem wasn't Delphi. In practice, objects were also created in large quantities, but then when I accessed them, especially the last ones in order of creation, the program crashed, as when trying to access dynamic memory with an incorrectly referenced pointer. – Alessandro Brolis Jun 25 '22 at 17:13