Bug in ClassHierarchySelector Moen view resource

I found what amounts to a bug in the ClassHierarchySelector Moen view
resource in Dolphin 5. The problem shows up for me on a win98 machine,
but not on 2000. It may not be that significant a bug, but it sure was
interesting figuring it out. <g>

On my win98 laptop, the Moen Tree View in the Class Diagram displayed
names that were too long by truncating the name and adding ellipses both
*before* and after. So for example, AXTypeLibDocumentation was displayed
as '...AXTypeLibDocumen...'. This didn't seem right, so I wanted to fix
it.

After much browsing and some debugging, I zeroed in on
MoenTreeView>>calculateNodeExtents:forCanvas:. I found that the instance
variable "dtflags" had the value of 278580. This breaks down as:
'DT_VCENTER' -> 4;   'DT_WORDBREAK' -> 16;   'DT_SINGLELINE' -> 32;
'DT_PATH_ELLIPSIS' -> 16384;   'DT_WORD_ELLIPSIS' -> 262144. This didn't
seem right, and indeed the MS platform SDK documentation on DrawTextEx
seems to imply that PATH and WORD ELLIPSIS are mutually exclusive.

I tried to figure out where the variable was being set wrong and looked
at all of its writers. It is initialized to the class variable
SingleLineMask which has been set to 32804 or
'DT_VCENTER' -> 4;   'DT_SINGLELINE' -> 32;   'DT_END_ELLIPSIS' ->
32768. The only other method that modifies it is #hasWordWrap:, but that
has no senders. I was stumped.

Eventually it dawned on me that view resources are instantiated by
filing in the binary representation of a prototypical one from a byte
array. Indeed, if you open a View Composer on
'ClassHierarchySelector.Moen view', go to "classes" inside the
ScrollingDecorator and inspect "classes", you'll find that the instance
variable "dtflags" is 278580. I changed this to 32804 (the default
SingleLineMask), and saved the view resource.

Now the Moen Tree view (correctly) only puts ellipses at the end of long
names, so that it shows, for example, 'AXTypeLibDocumenta...' rather
than '...AXTypeLibDocumen...'. Mission accomplished. :-)

This fix is also fine on Win2000, where apparently the original
conflicting flags were being resolved differently than they were on
Win98.

I also figured out that by saving the Development System package to a
.pac file, which includes the ClassHierarchySelector presenter class,
that I could edit the file to extract the expression:
    (ResourceIdentifier class: ClassHierarchySelector name: 'Moen view')

        assign: (Object fromBinaryStoreBytes:
            (ByteArray fromHexString: '215354422031 ... 10K more ...'
This can be used as a patch as part of a script when building a new
working image from the distribution. Seems like there could be a better
way, since only 6 characters within the 10K string are changed, but at
least it works.

I tried just dragging it from the Resource Browser to a Workspace to get
the text representation directly, but that's not a drag/drop combination
that works.

In summary, I guess that one of the lessons that I need to remember is
that view resources are prototypical things that have been edited and
inspected into their current state, and aren't necessarily making use of
the methods and code that are there.

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill,

> After much browsing and some debugging, I zeroed in on
> MoenTreeView>>calculateNodeExtents:forCanvas:. I found that the instance
> variable "dtflags" had the value of 278580. This breaks down as:
> 'DT_VCENTER' -> 4;   'DT_WORDBREAK' -> 16;   'DT_SINGLELINE' -> 32;
> 'DT_PATH_ELLIPSIS' -> 16384;   'DT_WORD_ELLIPSIS' -> 262144. This didn't
> seem right, and indeed the MS platform SDK documentation on DrawTextEx
> seems to imply that PATH and WORD ELLIPSIS are mutually exclusive.

Thanks for this (and the great amount of research you've done to track down
the problem). This has been entered as issue #946 and your fix should appear
in the next Live Update release.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Bill,

> This can be used as a patch as part of a script when building a new
> working image from the distribution. Seems like there could be a better
> way, since only 6 characters within the 10K string are changed, but at
> least it works.

For a temporary fix you should be able to get around it by reinitialising
the sub view (so it uses the values defined in the current class) in your
script and then resaving the complete resource.

ri := ResourceIdentifier class: ClassHierarchySelector name: 'Moen view'.
v := ri load.
v subViews first initialize.
ri save: v

The only problem (I think) with this is that some of the resources aspects
which are reset by #initialize might have been edited in the VC before the
resource was originally saved. This isn't an issue for a lot of Views, they
just use the default values, but in the above case some aspects, e.g.
#maxTextExtent have been modified and must be reset.

ri := ResourceIdentifier class: ClassHierarchySelector name: 'Moen view'.
v := ri load.
sv := v subViews first.
mte := sv maxTextExtent.
sv
    initialize;
    maxTextExtent: mte.
ri save: v

Another handihint (tm) is that mutating views is an easy way of doing the
above in the ViewComposer if you edit a non reference sub view or suspect
that resource and definition might have got out of sync.  For example,
select the 'classes' view in the ViewComposer (as you originally described)
and then select  "Mutate view" followed by "MoenTreeView" from the context
menu. As the sub view is already a MoenTreeView the only difference will be
that it is reinitialised.  Mutate does attempt to restore original aspect
values so it should work without needing any intervention.

--
Ian
Due to spamming the reply-to address may only be valid for the next few
days.  Use it to mail me _now_ if you want a longer term contact address

Ian Bartholomew wrote:

Ian,

Thanks a bunch for all the examples and hints about view resource
initialization. I learned a lot by going through them all and studying what
they're doing.

I think that I might use the above, perhaps even long term. I actually like the
fact that it resets the maxTextExtent to not truncate the names at all. With my
screen width (1024) there's only one branch of the class hierarchy that is too
deep to completely fit without scrolling (ADODB_Recordset), and actually it
never had any truncated names in its superclass path in the first place. All in
all it's nicer to simply see the full class names in the view.

Andy, any thought of changing the Moen Tree view limit of 120 for the width of
the class names while you're at it?

regards,
-Bill

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA