On Monday 2006-06-05 16:21 -0700, L. David Baron wrote: > Unfortunately it looks like all box-related frames other than menubar > should have had this bit set in the past; however, judging by what > happens with my IsFrameOfType implementation, they didn't. I need to > figure out which of them, if any, actually had the bit set, and why the > code in ConstructXULFrame didn't do what it looks like it did.
I still haven't figured out what was going on (although I have
eliminated the possibility that it's something wrong with the code I
wrote to change the bit tests to IsFrameOfType tests).
However, I was thinking that we might want to change the way we
implement IsFrameOfType slightly:
* use virtual *inline* functions
* make implementations call their base class
So nsIFrame.h would have:
virtual PRBool IsFrameOfType(PRUint32 aFlags) const {
return !aFlags;
}
a frame that wanted to be SVG would then have:
virtual PRBool IsFrameOfType(PRUint32 aFlags) const {
return baseclass::IsFrameOfType(aFlags & ~(eSVG));
}
a frame that wanted to undo being a type its base class was would do:
virtual PRBool IsFrameOfType(PRUint32 aFlags) const {
return !(aFlags & (eReplaced)) && baseclass::IsFrameOfType(aFlags);
}
We might even want macros to do this.
I'd hope that compilers could optimize this to the equivalent of what we
do now (rewriting the whole thing in condensed form in derived classes).
I'm also thinking that I want to make our use of typedefs like
nsBlockFrameSuper more consistent (although many of them are macros).
Though I may want to make them typedefs within the class, e.g.,
nsBlockFrame::super_type.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
pgpp0NhgEtBMB.pgp
Description: PGP signature
_______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
