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

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
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
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
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:
-Angel
kopi_b
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
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:
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)
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
yes, that helped;
thanks!