After around A decade or more now of heavily using TMS controls in my VCL app, I have hit a bit of a road block....
If A user maxes out our program.. ala, having every tab open we have available for every feature, we hit a GDI limit.
Windows only allows 10,000 GDI objects by default.
You can edit the registry to up this, if you got admin rights....
We use ALOT of TMS controls. Buttons, edits, page controllers, checkboxes, dozens of grids, ect ect.
I fixed this in testing by editing the registry and rebooting.
I ponder if there is anything else I can do? Or just bite the bullet and make our installer / updater check the registry... and edit it in admin mode.. to "fix" this...
Or there anything else in TMS that could be eating up GDI objects like crazy.
What exact components do you use and is it really necessary all these controls are simultanously active (i.e. simutanously have a window handle and do the GDI painting)?
Problem I have is the design that the company wanted... and has been in effect for over a decade. No going back now. Having a multi-tabbed system UI. Where X number of tabs can exist, depending on the customers own choices to lay things out and use actively at once.
Frames/Forms embedded into tabs... each form with its owns tabs/frames/controls/ect/ect/ect...
Around 30,000+ systems running the software.
The saving grace of this currently, is A customer has to push the program to its limits, running ALOT of tabs opened. Some features, are single use only, meaning 1 tab only for it, while others features, they can have 9 of them ( 9 tabs ) opened.
Somewhere in the double digits of tabs opened is when it starts to fall apart and can hit that 10,000 GDI limit.
Just one of those deals that over time, a multiple millions of lines of code later... hitting limits.
Doing a quick analyze project I pulled these out... That I am pretty sure are TMS related.
AdvAppStyler
AdvCalculatorDropdown
AdvCircularProgress
AdvColorPickerDropDown
AdvCombo
AdvControlDropDown
AdvCustomGridDropDown
AdvDataLabel
AdvDateTimePicker
AdvDetailDropDown
AdvDirectoryEdit
AdvDropDown
AdvDWM
AdvEdBtn
AdvEddd
AdvEdit
AdvFocusHelper
AdvGaugeCircle
AdvGaugeControl
AdvGDIP
AdvGDIPlusApi
AdvGDIPlusClasses
AdvGlassButton
AdvGlowButton
AdvGradient
AdvGraphics
AdvGraphicsHTMLEngine
AdvGraphicsStyles
AdvGraphicsSVGEngine
AdvGraphicsTypes
AdvGrid
AdvGridDropDown
AdvGroupBox
AdvHintInfo
AdvHTML
AdvImage
AdvImagePickerDropDown
AdvJSONReader
AdvJSONWriter
AdvMDD
AdvMemo
AdvMemoDropDown
AdvMenus
AdvMenuStylers
AdvMenuUtil
AdvMetroForm
AdvMoneyEdit
AdvMultiButtonEdit
AdvMultiColumnDropDown
AdvMultiInputQueryDialog
AdvmWS
AdvObj
AdvOfficeButtons
AdvOfficeHint
AdvOfficeImage
AdvOfficePager
AdvOfficePagerStylers
AdvOfficeSelectors
AdvOfficeStatusBar
AdvOfficeStatusBarStylers
AdvPageControl
AdvPanel
AdvPersistence
AdvProgressBar
AdvReplaceDialogForm
AdvRichEditor
AdvRichEditorBase
AdvRichEditorDD
AdvRichEditorIO
AdvRichEditorRTF
AdvScrollBox
AdvScrollControl
AdvShapeButton
AdvSmoothButton
AdvSmoothCalendar
AdvSmoothEddd
AdvSmoothEdit
AdvSmoothListBox
AdvSmoothListBoxDragDrop
AdvSmoothMessageDialog
AdvSmoothPanel
AdvSmoothProgressBar
AdvSmoothTabPager
AdvSmoothTheme
AdvSmoothToggleButton
AdvSmoothXPVS
AdvSpin
AdvSplitter
AdvStyleIF
AdvTBXPVS
AdvTimePickerDropDown
AdvToolBar
AdvToolBarStylers
AdvToolTip
AdvTrackBarDropDown
AdvTypes
AdvUtil
AdvUtils
AdvXPVS
Well, it is very simple. If you create >10000 TPaintBox controls that all use a GDI pen to draw, you'll run into a problem.
Now, you use apparently a variety of TMS controls and many of these do custom drawing and use GDI resources to do that.These controls will use a GDI pen, brush, font, etc.. whatever is needed to do the desired drawing. We can maybe optimize away a few percent of the GDI objects used in the drawing, but it will require a huge amount of effort (thus cost) and you will perhaps be able to create 100 controls more, after which the problem will be back.
What I figured with things.
The "Easy" fix is.. if that limit hit... edit registry, reboot... and got more time to worry. Just not sure what the downside will be besides more resources used.
2ndary fix is to limit tabs in general maybe.. but not my call on that. But that maybe fine for X years but this is an ever growing system so every day is to add more and more and more... never ends.
Probably not as easy as saying, Go to Direct2D for rendering when can, or move to more off screen buffers to draw to, to dispose of GDI when done. And any other options for GDI replacements or leaving them around floating.
Direct2D does have the "bonus" of COM/Reference counting to release?
Plus being hardware accelerated unlike GDI, speed increase. And virtually any system sold in modern times, has some kind of video acceleration. Speed would be great, as some of the GDI shading and such is on the slow side of things.
Anyways, this isn't a HUGE problem right now... we got work arounds.
But throwing it out there to let TMS know that GDI limits can be hit using all the GDI based controls.