The way I understand it, you want the indicator in the NotFilled state if none of the radio button within the group are checked and the Filled state if at least on of the radio button (within the same group) is checked. If this is correct, then your code is most likely wrong, this way it will set the indicator status based on the last radio button examined. Do something like

rb.Indicator.Status = myradiobuttongroup.Any(p=>p.IsChecked) ? Status.Filled : Status.NotFilled;

(not tested, may need polishing) H.

Thanks, I tried googling it but never tought of the term "split button".

What is the easiest way to get a button (acting like a normal Button) with a small arrow symbol or something on the right side and when the arrow is clicked, a submenu (ContextMenu) si displayed. This is fairly common espacially in toolbars and such, see for example "New Project" button in the Visual studio toolbar. I know I can probably get the job done with extensive templating but I want to code as little as possible and loose as little as possible of the default button behavior (mouse over effects implied by windows theme and such). Thanks for sugegstions.

Sure, but I want the standard behavior which displays the "no drop" icon (like a stop sign or something) when drop isn't allowed (meaning DragEffect is set to None). This works fine in windows forms and is even documented in WPF but for some reason doesn't work. It's not something I have to implement myself, it's internal Windows behavior, try to drag something somewhere and you'll see for yourself).

I have the basic drag and drop functionality up and running. Now I want to handle DragEnter and/or DragOver on the drop target and in the event handler decide whether or not the drop is allowed. I thought I would do this by setting DragEventArgs.Effects property to None when the drop is not permitted but this has absolutelly no effect - mouse cursor still looks like everything is ok and indeed Drop event is fired when you drop the item. I remember that this was the way to go in windows forms, how can I conditionally diallow dropping (other that AllowDrop=false of course) in WPF? Edited to add: Straight from MSDN: The drop target is also able to specify what effects it intends in response to the dropped data. For example, if the drop target does not recognize the data type to be dropped, it can refuse the data by setting its allowed effects to None. It typically does this in its DragOver event handler. So where is the problem? I am handling DropOver, settings Effects to None and yet the drop is allowed.

That is what I used for the time being - BooleanToFontWeightConverter, nice:-) - but I am looking for a more systematic approach because I am sure that design requirements will get more complicated than FontWeight=Bold.

