Discussion:
how to display a single tree-view item using different fonts?
(too old to reply)
anurag
2014-04-08 15:56:10 UTC
Permalink
Hello,

I'm faced with a problem where I need to display some characters in a tree-view item (those belonging to the Symbol charset) using "Symbol" font while others in the default System font (Segoi UI on my Windows 7).
Custom draw allows us to draw different items using different fonts but I wish to draw the same item string using different fonts as it applies to each character in the string as told above.
So, what I've done with not-so-pleasing results w.r.t. drawing performance upon a horizontal scroll when the number of items is more so far is this:

1). I disabled horizontal scrolling in my tree-view control using TVS_NOHSCROLL style (since I'm using my own scroll bar control inside the tree-view window to handle all horizontal scrolling)
2). I sub-classed the treeview control and in the sub-classed winproc, I handle the horizontal scroll notification and mouse notification (where I do my own hittesting and send message like TVM_EXPAND and TVM_SELECT as a result of mosue clicks/double-clicks). Also the scroll bar range is set based on how wide my custom drawn string is (the maximum length amongst all items).
3). I draw the string for each item upon receiving CDDS_ITEMPOSTPAINT using my own fonts for each character in the item.

The above approach (I left out some details for the sake of brevity) works BUT there are some problems which makes me post this question here and look for an alternare way:

Problems:

1). The horizontal scroll bar control I create is hosted "inside" the tree-view control at the bottom of the tree-view window. However, when the number of items goes beyond what the tree-view client area can accommodate vertically, the last visible tree-view item gets obscured by the scroll bar control. This can be solved by not making the scroll bar a child of the tree-view and hosting it outside the tree-view window just below it. But I don't want to do this since the scroll bar should typically be a child window of the tree-view.

2). This is the major one. Since I draw the items myself at each horizontal scroll, the drawing performance upon horizontal scrolling is very slow and also leads to flicker upon scrolling.

Any ideas will be much appreciated as I've been grappling with this for the last one week without success.
I can also post the relevant code here if you want to see the approach I took but I'm sure there shoould be a better approach to this and there must be some other people who would've faced this problem and solved it in the past.

Thanks in advance,
--ANURAG.
Deanna Earley
2014-04-09 08:30:27 UTC
Permalink
Post by anurag
Hello,
I'm faced with a problem where I need to display some characters in a
tree-view item (belonging to the Symbol charset) using "Symbol" font
while others in the default System font (Segoi UI on my Windows 7).
Custom draw allows us to draw different items using different fonts
but I wish to draw the same item string using different fonts as it
applies to each character in the string as told above.
So, what I've done with not-so-pleasing results w.r.t. drawing
performance upon a horizontal scroll when the number of items is more
1). I disabled horizontal scrolling in my tree-view control using
TVS_NOHSCROLL style (since I'm using my own scroll bar control inside
the tree-view window to handle all horizontal scrolling)
2). I sub-classed the treeview control and in the sub-classed
winproc, I handle the horizontal scroll notification and mouse
notification (where I do my own hittesting and send message like
TVM_EXPAND and TVM_SELECT as a result of mosue clicks/double-clicks).
Also the scroll bar range is set based on how wide my custom drawn
string is (the maximum length amongst all items).
3). I draw the string for each item upon receiving CDDS_ITEMPOSTPAINT
using my own fonts.
The above approach (I left some details for the sake of brevity)
works BUT there are some problems which makes me post this question
1). The horizontal scroll bar control I create is hosted "inside" the
tree-view control at the bottom of the tree-view window. However,
when the number of items goes beyond what the tree-view client area
can accommodate vertically, the last visible tree-view item gets
obscured by the scroll bar control. This can be solved by not making
the scroll bar a child of the tree-view and hosting it outside the
tree-view window just below it. But I don't want to do this since the
scroll bar should typically be a child window of the tree-view.
2). This is the major one. Since I draw the items myself at each
horizontal scroll, the drawing performance upon horizontal scrolling
is very slow and also leads to flicker upon scrolling.
Any ideas will be much appreciated as I've been grappling with this
for the last one week without success.
I can also post the relevant code here if you want to see the
approach I took but I'm sure there shoould be a better approach to
this and there must be some other people who would've faced this
problem and solved it in the past.
I'm not sure what the horizontal scrolling has to do with the drawing of
the item text.
Why don't you just do the CDDS_ITEMPOSTPAINT handling to draw the item
as required?

It removes a big chunk of the faff you have at the moment.

(Also, please don't multipost, Google should allow you to post to both
here and microsoft.public.win32.programmer.ui)
--
Deanna Earley (***@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be printed, shredded then fed
to the rats. Please reply to the group.)
Robert Miles
2014-04-18 19:15:38 UTC
Permalink
[snip]
(Also, please don't multipost, Google should allow you to post to both
here and microsoft.public.win32.programmer.ui)
The last time I checked, Google did NOT allow crossposting.
Deanna Earley
2014-04-22 07:48:49 UTC
Permalink
Post by Robert Miles
[snip]
(Also, please don't multipost, Google should allow you to post to both
here and microsoft.public.win32.programmer.ui)
The last time I checked, Google did NOT allow crossposting.
Disappointing given their "don't to that that is evil" mantra.
--
Deanna Earley (***@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be printed, shredded then fed
to the rats. Please reply to the group.)
Loading...