Thank you so much for your response. I thought I was being completely daft. I've been working with RadControls for a couple years now, but jut recently got tired of guessing at the most elegant ajaxifying patterns.
In code behind it seems like there are at least 3 ways to control ajaxification:
1) Ajaxify everything but don't provoke trigger events unless required
For example, in the case of a page with multiple pageviews activated by a tab (and I'll use this example below as well) the codebehind can check to see which tab is active before modifying a property on a control. If tab0 is active, don't set a property on anything that will trigger a refresh of tab1. This avoids the problem of an invisible control being updated by RadAjaxManager, and related errors. A problem here is when we want a timer trigger to update different tabs. But I think the solution is to have a different timer for each tab, and only enable a timer which has update controls for an active tab.
2) Ajaxify everything in markup but don't allow settings to get enabled.
sender, AjaxSettingCreatingEventArgs e)
( tab1.SelectedIndex == 1 && e.Initiator.ID.IndexOf(
// don't ajaxify tab 1, we're not there
3) Don't use markup, ajaxify in codebehind as needed:
For example (this is 'pseudo-code' and may not be technically accurate):
sender, RadTabStripEventArgs e)
( tab1.SelectedIndex == 0)
So, in addition to careful selection of controls, and not over-ajaxifying, is there a preference about whether to use any of the three methods above?
And I still need to find a solution to the mystery where we so,etimes cannot turn off a timer during its own timer_tick event. Here, trigger timer1 cannot have timer1 as an updated control. The timer1 needs to be in a panel1 and the timer1 trigger needs to update panel1. This sometimes works, sometimes not, depending on form complexity. As I find time in the next few days I'm going to see if a timer1 in a RadAjaxPanel will both trigger and update if I use: