SmartArt constraints: Evaluation flow

Question

I am somewhat stumped on what order constraints are being evaluated in a smartart layout. In some of the layouts I create it appears that values being set in the parent node are taking precedence. In others I get an error because the parent references a missing constraint even though I clearly set it in the child layout node. I was just curious if anyone had knowledge of how the constraints (and subsequently rules) are addressed by Office. More specificly what is the flow between parent and child layoutnode constraints, so I can better understand why some values are being overridden. 

Thanks in Advance!

Answer 1

Hi SamH89,

Thank you for your question.  An engineer from the Protocols Team will contact you soon.

---

Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

Answer 2

Hi SamH89,

I will look into this for you and get back to you shortly.  An excerpt from your code might be helpful if you can post it here.

Best regards,
Tom Jebo
Escalation Engineer
Microsoft Open Specifications

Answer 3

So, In this very simple layout, the width in the outer layout node(50) overrides the constraint set in the inner node(10):

<dgm:layoutNode name="diagram">
	<dgm:varLst>
		<dgm:dir/>
		<dgm:resizeHandles val="exact"/>
	</dgm:varLst>
	<dgm:alg type="lin"/>
	<dgm:shape xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" r:blip="">
		<dgm:adjLst/>
	</dgm:shape>
	<dgm:presOf/>
	<dgm:constrLst>
		<dgm:constr type="primFontSz" for="ch" forName="node"  val="20"/>
		<dgm:constr type="w" for="ch" forName="node"  val="50"/>
	</dgm:constrLst>
	<dgm:ruleLst>
	</dgm:ruleLst>
	<dgm:forEach name="Name3" axis="ch" ptType="node">
		<dgm:layoutNode name="node">
			<dgm:varLst>
				<dgm:bulletEnabled val="1"/>
			</dgm:varLst>
			<dgm:alg type="tx"/>
			<dgm:shape type="rect" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" r:blip="">
				<dgm:adjLst/>
			</dgm:shape>
			<dgm:presOf axis="desOrSelf" ptType="node"/>
			<dgm:constrLst>
				<dgm:constr type="w" val="10"/>
			</dgm:constrLst>
			<dgm:ruleLst>
		<dgm:rule type="h" val="INF" />
			</dgm:ruleLst>
		</dgm:layoutNode>
		<dgm:forEach name="Name4" axis="followSib" ptType="sibTrans" cnt="1">
			<dgm:layoutNode name="sibTrans">
				<dgm:alg type="sp"/>
				<dgm:shape xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" r:blip="">
					<dgm:adjLst/>
				</dgm:shape>
				<dgm:presOf/>
				<dgm:constrLst/>
				<dgm:ruleLst/>
			</dgm:layoutNode>
		</dgm:forEach>
	</dgm:forEach>
</dgm:layoutNode>

But in other cases, such as Microsoft's Accent Process layout, you see top level constraints being beat out by child level constraints:

<!-- Set initial composite width to maximize available area -->
<constr type="w" for="ch" forName="composite" refType="w" />
						
<!-- Set equality between children and transitions -->
<constr type="w" for="ch" ptType="sibTrans" refType="w" refFor="ch" refForName="composite" fact="0.3333" />
<constr type="w" for="des" forName="parTx" />
<constr op="equ" type="h" for="des" forName="parTx" />
<constr op="equ" type="h" for="des" forName="parSh" />
<constr type="w" for="des" forName="desTx" />
<constr op="equ" type="h" for="des" forName="desTx" />
<constr type="w" for="des" forName="parSh" />

I know that some of these are ultimately adjusted by rules, but looking at these three:

<constr type="w" for="des" forName="parTx" />
<constr type="w" for="des" forName="desTx" />
<constr type="w" for="des" forName="parSh" />

As far as I can tell from the specs, these set their respective widths to zero. A value which is only referenced again in child nodes. Are child level constraints sometimes revisited after touching the parent constraints? Is this done as part of the rule satisfaction? Ultimately the specs say very little about how constraints are evaluated.

Thanks again, 

Answer 4

Hi SamH89,

thanks for your patience while I continue to research this.  I hope to have something for you soon.  In the meantime, this article:

Create Custom SmartArt Graphics For Use In The 2007 Office System

discusses some of the nuances of constraints and rules. 

Thanks,

Tom

Answer 5

SamH89,

The following link:

http://msdn.microsoft.com/en-us/library/gg583880.aspx

points to a more recent article on creating custom SmartArt layouts. While not explicitly defined, if you do a search for “constraints”, you’ll see that the article talks about how constraints impact the layout at a root versus a node level.  Let me know if this doesn't help.

Tom

Answer 6

I have the same question. How to understand this constraints?

<dgm:constr type="w" forName="parTx" for="des"/>
<dgm:constr type="h" op="equ" forName="parTx" for="des"/>
<dgm:constr type="h" op="equ" forName="parSh" for="des"/>
<dgm:constr type="w" forName="desTx" for="des"/>
<dgm:constr type="h" op="equ" forName="desTx" for="des"/>
<dgm:constr type="w" forName="parSh" for="des"/>

Answer 7

Hi SamH89, do you understand how to use this constraints? I can't get a response from tech support. "Read the documentation" that's all they can say.

Answer 8

Unfortunately I wasn't able to find much more. The links posted above have been the best info i could find. As far as i can tell the "h" constraints are there to ensure that the heights of those elements are consistent between the different composite groups. The "w" possibly reset the widths to zero to ensure that they are recalculated further down the chain?  

Answer 9

Maybe my new discussion can help you.

http://social.msdn.microsoft.com/Forums/en-US/os_binaryfile/thread/c68fee14-56b8-4be4-845e-928fb2230a29

Answer 10

It looks like Josh's answer in:

http://social.msdn.microsoft.com/Forums/en-US/os_binaryfile/thread/c68fee14-56b8-4be4-845e-928fb2230a29

addresses the "h" and "w" questions. 

Tom