I agree that one shouldn't call a method on an entity from an overrule for that method called for that same entity. For example, if I were to call Attribute.TransformBy from my overrule of Attribute.TransformBy.
Yes, you can't call TransformBy() from the Overrule's TransformBy (at least not without disabling overruling temporarily to prevent reentance).
However, your description implies that the Attribute.Rotation property 'set' function calls TransformBy in its implementation. It doesn't.
No, I wasn't trying to imply that at all. And of course, it doesn't do that because if it did, that code would fail with a stack overflow. Actually, it's quite the opposite. The implementation of AcDbText::transformBy() is what sets the rotation member along with other members to perform the complete transformation.
If it did, then my code would have crashed the first time it was run as the overruled function was recursively called. That being the case, I really don't consider setting the Rotation property in the overrule as being any different from (say) setting the Color property.
I understand your point about using the transformation matrix, but I remain satisfied that the solution I use efficiently achieves exactly the behavior I wanted to implement in a single line of code (not a kludge). It also serves the additional purpose of avoiding having to present a larger and more complicated chunk of matrix manipulation code in a beginner tutorial.
Well, if a somewhat advanced topic like overrules are suitable as examples in an entry-level tutorial that targets those with no previous programming experience, then I think it should be done correctly and in the most efficient way (by manipulating the matrix). Perhaps its because I've always held the view that training materials both formal and informal, should always emphasize correctness and should not promote kludges as ways to solve problems, because kludges almost always come back to bite you in the arse.
On that subject, your tutorial purports to assume no prior programming experience. Perhaps you meant no prior object-oriented programming experience? I mention that because while it only very briefly touches on the most-basic of programming concepts such as conditional branching with 'if', variables, etc., It seems to rush the user past all of that and somewhat hastily proceeds to dive head-first into advanced oop-related concepts like inheritance, polymorphism, virtual methods, and so forth. It's almost as if it were trying to squeeze years of learning into one short, informal lesson.
While it certainly is useful for giving an entry level person a hands-on taste of what can be done using the APIs, I would not recommend it as a 'first lesson' for those with no prior programming experience. In fact, introductory training should have nothing to do with AutoCAD development at all, as it only interjects more confusion into something that is already confusing enough :d
I've come to view serious development with .NET and ObjectARX as something that should really be done by professional programmers rather than AutoCAD users that happen to also be weekend programmers. Scripting with LISP is certainly in the domain of the latter, but complex development with any flavor of ObjectARX is something that should be left to skilled professionals, because of the potential damage that inexperienced programmers can do. I remember one case where an inexperienced LISP programmer was able to corrupt a very large dataset to the extent that repairing it ultimately cost over 1000 times the fee he was paid.
I'm happy to agree to differ on this - working through the transformation matrix is also a good solution if that is your preference.
Well, doing it via manipulating the matrix also helps to show how one might apply the same kind of constraint to other types of entities like for example, block references that represent annotative elements or symbols containing text, dimensions, leaders, etc., more generally, cases where certain geometry and text should always have the same relative orientation.