[RESOLVED] Create lightweight controls similar to VB.Label or VB.Image

[SearchingDataOnly]

We know that VB.Label and VB.Image are super lightweight controls that we can place tens of thousands or VB.Label and VB.Image in a Form.

But it seems impossible to place tens of thousands of UserControls in a Form (even if we set this user-control to Windowless and HasDC = False), because system resources will be exhausted. Why is this?

Note:
we can use VB.Label, VB.Image and VB.Timer to combine/create many lightweight controls without subclassing.

[DllHell]

Looks like windows has a hard limit of around 32,700 which suggests that they are using an int to address them
https://devblogs.microsoft.com/oldne...18-00/?p=25963

And each process has a limit of 10,000 but can be changed in the registry
https://docs.microsoft.com/en-us/win...fo/gdi-objects

[wqweto]

Looks like windows has a hard limit of around 32,700 which suggests that they are using an int to address them
https://devblogs.microsoft.com/oldne...18-00/?p=25963

And each process has a limit of 10,000 but can be changed in the registry
https://docs.microsoft.com/en-us/win...fo/gdi-objects

That's the point of windowless/lightweight controls -- to not create an hWnd for each one of these and to use container's hDC (with world tranformation applied) to paint to.

cheers,
</wqw>

[Schmidt]

That's the point of windowless/lightweight controls -
- to not create an hWnd for each one of these and to use container's hDC (with world tranformation applied) to paint to.

I think the problem with VB6-Windowless-Controls is, that most users are not aware:
- that despite "not using any hWnd or hDC Handle-resources" (by switching Windowless = True)
- there's by default still one GDI-Handle, which is wasted with every single instance of such an UC

And that handle is "a GDI-Pen-Handle".

To avoid that extra-pen-handle as well, one has to adjust (beside Windowless=True),
a second Property on such an UC -> DrawStyle ... which has to be switched:
- from its default 0 = Filled
- to the Pen-Hdl avoiding 5 = Transparent

@SearchingDataOnly
Not sure what you're trying to do though, which requires "tens of thousands of controls" -
such an approach is in almost all cases "wrong from the get-go" - and usually solved via:
- an UDT-based Array as the "State-Container-List"
- and a "virtual Control", which forces dynamic re-rendering of changed state
- directly from the UDT-Array via normal Drawing-calls with appropriate offsets

HTH

Olaf

[Krool]

And that handle is "a GDI-Pen-Handle".

To avoid that extra-pen-handle as well, one has to adjust (beside Windowless=True),
a second Property on such an UC -> DrawStyle ... which has to be switched:
- from its default 0 = Filled
- to the Pen-Hdl avoiding 5 = Transparent

Good info here. Thanks. Will probably apply this to VBCCR soon.

[ColinE66]

And that handle is "a GDI-Pen-Handle".

To avoid that extra-pen-handle as well, one has to adjust (beside Windowless=True),
a second Property on such an UC -> DrawStyle ... which has to be switched:
- from its default 0 = Filled
- to the Pen-Hdl avoiding 5 = Transparent

Useful to know. Just recently I was wondering where my pen-handle count was coming from, and this (partially) explains it. Does this approach apply to PictureBoxes as well?

[Thierry69]

To avoid that extra-pen-handle as well, one has to adjust (beside Windowless=True),
a second Property on such an UC -> DrawStyle ... which has to be switched:
- from its default 0 = Filled
- to the Pen-Hdl avoiding 5 = Transparent
Olaf

I learned something today....
and you are giving me work to check in my app

[Schmidt]

Useful to know. Just recently I was wondering where my pen-handle count was coming from, and this (partially) explains it. Does this approach apply to PictureBoxes as well?

Yes - with default-prop-settings, a PicBox-instance will need 1 WindowHandle and 2 GDI-Handles.

And whilst one cannot get rid of the WindowHandle obviously -
the consumption of the two GDI-Obj-handles can be reduced to Zero, by:
- setting HasDC = False
- setting DrawStyle = 5 - Transparent

Easy to test in the TaskManager (directly observing the VB6-IDE-Process there) - by:
- creating a new Picture1 picbox-Object on a Form
- setting its Index-Prop to 0 (so that it becomes the "root-instance" of a Control-Array)
- and then using the test-code below in that otherwise empty Form:

Option Explicit

Private Sub Form_Click()
  Load Picture1(Picture1.Count)
End Sub

Olaf

[ColinE66]

Easy to test

Yes, and that's exactly what I did (although I used GDIView). Works with Forms, too (unsurprisingly). No way of getting the Font handle count down, I don't suppose? Not that it troubles me, overly - just curious...

EDIT: I already have .HasDC set to false (normally do that as a matter of routine)

[Schmidt]

No way of getting the Font handle count down, I don't suppose?

Have not tested that for a long time - but shouldn't it be possible to share the same
Font-ObjectInstance on Controls which support direct FontObject-assignment like:

Set Ctl.Font = MyPredefinedStdFontObj
or
Set Ctl.Font = Me.Font (to share the Forms Font)
or (in case of UCs - not sure if that isn't the default anyways)
Set UserControl.Font = Ambient.Font

No intensive UC-usage here anymore - all these GDI-resource-considerations (including the Font-handles) -
are not existent in the RC5/6 WidgetEngine (a Widget-Class-Instance consuming only memory, nothing else).

Olaf

[ColinE66]

Have not tested that for a long time - but shouldn't it be possible to share the same
Font-ObjectInstance on Controls which support direct FontObject-assignment like:

Yeah, I wondered in the past if that was the way to tackle it but, like I said, it's not something that overly concerns me, so I've never tested it. Thanks for answering, anyway...

[wqweto]

Here is the constant for the DrawStyle

Private Sub Form_Load()
    DrawStyle = DrawStyleConstants.vbInvisible
End Sub

Btw, can be switched off at run-time (not only at design-time) both for forms and user-controls.

cheers,
</wqw>

[SearchingDataOnly]

The discussion here provides a lot of very useful information. Thank you all.

[SearchingDataOnly]

@SearchingDataOnly
Not sure what you're trying to do though, which requires "tens of thousands of controls" -
such an approach is in almost all cases "wrong from the get-go" - and usually solved via:
- an UDT-based Array as the "State-Container-List"
- and a "virtual Control", which forces dynamic re-rendering of changed state
- directly from the UDT-Array via normal Drawing-calls with appropriate offsets

HTH

Olaf

Yes, these methods of yours are better and more professional methods. I haven't used tens of thousands of VB.Labels or VB.Images in an actual project, I just did such an operation in the limit-testing.

But many complex UI can indeed be realized with VB.Label and VB.Image. The VSCode's UI seems simple, but the internal implementation is extremely complicated. However, it's much simpler to implement it with VB6. In order to avoid subclassing, I even considered using VB.Label and VB.Image to implement VSCode-like UI, including VSCode's File-Explorer and Code-Outline.