none
GetAdornerLayer fails on InkCanvas RRS feed

  • Question

  • I have successfully used Adorners to do some "rubberbanding" on an InkCanvas. After I save and reload the contents of that InkCanvas (which contains ink and some child UIElements), I can modify the ink and the child UIElements of the reloaded InkCanvas all right, but I can no longer add an adorner to it, because AdornerLayer.GetAdornerLayer() applied to that InkCanvas always returns null.
    (Saving here just means: writing an XML file that holds all the relevant information to allow reconstruction of the original contents of the InkCanvas. Reloading means: using the same basic constructor as was used when the InkCanvas and its contents was constructed interactively, but then adding ink and some UIElements from the XML file to the InkCanvas.)

     This is especially surprising to me because if I save and then reload the (content of the) InkCanvas, the basic constructor used is the same, only the way I add some ink and child UIElements might conceivably be different from the case when GetAdornerLayer() returns != null.
     
    In order to find that difference (and somehow remove it) I need to know the answer to an apparently simple question (that, unfortunately I cannot answer myself, even after searching this forum and the internet more generally): Under what conditions can an InkCanvas fail to have an adorner layer? (I thought an InkCanvas would always have an adorner layer, but apparently that is not the case.)

    Many thanks in advance for any answers to this question.

    Regards,
    Failure
    Tuesday, November 11, 2008 7:43 AM

Answers

  • Failure said:

    I have successfully used Adorners to do some "rubberbanding" on an InkCanvas. After I save and reload the contents of that InkCanvas (which contains ink and some child UIElements), I can modify the ink and the child UIElements of the reloaded InkCanvas all right, but I can no longer add an adorner to it, because AdornerLayer.GetAdornerLayer() applied to that InkCanvas always returns null.
    (Saving here just means: writing an XML file that holds all the relevant information to allow reconstruction of the original contents of the InkCanvas. Reloading means: using the same basic constructor as was used when the InkCanvas and its contents was constructed interactively, but then adding ink and some UIElements from the XML file to the InkCanvas.)

     This is especially surprising to me because if I save and then reload the (content of the) InkCanvas, the basic constructor used is the same, only the way I add some ink and child UIElements might conceivably be different from the case when GetAdornerLayer() returns != null.
     
    In order to find that difference (and somehow remove it) I need to know the answer to an apparently simple question (that, unfortunately I cannot answer myself, even after searching this forum and the internet more generally): Under what conditions can an InkCanvas fail to have an adorner layer? (I thought an InkCanvas would always have an adorner layer, but apparently that is not the case.)

    Many thanks in advance for any answers to this question.

    Regards,
    Failure

    This problem seems to have been caused by faulty event handling in my code: because my application manages several InkCanvases at the same time, the selection of a "drawing tool" that required attaching an adorner to an InkCanvas generated an event to which all InkCanvases subscribed. Thus, after I had reloaded four InkCanvases from my XML file  and tried to attach a rubberband to the fourth (and only visible one), the first three (invisible ones!) successfully attached a rubberband (using GetAdornerLayer) to themselves. But for the fourth InkCanvas, GetAdornerLayer() then failed.
     I have now added an "if (IsVisible)" condition to the attaching of a rubberband to prevent invisible InkCanvases to also try to attach a rubberband to themselves.
     I suppose this really bad programming mistake on my part led to some kind of resource exhaustion as regards the AdornerLayer.

    Regards,
    Failure

    • Marked as answer by Failure Tuesday, November 11, 2008 8:58 AM
    • Edited by Failure Tuesday, November 11, 2008 9:04 AM
    Tuesday, November 11, 2008 8:57 AM