Design-Time User Activity Input (WF 4.0)
I want to better understand the capabilities and limitations of what can be done with custom actions in WF 4.0 at design time. More specifically, what can we do in the user activity so that we can allow the designer to interact in their own way during development to provide details / data about the activity.
For example, I would like to create activity A, and when a workflow designer places that activity into a workflow in the designer (either the Visual Studio designer or the refactored designer in a separate application), a .NET dialog box can be displayed, allowing the user to enter data (for example , specify the file via the "Open file" dialog) and check the input data, i.e. runs some code whenever a particular text field is focused or input (event handlers).
Can this be done and saved in a workflow XAML file?
Note that all of this capability is required in the workflow designer when the workflow is actually being developed.
Thank.
source to share
The WF4 designer is quite capable. You can add designer controls so that the end user can interact directly with the design surface without using a property sheet. You can also add confirmation actions to check if the entered data is acceptable or not. All of this is done at the activity level in C # or VB code, not at the workflow level. I'm not sure about events where activity is dropped, but I believe they are supported as well (they are somewhere in Wf3 at least and I expect this to be carried forward.
source to share
There are several ways to connect to event notifications when an activity is added to a workflow.
The first one listens for the TextChanged event in the WorkflowDesigner class (Beta1), or I think it will be the ModelChanged event (in Beta2) which is more reliable. This is a notification that something has changed in your workflow. Nothing fancy, just something, but you can use this as a trigger to traverse your workflow and look for new, unconfigured activities.
The second possibility is to take advantage of the fact that every ModelItem (which is a design-time wrapper for an activity) implements INotifyPropertyChanged. Instead of listening for changes throughout the workflow, you can listen for changes to certain properties, such as the Body of the While activity, and then when the property is initialized to hold the new activity, respond to that change.
The third possibility is that your interesting activity has a custom constructor (which you write) - and this scenario looks like it fits what you think. Here you can completely customize the look and feel of your activity. A custom designer is just a WPF control. You can use the same data binding and validation events and methods that you use when developing a WPF application, or react to regular WPF events. You can of course pop up the dialog boxes if you like.
As far as storage in XAML files is concerned, of course, custom actions are stored in XAML files along with all their configured properties - just like normal actions. If you want to load the XAML file again, you need to provide contextual information about the assemblies that store the actions referenced by the XAML file. In VS it is as easy as adding assembly references, in a reuse scenario you have to write a little code to do this.
You may like to read more about this or ask similar questions in the .NET Framework 4: Workflow Foundation - Beta 1 Forum
source to share