开发者

WPF Wired Event Handler is not called

Day 2 and I don't have a clue. [.Net 3.5, VS 2008]

I have a UserControl that defines a ClickEvent:

public static readonly RoutedEvent ClickEvent = EventManager.RegisterRoutedEvent (
  "Click", RoutingStrategy.Bubble, typeof ( RoutedEventHandler ), typeof ( TouchToggleButton ) );

and an OnClick method:

protected virtual void OnClick ( )
{
    RaiseEvent ( new RoutedEventArgs { RoutedEvent = ClickEvent, Source = this } );
}

In each of two different windows, I wire an instance of this control to an event handler.

<wft:TouchToggleButton DockPanel.Dock="Top" x:Name="measurableButton" Click="measurableButton_Click">Cannot Measure</wft:TouchToggleButton>

and

<wft:TouchToggleButton x:FieldModifier="public" x:Name="BuyoutButton" Click="BuyoutButton_Click">Buyout</wft:TouchToggleButton>

and, finally, I have the two handlers defined:

private void measurableButton_Click ( object sender, RoutedEventArgs e )
{
    IsMeasurable = !IsMeasurable;
    OnMeasurableButtonChanged ( );
}

and

private void BuyoutButton_Click ( object sender, RoutedEventArgs e )
{
    IsBuyout = !IsBuyout;
    OnBuyoutButtonChanged ( );
}

In both cases, if I put a breakpoint at the OnClick, it hits. In the case of the measurableButton, the RaiseEvent goes to measurableButton_Click; in the case of the BuyoutButton, the RaiseEvent does NOT go to BuyoutButton_Click.

There is nowhere in the app an unwiring (-=) of the BuyoutButt开发者_运维技巧on.Click. What further could I check to discover the reason for the difference in these behaviors?


With thanks to Rachel for making me think about the event, I realized I had left out

public event RoutedEventHandler Click
{
    add { AddHandler ( ClickEvent, value ); }
    remove { RemoveHandler ( ClickEvent, value ); }
}

in my inherited class. (Being an event, it does not inherit.) This fixed my problem, although I still wonder how it ever worked in the first place.


I know this doesn't help you understand how to do what you asked, but I have a suggestion anyway in case this turns out to be an XYZ problem.

Just from looking at what you're doing, which is toggling Boolean values with a more or less custom implementation of a Button, I would suggest using a ToggleButton instead. It would be a more WPF-ey way to do it.

That way the state is clear in the UI, you don't have to hook up the logic, the toggling is handled for you, and you can bind to the IsChecked value!

Anyways, my two cents' worth.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