locked
I have some basic questions on InArgument RRS feed

  • Question

  • 1. What is the purpose of the InArgument as opposed to a standard property?

    2. If I have no intention of holding an expression in the argument should I just use a standard property?

    3. When I write my activity to XAML, will it serialize standard properties' values? And deserialize them coming back?

    4. Would InArgument<FlowDocument> be weird? And in that circumstance, is it possible to bind directly to the FlowDocument from my designer?

    Friday, September 3, 2010 4:33 PM

Answers

  • InArguments are used to flow inputs into an activity when it executes, kind of like parameters on a method:

    void WriteLine(string msg)
    {
      Console.WriteLine(msg);
    }
    
    class WriteLine : CodeActivity
    {
      public InArgument<string> Msg { get; set; }
    
      override Execute(context)
      {
        Console.WriteLine(Msg.Get(context);
      }
    }
    

    Properties on an activity can be set at design time, or when the workflow is constructed in code, and then can be read by the activity at runtime, kind of like constant values. When you serialize a workflow to xaml that has properties, the values are serialized with it as part of the workflow.

    You should use arguments if you want to flow data into an activity (InArguments) or return data out of an activity once it has completed its execution (OutArgument, can be like a return value of a method or out parameter in a method, or you can use InOutArgument to be like a ref parameter)

    I am not sure what you mean by #4, what are you trying to accomplish and that may give me some ideas for suggestions.

    Thanks,

    Steve Danielson [Microsoft]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

     

    • Marked as answer by Andrew_Zhu Friday, September 10, 2010 6:16 AM
    Friday, September 3, 2010 9:19 PM

All replies

  • InArguments are used to flow inputs into an activity when it executes, kind of like parameters on a method:

    void WriteLine(string msg)
    {
      Console.WriteLine(msg);
    }
    
    class WriteLine : CodeActivity
    {
      public InArgument<string> Msg { get; set; }
    
      override Execute(context)
      {
        Console.WriteLine(Msg.Get(context);
      }
    }
    

    Properties on an activity can be set at design time, or when the workflow is constructed in code, and then can be read by the activity at runtime, kind of like constant values. When you serialize a workflow to xaml that has properties, the values are serialized with it as part of the workflow.

    You should use arguments if you want to flow data into an activity (InArguments) or return data out of an activity once it has completed its execution (OutArgument, can be like a return value of a method or out parameter in a method, or you can use InOutArgument to be like a ref parameter)

    I am not sure what you mean by #4, what are you trying to accomplish and that may give me some ideas for suggestions.

    Thanks,

    Steve Danielson [Microsoft]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

     

    • Marked as answer by Andrew_Zhu Friday, September 10, 2010 6:16 AM
    Friday, September 3, 2010 9:19 PM
  • Here's some follow up questions to make sure I understand:

    "InArguments are used to flow inputs into an activity when it executes, kind of like parameters on a method"

    1. In other words, I don't have a way to set public properties on an Activity at runtime -- those have to be done at design time, true?

    2. These arguments are set at runtime by other activities or by the execution engine? Anything else?

    "...or when the workflow is constructed in code"

    3. When is the workflow not constructed in code? When it's dragged onto a designer? Wait, that would be pre-design time.

    "...then can be read by the activity at runtime"

    4. Surely all properties on the activity can be read at runtime, regardless of type, true?

    "You should use arguments if you want to flow data into an activity (InArguments) ..."

    5. Where is this data coming from? Previously executed activities? Their results and OutArguments?

    6. Where is this data stored? In the global variables regestered with the executor?

    7. Surely if another activity was going to access the present activity and set its parameters, the type would not play into the availability of setting the parameter, true?

    "I am not sure what you mean by #4"

    8. I have an AvalonEdit control in one of my activity designers. I'm just wondering the best way to bind its text to a property. I want the text to be serialized as part of saving the activity and restored when the activity is recreated. The control is made to be bound to a Document of some kind, not a string.

    Saturday, September 4, 2010 4:41 AM
  • InArgument values are persisted when your workflow instance is persisted, and restored when you rehydrate it. Their lifetime is tied to the workflow instance. Property values are not tied to the workflow instance, instead they are tied to the workflow definition (XAML or whatever).
    Tim
    Saturday, September 4, 2010 6:24 AM
  • For 4):

    4. Would InArgument<FlowDocument> be weird? And in that circumstance, is it possible to bind directly to the FlowDocument from my designer?

    I'm not sure if it helps. You can do InArgument<Any type>, and use Variable<FlowDocument> to store data between activities.

    Monday, September 6, 2010 5:45 AM