Docking and Anchoring
-
Control docking and anchoring are well understood by everybody and we all know that the two techniques are mutally exclusive. The help pages says something like "Only one can be set at a time, and the last one set takes precedence". I've always believed what I'm told by my elders and betters and was certain that code like the following would create an anchored control.
FancyControl fc = new FancyControl();
fc.Anchor = AnchorStyles.Top | AnchorStyles.Left;
SomePanel.Controls.Add(fc);My FancyControl would typically be used fully docked and the constructor helpfully presets that condition. On the very rare occasion it should be anchored then just assign a value as shown. Why oh why then, did the control remained dicked?
FancyControl fc = new FancyControl();
Debug.Print("Dock: {0} Anchor: {1}", fc.Dock, fc.Anchor);
// Dock: Fill Anchor: Top, Left
fc.Anchor = AnchorStyles.Top | AnchorStyles.Left;
SomePanel.Controls.Add(fc);On reading the Anchor property all became clear as the value was already Top|Left. Perhaps the Anchor property ignores redundant assignments? Of course it does and a delve into the published reference source confirms this. Search for DefaultLayout.SetAnchor in Reference Source[^] if you are interested. The final solution for the simple task of setting the control's anchor property is
FancyControl fc = new FancyControl();
fc.Dock = DockStyle.None;
SomePanel.Controls.Add(fc);OK I should have included the statement
fc.Anchor = AnchorStyles.Top | AnchorStyles.Left;after undocking but it's redundant! AlanN aka Alan "2f hours debugging" N -
Control docking and anchoring are well understood by everybody and we all know that the two techniques are mutally exclusive. The help pages says something like "Only one can be set at a time, and the last one set takes precedence". I've always believed what I'm told by my elders and betters and was certain that code like the following would create an anchored control.
FancyControl fc = new FancyControl();
fc.Anchor = AnchorStyles.Top | AnchorStyles.Left;
SomePanel.Controls.Add(fc);My FancyControl would typically be used fully docked and the constructor helpfully presets that condition. On the very rare occasion it should be anchored then just assign a value as shown. Why oh why then, did the control remained dicked?
FancyControl fc = new FancyControl();
Debug.Print("Dock: {0} Anchor: {1}", fc.Dock, fc.Anchor);
// Dock: Fill Anchor: Top, Left
fc.Anchor = AnchorStyles.Top | AnchorStyles.Left;
SomePanel.Controls.Add(fc);On reading the Anchor property all became clear as the value was already Top|Left. Perhaps the Anchor property ignores redundant assignments? Of course it does and a delve into the published reference source confirms this. Search for DefaultLayout.SetAnchor in Reference Source[^] if you are interested. The final solution for the simple task of setting the control's anchor property is
FancyControl fc = new FancyControl();
fc.Dock = DockStyle.None;
SomePanel.Controls.Add(fc);OK I should have included the statement
fc.Anchor = AnchorStyles.Top | AnchorStyles.Left;after undocking but it's redundant! AlanN aka Alan "2f hours debugging" NAlan N wrote:
did the control remained dicked?
Is that gender-specific control property? ;) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
Alan N wrote:
did the control remained dicked?
Is that gender-specific control property? ;) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
No, having a dick does not imply gender at all these days. :rolleyes:
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
Control docking and anchoring are well understood by everybody and we all know that the two techniques are mutally exclusive. The help pages says something like "Only one can be set at a time, and the last one set takes precedence". I've always believed what I'm told by my elders and betters and was certain that code like the following would create an anchored control.
FancyControl fc = new FancyControl();
fc.Anchor = AnchorStyles.Top | AnchorStyles.Left;
SomePanel.Controls.Add(fc);My FancyControl would typically be used fully docked and the constructor helpfully presets that condition. On the very rare occasion it should be anchored then just assign a value as shown. Why oh why then, did the control remained dicked?
FancyControl fc = new FancyControl();
Debug.Print("Dock: {0} Anchor: {1}", fc.Dock, fc.Anchor);
// Dock: Fill Anchor: Top, Left
fc.Anchor = AnchorStyles.Top | AnchorStyles.Left;
SomePanel.Controls.Add(fc);On reading the Anchor property all became clear as the value was already Top|Left. Perhaps the Anchor property ignores redundant assignments? Of course it does and a delve into the published reference source confirms this. Search for DefaultLayout.SetAnchor in Reference Source[^] if you are interested. The final solution for the simple task of setting the control's anchor property is
FancyControl fc = new FancyControl();
fc.Dock = DockStyle.None;
SomePanel.Controls.Add(fc);OK I should have included the statement
fc.Anchor = AnchorStyles.Top | AnchorStyles.Left;after undocking but it's redundant! AlanN aka Alan "2f hours debugging" NAnchoring is not use in WPF. Docking is used if you use a DockPanel.