Accessing a control on the view?

Feb 27, 2011 at 5:06 PM

I am using 3rd party telerik controls, in specific the RadScheduler. I cannot bind things to it so I need to be able to say things like this

_scheduler.AppointmentsSource = myApps;
_radScheduler.ResourceTypes.Add(resourceType);
_radScheduler.SetFirstVisibleDay(datetime);
Without access to the scheduler I'm not sure what to do. I tried implementing IViewAware but the methods don't seem to fire.

Feb 27, 2011 at 10:30 PM

You have 2 options:

 - Inherit and override OnViewLoaded of Screen, you have access to your view:

		protected override void OnViewLoaded(object view)
		{
			base.OnViewLoaded(view);
		}
- Use GetView method inside (almost) any of your Screen class methods.

Then you cast it to your view type and find your control.
Feb 27, 2011 at 10:58 PM

This doesn't seem to work... I think it's because I am using 

cal:Action.Target="ScheduleViewModel"

Feb 28, 2011 at 1:57 AM

In order to exploit IViewAware you have to let CM to pick up the view and bind it to the ViewModel (ViewModelBinder takes care of this); then, you can get a reference to  the view when IViewAware.AttachView got called.

Using Action.Target just sets the VM (picked from the IoC container with the specified key "ScheduleViewModel") as the handler of actions coming from the element subtree.
If you really want to follow the view-first approach, you might use Bind.Model attached property, which also executes the view/VM binding.

My personal preference is to always use model-first approach and access the view using the overrides suggested by vcaraulean; it is also simpler.

Feb 28, 2011 at 2:04 AM

I'm having trouble determining how to do this. I am using the hybrid screen layout and this control is used on multiple screens with State="Schedule". The problem is the screen that I am on is considered to be the main ViewModel but the code for the "Schedule" is big enough to warrant it's own view model. I guess in this case it is just better to use the Bind.Model or am I not doing something quite correct?

Feb 28, 2011 at 1:24 PM

As I understand your scenario, you have a MainViewModel with its corresponding MainView, which contains the RadScheduler; then you have a ScheduleViewModel to actual handling scheduler.
Problem is that MainViewModel is hooked to the view, while ScheduleViewModel it's not. 
The best I can suggest without a deeper knowledge of the scenario is to expose ScheduleViewModel as a property on MainViewModel, so that it could receive a reference to the view from its parent.

Does it help? 

Feb 28, 2011 at 3:44 PM
Edited Feb 28, 2011 at 3:45 PM

That is a good idea actually... However using Bind.Model also did work. Is there any downsides or reason why I should instead use one approach over the other in this case?

Thanks for your help.

Feb 28, 2011 at 7:19 PM

Aside from personal preference, I prefer to use an uniform approach: model-first or view-first.

I use to keep all the application logic in the VM side, thus gaining a better organization and the possibility to unit test all the "interesting" parts.
As a consequence is a no brainer for me to use model-first: the view part became mere visualization, so I avoid to drive the application composition from it.
My views usually contains just binding (if any, since CM supports powerful conventions); if the scenario requires a direct access to the view, I prefer to handle it as an exceptional case, temporary switching to an MVP-style approach. 

This is very convenient and well supported by CM without breaking the main application model abstractions and overall MVVM philosophy.

Mar 2, 2011 at 11:58 PM
Edited Mar 3, 2011 at 12:12 AM

As a design note you should avoid muddying up your ViewModel with direct references to your view. It makes your code harder to test in isolation since you're create a direct dependence between your view and ViewModel, which defeats one of the advantages of an MVVM based approach.

For anything you can't bind directly to you usually can take the approach of creating a behavior (blend or attached) to make it MVVM friendly. Here's an example of using an attached behavior to allow binding Telerik's RadScheduler ResourceTypes:

http://www.telerik.com/community/forums/silverlight/scheduler/using-databinding-for-resourcetypes.aspx

Also mentioned in the link above if you're writing a new application you may want to target the soon to be released RadScheduleView instead of RadScheduler. RadScheduleView is much more MVVM friendly (includes the ability to bind to the ResourceTypes), performance friendly and provides additional features over RadScheduler.

You can examine/download the beta of the new RadScheduleView for Silverlight here (release version scheduled for mid March):
http://demos.telerik.com/silverlight/beta/#ScheduleView

http://www.telerik.com/community/forums/silverlight/scheduleview/radscheduleview-for-silverlight-pre-beta-release-is-here.aspx


The RadScheduleView has already been available for the past few versions of the WPF Telerik control suite. The other reason to switch is RadScheduleView is it is designed to replace RadScheduler which eventually support will drop for in favor of RadScheduleView, more information here:

http://blogs.telerik.com/valerihristov/posts/10-10-25/telerik_scheduleview_for_silverlight_wpf_questions_and_answers.aspx