I've been experimenting with using TreeView>customDrawBlock:
First of all, I needed to add customDrawContextClass to return NMTVCUSTOMDRAW (this seems to be missing?). Secondly, I'm using customDrawBlock: to set some items in the Tree to be bold: [ :drawContext | drawContext item isSomething ifTrue: [drawContext font beBold]. false] This works OK, except the bounding box of the text isn't enlarged to accomodate the increased text size. Should this happen automatically or do I need to handle it myself (and if so, how)? Thanks. John Aspinall Solutions Software -- |
John
You wrote in message news:9conda$d8mb1$[hidden email]... > I've been experimenting with using TreeView>customDrawBlock: > > First of all, I needed to add customDrawContextClass to return > NMTVCUSTOMDRAW (this seems to be missing?). > Correct. Defect no. 207 which will be fixed in the next patch. > Secondly, I'm using customDrawBlock: to set some items in the Tree to be > bold: > > [ :drawContext | drawContext item isSomething ifTrue: [drawContext font > beBold]. false] > > This works OK, except the bounding box of the text isn't enlarged to > accomodate the increased text size. Should this happen automatically or do I > need to handle it myself (and if so, how)? It should happen automatically, since changing the font in any way causes the Dolphin framework code to return the CDRF_NEWFONT bit, which should (according to MSDN) adjust for the new font metrics. However I don't think that the Tree View control is implementing this correctly since as far as I can tell Dolphin does return CDRF_NEWFONT correctly. Aha! Just spotted: "Version 5.80. If you change the font by returning CDRF_NEWFONT, the tree view control might display clipped text. This behavior is necessary for backward compatibility with earlier versions of the common controls. If you want to change the font of a tree view control, you will get better results if you send a CCM_SETVERSION message with the wParam value set to 5 before adding any items to the control." It seems that this message was only introduced with IE5, so I have no idea what effect it will have on IE4 installations. Why anyone would want backwards compatibility with erroneous behaviour beats me. I tried it out by creating a new CHB view which emboldens all the classes. I noted that it should be sent before any items are added, so added it to #IconicListAbstract>>onFullyCreated before anything else. It does seem to work, .... for all but the root items, aaarrgh! Let me know if your experience is any better. Regards Blair ------------ CommCtrlConstants at: 'CCM_FIRST' put: 16r2000! CommCtrlConstants at: 'CCM_SETVERSION' put: 16r2007! !IconicListAbstract methodsFor! onFullyCreated "The receiver window has been created. Finish the job and apply the image lists" "Request version 5 control behaviour which supposedly fixes bug of control ignoring CDRF_NEWFONT bit returned from custom draw" self ccmSetVersion: 5. super onFullyCreated. self applyImageLists! ! !IconicListAbstract categoriesFor: #onFullyCreated!event handling!public! ! !ControlView methodsFor! ccmSetVersion: anInteger "Inform the contorl that behavior compliant with a particular common control version is expected." ^self sendMessage: CCM_SETVERSION wParam: anInteger lParam: 0! ! !ControlView categoriesFor: #ccmSetVersion:!operations!public! ! |
Blair,
> "Version 5.80. If you change the font by returning CDRF_NEWFONT, the tree > view control might display clipped text. This behavior is necessary for > backward compatibility with earlier versions of the common controls. If > you want to change the font of a tree view control, you will get better > results if you send a CCM_SETVERSION message with the wParam value > set to 5 before adding any items to the control." Hmmm... "better" rather than "correct"? Interesting choice of words. Thanks Microsoft! > I tried it out by creating a new CHB view which emboldens all the classes. > I noted that it should be sent before any items are added, so added it to > #IconicListAbstract>>onFullyCreated before anything else. It does seem to > work, .... for all but the root items, aaarrgh! Let me know if your > experience is any better. I'm getting the same results here - it's an improvement I guess. A couple of observations: - turning on hasLinesAtRoot has no effect - if I change NMCUSTOMDRAW>>evaluateDrawBlock: to always return CDRF_DODEFAULT, the font change still appears (with non-root items correctly resized if ccmSetVersion: 5 is included) Thanks for the feedback, John |
Blair,
One further observation - if the image is saved with an open window containing a TreeView with emboldened root items (incorrectly sized), then those roots are displayed correctly when the image is restarted. However if the model of the TreeView changes, the root items revert to being incorrectly sized. Any use? John Aspinall Solutions Software |
John
You wrote in message news:GiNL6.10927$[hidden email]... > > One further observation - if the image is saved with an open window > containing a TreeView with emboldened root items (incorrectly sized), then > those roots are displayed correctly when the image is restarted. > > However if the model of the TreeView changes, the root items revert to being > incorrectly sized. > > Any use? Hmmm, that's interesting. It certainly does point to it being some kind of ordering issue. Regards Blair |
Free forum by Nabble | Edit this page |