locked
binding converter for everything? RRS feed

  • Question

  • Wow so I am getting frustrated with the custom designers.  I keep getting errors related to type cast of values from string to inArgument<string>.

    I can get around this by writing a converter for everything, but it seems that this is the ONLY way to get around it.
    Is there an easier way other than to write converters for every single InArgument<type>?

    ---------------------------
    Workflow Designer
    ---------------------------
    Object of type 'System.String' cannot be converted to type 'System.Activities.InArgument`1[System.String]'.
    ---------------------------
    OK  
    ---------------------------

    Matthew Christopher
    Monday, November 30, 2009 5:11 PM

All replies

  • Can you take a look here and see if it helps:

    http://blogs.msdn.com/cathyk/archive/2009/11/12/expressiontextbox-101.aspx

    Thanks,
    Kushal.
    Kushal Shah - This posting is provided "AS IS" with no warranties, and confers no rights
    • Proposed as answer by kushals Monday, November 30, 2009 5:29 PM
    Monday, November 30, 2009 5:29 PM
  • It does help a little however as noted in the post I have combo boxes (fixed list of input values) and want to pull its values as content for my input arguments.

    Even this article notes

    *Aside – this is the only convenient converter for binding basic UI elements to arguments (WorkflowItem[s]Presenter excepted). In this release, you have to write your own converter to bind say a check box to a boolean argument.

    Are there plans to address this in the release candidate?
    Matthew Christopher
    Monday, November 30, 2009 6:13 PM
  • Also why can we not just use our standard POCO objects and just decorate them with an attribute to indicate what the usage of them is in the context of the activity.  For example you could decorate as input, output or Both.  This would give far greater functionality as it would let people design and implement activities based on methods and objects that they already have existing in their repositories. 

    Matthew

    Matthew Christopher
    Monday, November 30, 2009 6:19 PM
  • Hi Matt,
    It sounds like you want to configure string values using a textbox, or enum values using combo boxes, on an Activity at design time. I am not really sure whether you have a good reason to use InArgument, and am wondering if maybe a POCO property would work better than an InArgument or OutArgument. i.e. set 'Property' direction in the Arguments designer, or if you are creating CodeActivity/NativeActivity using

    public class MyActivity : CodeActivity
    {
        public string strVal { get; set; }
        public MyEnum enumVal { get; set; } //rather than public InArgument<MyEnum> enumArg { get; set; }
    }

    This should make them much more convenient for binding. The main thing you might lose by doing this is the ability to compute the value at runtime (as opposed to setting it at design time).

    Tim
    Tuesday, December 1, 2009 6:16 PM
  • Hi Tim,

    i'm new to the workflow foundation, and i'm wondering if this would be threadsafe?

    public class MyActivity : CodeActivity
    {
        public string strVal { get; set; }
        public MyEnum enumVal { get; set; } //rather than public InArgument<MyEnum> enumArg { get; set; }
    }
    cheers,

    Chris
    Tuesday, December 8, 2009 8:54 PM
  • it is thread safe, but it does not solve the problem of using the input arg.  Basically I want to give someone the ability to use the designer OR use the standard input arguments.  To do this I have to use converters but I really wish the casting just worked and input or output argument were just done through attributes.

    Matthew Christopher
    Wednesday, December 9, 2009 5:35 AM