locked
Hidden Workflow Arguments to System.Activities.ActivityBuilder RRS feed

  • Question

  • Hi, I have rehosted the Workflow designer, and the base activity that i load is the Activity Builder(workflowDesigner.Load (activityBuilder);)

    I basically need to add in some details to the activity, and the value of which the user should not be able to edit (or may be even see on the designer surface). For this I am (currently) adding some arguments as follows where i can add in the extra information.

    activityBuilder.Properties.Add (new DynamicActivityProperty { Name = "HiddenArgument", Type = typeof (string), Value = "Value that the user should not edit." });

    But as these arguments are visible on the designer surface in the Arguments Panel on the bottom of the designer, the user can edit this. i also have other arguments that the user is allowed to edit so therefore i cant disable the whole arguments pane.

    I would just want to know how can i add my information to the workflow(and obviously save it in the *.XAML file) so that the user cant edit (or see) this information.

    EXTRA DETAILS: I basically want something like, if i create a custom activity i can add properties with [Browsable(false)], which causes the user to not see the property on the right side pane but hold a value!

    Thursday, April 7, 2011 6:34 AM

Answers

  • So they don't need any ability to add their own arguments, correct?

    You could have them edit a Sequence as the root of their workflow, instead of an ActivityBuilder? In this case the Arguments UI will disappear.

    >And with the ExecutionProperties you reffered to, can be added at the Execution time where as the Value i want to add is during the Design time (while the workflow is being created).

    Yes, you could do something like this, by at design time storing them in an attached property on your workflow. Especially if it doesn't need to be a VB expression.

    >Extra Details: just to clear out the scenario, i basically want to add in the Rehosted Designer version to the xaml file, so that when a user sends me the xaml that he/she created, i know which designer (version) i need to open it in so that there are no inconsistency.

    In this case storing it as an attached property sounds probably more reasonable than storing it as an argument. Other ideas things you could do: when serializing XAML, serialize your own custom wrapper object, which points to the workflow definition... so the XAML will contain both.

    Tim

    • Marked as answer by Andrew_Zhu Monday, April 25, 2011 7:37 AM
    Friday, April 8, 2011 6:35 PM

All replies

  • So the user is creating their own custom activity, but has to make it compatible with something particular of yours, is that right?

    Does the user creating your activity who can't see the arguments ever need to know they exist e.g. in expressions? How do you plan to retrieve the arguments yourself? Where do the arguments actually come from? Who controls the hosting environment?

    I'm asking all this because I wonder if Argument is a good solution. There are some other ways data could come into your workflow, especially if you control the hosting environment, such as ExecutionProperties, Workflow Hosting Extensions, Environment Variables etc.
    Tim

    Thursday, April 7, 2011 10:25 PM
  • i am sorry but i think i was a bit vague about it..

    The users are not making their own custom activity, they are just making a workflow using the activities that i provide in the Rehosted Designer.

    The User using the Rehosted Designer does not need to know they exist. i basically dont need to retrieve them programatically either, but when the XAML (with the workflow created by the user) is opened in any editor, the value should be there.

    And about the hosting, as its a rehosted Designer we have the full control of everything. and can retrieve arguments or anything, but retireval is not the problem. the issue is to store the value and not let the user to edit (or even see) it.

    And i thought so that there might be some other way to resolve this situation. And with the ExecutionProperties you reffered to, can be added at the Execution time where as the Value i want to add is during the Design time (while the workflow is being created). And Environment variables is not a solution as the Value just needs to be there in the XAML file and is not needed anywhere else.

    Extra Details: just to clear out the scenario, i basically want to add in the Rehosted Designer version to the xaml file, so that when a user sends me the xaml that he/she created, i know which designer (version) i need to open it in so that there are no inconsistency.



    Friday, April 8, 2011 9:56 AM
  • So they don't need any ability to add their own arguments, correct?

    You could have them edit a Sequence as the root of their workflow, instead of an ActivityBuilder? In this case the Arguments UI will disappear.

    >And with the ExecutionProperties you reffered to, can be added at the Execution time where as the Value i want to add is during the Design time (while the workflow is being created).

    Yes, you could do something like this, by at design time storing them in an attached property on your workflow. Especially if it doesn't need to be a VB expression.

    >Extra Details: just to clear out the scenario, i basically want to add in the Rehosted Designer version to the xaml file, so that when a user sends me the xaml that he/she created, i know which designer (version) i need to open it in so that there are no inconsistency.

    In this case storing it as an attached property sounds probably more reasonable than storing it as an argument. Other ideas things you could do: when serializing XAML, serialize your own custom wrapper object, which points to the workflow definition... so the XAML will contain both.

    Tim

    • Marked as answer by Andrew_Zhu Monday, April 25, 2011 7:37 AM
    Friday, April 8, 2011 6:35 PM