Develop Reference

WF - myCustomType cannot be converted to myCustomType

I got this strange error from time to time when an workflow is activated:
Object of type
'System.Activities.InArgument1[myNamespace.myCustomType]' cannot be
converted to type
'System.Activities.InArgument1[myNamespace.myCustomType]'
I am trying to understand where this error comes from and I am thinking somehow a different version of the dll is loaded, but still I cannot explain why this happens and how this could be fixed.

It sounds like a mismatch. One thing to check is hit F7 when you're on the XAML designer to look at the raw XAML and find your code activity that is complainig. The inArguments should have a type like x:TypeArguments="local1:MyCustomType"
Then scroll to the top and look at the xmlns declaration and make sure it matches the namespace you expect xmlns:local="clr-namespace:MyNamespace.MyCustomType". Also check for dupes in that list.

Binding to a Binding: Data Binding indirection -or- Metabinding in WPF

No way to explain this issue except by example:
Say you have a custom UserControl with two DependencyPropertys, StatList Stats and string ImportantStat. The job of the user control is to display a table showing all of the values in Stats but with special visual treatment (like a pie chart) of the ImportantStat.
My instinct was to write a block of XAML that looked more or less like:
<PieChart Value="{Binding Path={Binding ImportantStat} }"/>
where the DataContext is prior set to Stats. So, the user passes in ImportantStat = "WinPercentage" and the pie chart binds to the WinPercentage Property of the stat line. But the user can just as easily pick some other Property to emphasize.
The problem (of course, you already know this, educated Stacker) is that you get an error message stating that you can't convert from Binding to string, which is what the outer Binding expects for Path. Though I haven't proven it to myself, I am guessing this is simply because Path is not a DependencyProperty.
So, is there any way to achieve my goal here? Feel free to break my assumptions in that first paragraph. Maybe, for example, ImportantStat can't be a string but must itself be a Binding.
Edit: Attempt #1 Failed
I was hoping that exposing from the code-behind a new DependencyProperty Binding ImportantStatBinding would allow me to rewrite the XAML as:
<PieChart Value="{Binding ImportantStatBinding, RelativeSource=... }"/>
...but to no avail. The indirect Binding is just stuck into Value itself with no attempts to resolve it.
My backup solution, which might be where this is headed, will be to just create the content inside the code-behind where I have access to ImportantStat directly and so can get away with a single Binding.

Far as I know, there is no way to concatenate data bindings in this way, without additional code. To put the problem more simply, we can have data binding (of course) of the form:
A --> B --> C
but you cannot have data binding of the form:
A --> B --> *A (*A indicates the target depends on the value of A)
because the relationships must be fixed.
It seems like it might be possible to create a Converter whose job is to convert a string into an arbitrary value by actually dereferencing a Binding using some additional context and that string as the property path. That sounds messy with type issues, so I chose the only other way I could think of:
I added a new DependencyProperty for the PieChart to the code behind and made sure that I constructed it at the appropriate times, so that the XAML could consume it. It's ugly, but it works. I just feel a little dead inside :) Hope someone finds this useful some day.

Any way to use object code in a User Control as a template for a new Object in a Sharepoint 2010 web part?

I'm trying to do something my teacher says can't be done; I would like to prove him wrong.
In the CreateChildControls method of my SharePoint 2010 webpart, I am referencing a User Control file called "ChartUserControl.ascx" in my project that contains the ASP.NET code for a WebChartControl object configured just the way I want it. WebChartControl has an ID of "OrderQtyChart".
What I want to do is take the code from that UserControl and use it create a new WebChartControl, called "chart", with matching configuration. I'm trying to do this because there are callbacks etc. that need to be performed on the chart after it's created to actually populate it with chart-stuff.
So, my code:
WebChartControl chart;
protected override void CreateChildControls()
{
ChartUserControl userControl = new ChartUserControl();
// referencing file ChartUserControl.ascx as an object
chart = userControl.FindControl("OrderQtyChart") as WebChartControl;
// or
chart = (WebChartControl)userControl.FindControl("OrderQtyChart");
// Trying to tell the code to create 'chart' using the code defined in object
"OrderQtyChart" located in ChartUserControl.ascx
}
Or something like that. In either instance above, 'chart' will return null.
I'm trying to use the front end code of OrderQtyChart as a template for 'chart'; they're both the same type of object and I don't get any errors until I try to create 'chart' on my page, at which point I'm told it's null.
Is there a way to do this? It would save me a ton of time not to have to configure 'chart' completely at creation time. Even if I have to reference my front-end code for OrderQtyChart a different way.
Thanks.
[Edited 7/9 for clarity]

