Peter B. West wrote: > depend on the type supported by the Property. Take MaxWidth. What > value will be returned? An int, representing the number of millipoints? > An Integer? A Length object? What happens when the width is, as > yet, unresolved, because it depends upon the resolution of the width of > a reference area in the Area Tree? The value is not undefined, just > unresolved. When the FO Tree interacts with the Area Tree, the length > will be resolved. But the Area Tree may be re-laid, in which case the > value will revert to unresolved.
This is a good question. The answer to the first part is that it should return an int, representing the number of millipoints. When it cannot be resolved, it should return an int constant TBD_LAYOUT (or whatever), which is equal to -32,987 (or whatever). So, the Area Tree or Layout needs to then perhaps query another "get" method to determine how it should compute the value from its Area Tree context, or, as I mentioned in a recent (within the past hour or so) posting in response to Glen, either 1) passing context data to "get", or 2) making "get" look at the area tree context before returning the value. The second of these requires making the FO Tree nodes know about their Area Tree children. Each node in the Area Tree not only has a parent, and possible siblings, and possible children in the Area, but also has a parent in the FO Tree. Each node in the FO Tree can therefore know what its children in the Area Tree are as well. > The resolution of properties within the FO Tree has dependencies on the > resolution of areas in the Area Tree. Do you like any of the 3 possibilities above as potential solutions? And, importantly, are there ways that your work can help us implement any of this? I know you have a huge investment in trying to solve this problem, and, although I don't "get" all of it, I want to make sure that 1) all of your concerns are addressed, and 2) as much of your work is used in the solution as possible. Victor Mote
