TimoSoft-Software.de

The control is based on the "Static" native window class. I thought there would be a window style (SS_* constant) which makes static controls resize themselves automatically dependent on the text. But there isn't. So looks like I'll really have to measure the text and do the resizing myself.
Another problem that still exists: keyboard cues (underlining of mnemonics) do not work as expected. On Windows XP and newer, keyboard cues should be invisible by default and become visible if the ALT key is pressed. This works for my ButtonControls, but for some reason not for the label.

BTW, I'm afraid the label control has the same redrawing speed issues as the button controls.

Well then good luck! I believe in you!

AutoSize is done, see the attachment. The bug with the frame is still there. Maybe I'll change the label control to not be based on the STATIC window class anymore and draw the text manually instead. This might help.
Oh and keyboard cues actually work, I made a mistake when testing it.

Hello Timo!
Yes, looks good, but the problem with the Frame+Label is relatively important. As I said, when I click somewhere on the Frame, the label gets invisible.
Hans

I've changed the control to a windowless one and am drawing everything manually now.

Everything seems to work now. But I had to remove some things:

• the events ContextMenu, MouseEnter, MouseHover, MouseLeave, because they don't work with windowless controls (at least not that easy)
• the events DestroyedControlWindow and RecreatedControlWindow (well, it's a windowless control now)
• the properties HoverTime and hWnd
• the rtlLayout flag (it's pointless for label controls)

Keyboard cues are still working. The reason they don't get displayed when pressing ALT although the keyboard hook is set up correctly, is that I did not yet find a windowless way to detect the change of the keyboard cue state and therefore can't redraw the control.

Hello! I cannot set RTL, it has no effect.
And the toolbox bitmap for the control is the MFC-symbol now (just in case you care).

TickTick wrote:Hello! I cannot set RTL, it has no effect.

It has. Remember that rtlLayout has been removed. The remaining rtlText makes "bla:" to ":bla", i. e. it influences the placement of punctuation marks only. If you really need rtlLayout back, I think I can add it again. But this will be an emulation then. Normally rtlLayout causes the point (0,0) be placed top-right instead of top-left. Using the SetLayout API function, it's possible to make a device context RTL. But windowless controls don't have their own device context, so (0,0) will have to remain top-left.

TickTick wrote:And the toolbox bitmap for the control is the MFC-symbol now (just in case you care).

ATL, not MFC. I've changed the icon on purpose. The old one was the icon of my Animation control.

I noticed that I need it back when I tried out WordWrap. When using Autosize of course you don't need it.
A bug:
Place the label in a frame and then set RTL true, and it will have a strange background (part of the frame border), although it's nowhere near to the Frame border.

I've added rtlLayout back. To keep it simple, the events still use left-to-right coordinates. Let me know if this is a problem.

The drawing issue is very likely another problem with my Frame control (it begins to drive me mad...).

Please see my bug report in the button controls bugtracker.

How well do you know C++? As I don't find a solution for the remaining drawing bug, I'm thinking about sending you the sourcecode.

I have given up. My dead line ended, so I don't have use for it anymore.
Regards,
Hans

I'm sorry to hear that.

Timo,
if you find the time, please fix the label. My app was buggy, so I have an extended dead line now.
Regards,
Hans

Do you want the C++ source code? I have run out of ideas and do not really have time to work on the control. I think that either the device context's origin gets somehow fucked up or drawing the label validates the whole device context and not just that part that is occupied by the label.