What you are trying to do seems very well possible and I assume your teacher did not understand your question correctly. Here are a few tips on how this is done:
Object A could be one of these:
A visual control such as label or textbox. In this case your will have to traverse the visual controls from parent to child by doing direct parent.FindControl("ObjectA");
It is an instance of a class. This might be a MyClass or a new textbox that is created by code. In this case you'll have to create a public property that has a getter which returns ObjectA. although you can use FindControl in case ObjectA is a UI component that is created and added dynamically at run-time. Otherwise, you'll have to stick with property.
FindControl will not traverse the parent to child hierarchy, so you'll have to do a recursive method in order to successfully find the ObjectA or if you have access to its direct parent, call FindControl on that. More info here: http://geekswithblogs.net/QuandaryPhase/archive/2009/05/06/asp.net-recursive-findcontrol-amp-extension-methods.aspx
Page life cycle plays an important role here, so make sure that you keep it in mind or you'll end up with a null reference that is not really caused by FindControl

Gah, never mind. I realized I can just call the user control directly and I'm seriously overcomplicating this.
That's a whole new question, so I'll just start a different thread.

UITypeEditor and readonly reference type properties in .Net, WinForms

I thought I had type editors and converters nailed until I tried to persist a Readonly Reference type property after editing it in a UITypeEditor.
In my UITypeEditor, because I'm working with a read only property, I'm careful to pass back the original value (after updating the relevant sub property).
This change is reflected immediately on the designer but will not be persisted unless I do something like resize the control that the property is attached to.
To fix this I, blindly, include a call to context.OnComponentChanged() before returning the value.
I can see why this is needed. It's a reference type, I've altered it (not replaced it), and the property grid doesn't know this. I have a couple of questions for clarification:
Do I need a call to context.OnComponentChanging as well? A simple call to OnComponentChanged works in the tests I've done so far, but I don't want biting on the arse at some point in the future.
Also, is there any danger that, with my call to OnComponentChanging, I'll be persisting other components, in DesignerTransactions, that I shouldn't be persisting?

C#: Attrbute for intellisense to show method only outside of assembly

Basically what I'm hoping for is something that would work like how the Obsolete attribute works with Intellisense and strikes the method text when typing out the name. What I'm looking for is an attribute that blocks the method from being seen with the assembly it's defined. Kind of like an reverse internal. Using 3.5 by the by.
Yeah sounds odd but if you need the reason why, here it is:
My current solution for lazy loading in entity framework involves having the generated many to one or one to one properties be internal and have a facade? property that is public and basically loads the internal property's value:
public ChatRoom ParentRoom
{
get
{
if(!ParentRoomInnerReference.IsLoaded)
{
ParentRoomInnerReference.Load();
}
return ParentRoomInner;
}
set
{
ParentRoomInner = value;
}
}
Problem with this is if someone tries to use the ParentRoom property in a query:
context.ChatItem.Where(item => item.ParentRoom.Id = someId)
This will blow up since it doesn't know what to do with the facade property when evaluating the expression. This isn't a huge problem since the ParentRoomInner property can be used and queries are only in the entity assembly. (IE no selects and such in the UI assembly) The only situation comes in the entity assembly since it can see both properties and it's possible that someone might forget and use the above query and blow up at runtime.
So it would be nice if there were an attribute or some way to stop the entity assembly from seeing (ie blocked by intellisense) the outward facing properties.
Basically inside the assembly see ParentRoomInner. Outside the assembly see ParentRoom. Going to guess this isn't possible but worth a try.
I do see that there is an attribute
for stopping methods from being
viewable
(System.ComponentModel.EditorBrowsable)
but it's choices are rather slim and
don't really help.

You can use the EditorBrowsableAttribute for this:
[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
public void MyMethod() {}
One thing to know, though: In c#, you will still get intellisense on the method if it is in the same assembly as the one you are working in. Someone referencing your assembly (or your project, for a project reference) will not see it though. You can also pass EditorBrowsableState.Advanced, and then you will only get intellisense if c# if you clear the HideAdvancedMembers option in Tools Options.

I haven't heard of a good way to do this in plain .NET. But, here are some ideas. Maybe one of them will work, or set you off in a direction that will be helpful.
Use FxCop, probably writing your own rule to make sure ParentRoom isn't called from the asslembly that defined it.
Look into the various post-processing projects for .NET (link design-by-contract).
Write some code inside your ParentRoom getter which will check the stack (using "new Stack()" or "new StackFrame(1)" to figure out whether the caller was from the same assembly. If so, either throw an exception or simply return ParentRoomInner.