locked
How to set outargument on child activity from parent? RRS feed

  • Question

  • Hello

    I have a parent activity with a collection of child activities. I need to schedule each child activity, use the results of their execution in the parent activity then set an outargument on each child when the parent is completed. When trying to do this I get the error:

    An Activity can only get the location of arguments which it owns.  Activity 'Parent' is trying to get the location of argument 'OutFiles' which is owned by activity 'Child'.

    I have tried to set the childs argument with the parents context and also with the childs context (creating delegates and then invoking them) but does not make a difference.

    I do not override CacheMetadata so it should reflect on the public property ICollection<Activity> Children and set it up correctly. Execution of the child activities runs with no problem using context.ScheduleActivity and an in internal enumerator.

    How can I set a result on the child activity after it has completed execution, is this possible?

    Most of the examples I have seen use an implementation variable but set its value just before executing the child.

    e.g. http://social.technet.microsoft.com/wiki/contents/articles/passing-arguments-to-activities-scheduled-by-nativeactivity-wf.aspx

     Would I need to create a variable for each child, hook it up in cacahemetadata and then set its value when parent execution completes? 

     

    Thanks for any advice

     

     


    • Edited by T Rex Friday, October 14, 2011 1:06 PM
    Friday, October 14, 2011 1:06 PM

Answers

  • I came with a solution that does work and does not seem to violate any of the principles of the WF runtime. I execute the child activity twice - once in execute mode and once in results mode - the second time I execute it the child sets its own results i.e. its own arguments. These arguments are now available on the workflow designer and the user can link them to variables etc. Not a great way of doing it but at least from the users perspective they can interact with the child activity as expected.
    • Edited by T Rex Tuesday, October 18, 2011 6:20 AM
    • Marked as answer by LeoTang Sunday, October 23, 2011 10:52 AM
    Tuesday, October 18, 2011 6:20 AM

All replies

  • Here are some more details (Im hoping this will get me an answer!)

    The parent activity has a collection of child activities, each child is a factory that creates an internal pipeline process that is hooked into the parents pipeline. The pipeline process is the result of the child activities execution and is collected at execution callback. When the parent pipeline completes I need to set some outarguments on each child activity (like a status and other information). But at this point the child activity has finished executing and the context has gone out of scope for the child. The outarguments are required as they may be used by other activities in the workflow.

    Is there some technique I can use to set an outargument on a child activity from the parent after the child has finished executing?  The main problem I have is that the context is now running in the parents location and cannot be used to set any values onto the child (Reflector shows that there is a check internally that the runtime argument has the same owner as the context activity as shown below). At this point the context activity is the parent and the runtimeargument owner is the child and so the exception is thrown. Somehow I need to use variables to hook this all up but I canot figure it out.

    My last resort would be to create a dictionary of results on the parent and set each childs result into the dictionary with a key - other activities can then use the result dictionary for a child result - not a great solution but the best I can come up with right now.

    RuntimeArgument.GetLocation()...

     if (!object.ReferenceEquals(this.Owner, context.Activity))
            {
                throw FxTrace.Exception.AsError(new InvalidOperationException(SR.CanOnlyGetOwnedArguments(context.Activity.DisplayName, base.Name,  this.Owner.DisplayName)));
            }

    Monday, October 17, 2011 6:01 PM
  • I came with a solution that does work and does not seem to violate any of the principles of the WF runtime. I execute the child activity twice - once in execute mode and once in results mode - the second time I execute it the child sets its own results i.e. its own arguments. These arguments are now available on the workflow designer and the user can link them to variables etc. Not a great way of doing it but at least from the users perspective they can interact with the child activity as expected.
    • Edited by T Rex Tuesday, October 18, 2011 6:20 AM
    • Marked as answer by LeoTang Sunday, October 23, 2011 10:52 AM
    Tuesday, October 18, 2011 6:20 AM