Would have been cool is Silverlight supported triggers at all, there is no Style.Triggers collection... :( I'll do some digging, but honestly I didn't expect I'll spend so much time on such a simple matter you just take for granted in WPF.

Hi, I have a ListBox bond to a collection of following objects with string and bool property:

class Item
{
public string Text {get;set;}
public bool IsBold {get;set;}
}

The DataTemplate is simple enough:

<DataTemplate>
<TextBlock Text="{Binding Text}" />
</DataTemplate>

(could actually use DisplayMemberPath instead, I know) Now, I want those items that have IsBold == true to be bold-faced. As in WPF, where you add a simple DataTrigger that sets FontWeight=Bold on the TextBlock if IsBold is true. Is something like this possible in Silverlight and what is the recommended approach? Thanks, H.

To answer my own question, the following links have some useful info (different approaches): http://www.wintellect.com/CS/blogs/krome/archive/2011/05/24/sharing-code-between-silverlight-and-wpf-using-build-targets.aspx[^] http://msdn.microsoft.com/en-us/magazine/ee321573.aspx[^] The latter brought to my attention the possibility of file linking between projects, which I completelly forgot is possible.

What I meant (and also in my replay to OP) is that ListView (as opposed to ListBox) can be used this way

<ListView>
<ListView.View>
<GridView>
<GridViewColumn DisplayMemberBinding="{Binding FirstName}" Header="First Name" />
...
</GridView>
<ListView.View>
</ListView>

where the individual columns can be either autogenerated or more or less customized. Which I assume is what the OP wanted. This displays the "grid-view" known for example from file explorer if you select display mode->details. This is (I think) the primary purpose of ListView.

What is the difference/benefit between this and using ListBox? I thought ListView was supposed to be used with views (ViewBase-derived objects), like GridView - isn't that the case?

Check out ListView, it is customizable to some degree (with AutoGenerateColumns=false) and it will probably serve you just fine.

Hi I have a class library with code that is compatible with both Silverlight and standard .net libraries. (the minor incompatibilities can be solved with #if) How I can compile the code for both of these platforms? I mean - how do I set up Visual Studio to have two output configurations - one for .net, one for silverlight, so that my bin folder will contain two compiled .dlls? The project was initially created as Widnows Class Library and now I don't even know how to tell the VS to use Silverlight libraries to begin with:-(

I am starting to get it now. As I explained, I lived under the impression that model classes should only store data and not contain any means to manipulate them (this belongs to viewmodel). I learned this in some MVVM article, possibly not very good one because you say the direct opposite. Still it is good to know there are ways to deal with data sources I do not have under my control, so I appreciate Colin's input. But suppose the UI allows for direct manipulation with the individual Day objects (which are low in the whatever-Week-Day hierarchy). I could implement this by exposing a Manipulate (or something) command in the Day class, but rather in the DayViewModel class, since command handling is the viewmodel's job, right? If so, I am back to square one since I need the Day model class which manipulates the data and the DayViewModel which exposes the manipulation commands. If this is correct that the question still stands, how can the Week model class contain a collection of Day objects if it actually needs DayViewModel objects and thus would have to be tied with one particular viewmodel? If you say to expose the commands directly in the Day class, then I really see no point of VM layer since it would do nothing of any value.

Thank you guys for all replies. No need to argue, really. To clarify a few points: the project which inspired the question is certainly more complex than counting days in a week (it is actually sports related but I came with the example to spare myself the need to explain the particular sport). It is a non commercial activity of mine and I though that one of the benefits would be to get comfortable with the celebrated MVVM. That is why I overthink things, because in this rare case I can afford it, and I can hardly get a thorough understanding by underthinking. SledgeHammer's reaction was my reasoning exactly - why complicate things with unneccessary model objects when viewmodel alone does all I need with no further complications. But most design patterns have use for model classes, so I thought there must be a "proper" (whatever it means) way to desing the application with model and viewmodel separated. I'll look into factory classes, thanks for the suggestion. I never said there is 1:1 correspondence between model and viewmodel classes, on the contrary. I remember now what made me think about the design the way I described. In one article on MVVM (don't know which one, maybe I read too many) someone said that model classes should contain only data that need to be stored in the data store. In particular, data which can be computed should not be present in the model classes but rather in the viewmodel. Back to my example - if the Day class contains a DateTime information about the time some employee came to work and another DateTime info when the employee left, it is all you need to store. Then my view wants to show how many hours the employee spend working, which can be computed from the data but it is job (I believe/ed) of the DayViewModel to provide this information. That is why I thought I needed both Day and DayViewModel. I got the impression that model classes store data, viewmodel contains all logic and view deals with appearance. I don't seek perfect code for the sake of it but I can hardly appreciate the benefits of MVVM for large scale applications if I can't successfully use it (with a bit of overkill) even for a small application. I'll be happy to hear any other suggestions and advice, H.

I see I didn't express myself clearly. It is not really a functionality I am looking for, more like advice on how to deal with the given scenario using MVVM. If I ditch MVVM, I am ok. Another approach to explaining the question: how to work with two-layer model data in MVVM framework. As an abstract example - consider a SubItem class (model) and associated SubItemViewModel, then I have Item class (model; containing a collection of SubItems) and associated ItemViewModel. The application works with a collection of Items (we may call this application-level class SuperItemViewModel). Like I explained in the original post, the model classes consist of ordinary collections of another model classes while the view-model classes contain observable collections of associated view-model classes (this is how I understand MVVM, which may be wrong). My question is, how to best plug these M and VM classes together while maintaining sufficient separability. That is, in the imaginary Item model class I could directly use ObservableCollection of SubItemViewModels but this, in my understanding, has no place in model classes, which are supposed to be unaware of view-models. To say it most generally, I think I understand the V-VM part but I don't really get the M-VM part. Hope I made myself clearer. If not, I may give up this thread and MVVM altogether:-) Thanks for any suggestions.

This one will be easy, I guess. Suppose I have a model class, for example Day, with its properties. Then I have DayViewModel, which wraps the Day for viewing, presents some other properties which are not present in the model class (like TimeOfSunset which can be computed, whatever, it's an example). Then I have Week class, which is a collection of Day objects + additional properties. Then again, WeekViewModel which wraps Week for viewing. I am not doing this automatically - one VM class for each M class, I really need to show Days (in a list maybe), hence the DayViewModel, and I want to show and interact with Weeks, hence the WeekViewModel. Now to the question. The Week class must include some property like List<Day> Days; which will be populated when the Week is loaded from the data store. But WeekViewModel requires something more like ObservableCollection<DayViewModel>. Now this is awkward, I already have one collection and I need to create another with the same physical data, just to change Day to DayViewModel and List to ObservableCollection. I could live with that but it gets worse. Whenever the WeekViewModel's ObservableCollection gets changed, I must take care to change the Week's List accordingly so that when I save the model classes to the data store, I am sure to have the most recent version. What is the common way to deal with this simple scenario? I believe that one of the benefits of MVVM is the fact, that several ViewModels can work with one Model just like several Views can work with one ViewModel (correct me if I am wrong). Following this principle, I can't simply use ObservableCollection<DayViewModel> directly in the Week (model) class, because that would tie the Model with one particular ViewModel. So, is there a better way around this than the one I outlined? I'll be happy to hear your suggestions, H.

I wasn't wrong, just not really answering your question, sorry for that. I just wanted to outline the main differences between the two approaches, which is not really what you asked. Ad 1) sure, VM does not return colors, what I had in mind was a rather more complex object than just DisplayName and then ToString() forces you to condense all the data to one string, which can be very limiting and styling is of no help. Ad 2) of course you can use DataTemplates but I was talking about limitations of ToString().

I would say that ToString "converts" the whole object to a string, simple as that. Which means 1) you can't return any fancy colorful represantation other than a simple string and 2) the ToString() is global application-wise, meaning that you can't make two comboboxes displaying the same list of items make display slightly different things (which you can do with DataTamplates). DataTemplates are much more versatile, can be specific for a particular control (combobox) or used globally. They can also display much more complex data than just a string. Then there are value converters... The call is yours, ToString may be just fine for simple combobox item represatation, setting ItemTemplate doesn't hurt either.

DataTemplate is actually often used for the represantation of the entire object, arbitrarily complex (both the object and the representation).