Activity Properties

hi all,

i know that i can bind activity properties to workflow properties using the designer; but is it also possible to bind activity properties to properties of other activities and: is it possible to bind activity properties not to a certain activity but to the parent activity’s properties

if you know something, please tell me. :-)
thanks in advance,
regards,
.k



Answer this question

Activity Properties

  • pig30n

    The designer will always display the name of the parent since it is readily available.

    It is still valid to specify your ActivityBind name as a relative path such as "/Parent/Parent..." The designer will always evaluate the name and display it though.

    You can try this by creating a simple workflow in VS and opening the .designer.cs file and modifying your ActivityBind to use "/Parent" instead of the actual name. You will see that it works just fine.

    Thanks!



  • NC01

    thanks again.
    but i have one more question:

    is there another way of binding activity properties to workflow properties than the way of binding every single activity property to every single workflow property

    the goal i am trying to reach, is: i would like to start a workflow with a bunch of parameters in form of a collection (for example an object[]), where this collection would be passed from the workflow start to activity1, activity2 a.s.o until the workflow is finished. (i hope you understand, what i mean..)

    regards,
    .k

  • PCU

    thanks for your answer.
    to get this right:

    there is no way to bind an activity property to the parent activity without specifying the parent activity with a name


    regards,
    .k

  • Thierry Nenin

    hi angel,

    would it also work, if i would (in the workflow.xoml) set the attribute 'name' in the activitybind-tag to "/Parent"

    regards,
    .k

  • Ryan_Willardryan

    You're doing everything correctly, actually. The problem is that the Visual Studio property browser has specific behavior for collections that is currently overriding our behavior - this is something I will have our product team look into.

    In the meantime, you have two possible workarounds:

    1) Edit the .Designer.cs file yourself and set up the binding - this will work fine.

    2) If you really want to use the Designer, then you'll have to make your property of type Object so that it brings up the correct dialog.

    I would go with option 1 right now if it's not too much trouble for you.

    To answer your second question -

    The workflow has no parent, so "/Parent" doesn't make sense here. But then again, you shouldn't have to bind it because if the data is coming from outside (most likely via paramter inputs), then its property will already be set at the time of execution.

    Thanks!



  • GregVance

    Ah! One of my collegues (designer expert) has the solution to the collection binding issue in the designer:

    _vihang wrote:

    You need to have the type converter attribute for the property in order to show the Bind dialog. Try adding this to the property

    [TypeConverter(typeof(ActivityBindTypeConverter))] and then you will be able to bind the property through the property browser.

    Hope this helps.

    - Vihang

    -Angel



  • kopi_b

    hi angel,
    first of all: thank you very much!
    this would be a very good aproach. what i dont know, is:

    instead of an object[] i am going to use an ArrayList, which i declared as a property in my workflow. (of course every single activity involved in the workflow has also a property of type ArrayList) in the workflow this would look something like this:

    //collection of objects
    public ArrayList ParamCollection
    {
    get { return (ArrayList)GetValue(ParamCollectionProperty); }
    set { SetValue(ParamCollectionProperty, value); }
    }

    public static DependencyProperty ParamCollectionProperty =
    DependencyProperty.Register("ParamCollection", typeof(ArrayList), typeof(WF1), new PropertyMetadata());

    so far so good...
    now, if i want to bind the activity’s property (ArrayList) to the workflow’s property (ArrayList), the properties window of the designer just leads me to the object collection editor.
    (if i would have defined properties of type string f.e. and try to bind them, i can do that by an activity reference...) and i think this is not correct. it should lead me to the 'existing activity reference' window, shouldn’t it

    so, the problem is, i am somehow not able to bind prperties to the parent activity (btw: could the workflow startpoint also be referenced with a "/Parent" path )

    do you see the mistake i might have made

    regards,
    .k

  • hedgeu

    This is an interesting question. If I'm not mistaken, you're looking for an implicit data flow throughout your workflow - we don't support this.

    You can definitely start off with an object[] as your workflow input and pass that to your subsequent activities (as a single ActivityBind instead of one for each property), but your activities would need to know what to do with it, i.e. they would have to be written in a way to accept a variable number of object inputs (probably in an assumed order as well unless you use a Hashtable) in the form of an array and do what they do.

    The benefit of binding every property is that you get strongly-typed validation on ActivityBind (it knows immediately if this is right or wrong), your activities look cleaner, and they are easier to program.

    Please let me know if I am not addressing your scenario. Hope this helps!

    -Angel



  • Mark Rodenhauser

    Absolutely. That is the equivalent of setting the property 'Name' through code.

    Thanks!



  • Santiago Cepas Lopez

    Yes, you can bind an activity property to another activity property, this is one of the very powerful features of WF.

    In Beta1, you used to be able to use "Parent" for the identifier before the path, but this doesn't seem to be available in Beta2.

    In the designer, you'll be able to choose the parent for the bind, and if you are building the bind in code, you can always get the name of the parent activity from the activity you are binding.

    Matt



  • PKH

    hi angel,

    once again - i hope for the last time, i have to bother:

    i am not sure how to use the eventhandler on the incoming dataflow. i gave every custom activity an event handler like you recommended. furthermore averey activity has a dependency property of type object. the binding between the activities is set in the .xoml by Name="/parent". so far so clear. but how does the event handler get involved in this scenario

    could you give me an example, please

    furthermore i am wondering, if it is possible for an activity to edit the data it gets from its parent activity and send the data to the next activity. do you know something about this

    thnaks in advance,
    regards,
    .k

  • BLOX

    It's no bother - here's how it should all come together:

    1) You create an instance of your workflow and pass it an ArrayList.

    2) Your first child activity, also having a property of type ArrayList (or object) binds to the workflow's ArrayList property.

    3) This activity also exposes an event (let's call it "DoWork") where you need to attach a handler to process your data.

    Here's what the fully configured first activity will look like:

    MyActivity firstChild = new MyActivity();

    firstChild.Name = "firstChild";

    firstChild.SetBinding(MyActivity.ArrayListDataProperty, new ActivityBind("/Parent", "ArrayListData");

    firstChild.DoWork += new EventHandler(DoWorkHandler);

    ...

    public void DoWorkHandler(object sender, EventArgs e)

    {

    MyActivity myActivity = sender as MyActivity;

    ArrayList data = myActivity.ArrayListData;

    // Do your thing with the ArrayList now

    }

    4) Subsequent activities work exactly the same, except that they would bind to the previous child instead of to the workflow ("previousChildName" instead of "/Parent" in the ActivityBind).

    5) All modifications to the data in the ArrayList will be visible to subsequent activities, as ArrayList is a reference type.

    Your workflow should now be set up to simulate a "flow" of data from activity to activity.

    Hope this helps!



  • Gorhal

    If you don't mind doing all of the work in your workflow, then handlers can definitely be used. You can expose an event in your custom activity as follows:

    public static DependencyProperty DoWorkEvent = DependencyProperty.Register("DoWork", typeof(EventHandler), typeof(MyActivity));

    public event EventHandler DoWork

    {

    add

    {

    base.AddHandler(ClassNamePlaceholder.DoWorkEvent, value);

    }

    remove

    {

    base.RemoveHandler(ClassNamePlaceholder.DoWorkEvent, value);

    }

    }

    In the executor of your activity, you can invoke this handler as follows:

    this.RaiseEvent(DoWorkEvent, this, EventArgs.Empty);

    Now when you use this activity in your workflow, you can attach handlers to the event and when you are called, you will be passed the activity as the "sender." This will let you access its properties, particularly the "object[]" property you need and perform the necessary operations on it.

    Your workflow will then look something like this:

    Workflow - receives payload of data (object[] for instance)

    CustomActivity1 - has a property of type object[] that is bound to the workflow's object[] property and has an event handler defined in the workflow that operates on the payload

    CustomActivity2 - same deal as previous activity but binds to CustomActivity1's property instead of the workflow's

    etc.

    This will give you a flowing pattern, but all of the data operations will reside in your workflow instead of inside your custom activities.

    Thanks!

    -Angel



  • Milo T. Minderbinder

    actually, an implicit data flow trough the workflow is exactly what i am trying to do. the problem of the activity’s need to know what to do with the incomming data would be the next step. (is it possible to extend the existing toolboxactivities with something like a handler for such a data flow )

    yes, that helped;
    thanks!


  • Activity Properties