I am studying a code base developed using .NET WPF. I am using Visual Studio 2008 IDE. In the XAML code, I have a line as follows:
<MenuItem Header="About" Click="Main_Window_ContextMenu_About_Click">
Clicking right mouse button, I see a option called "Navigate to Event Handler". However, clicking it does not take me to the Event Handler definition. In fact, this action seems to have no effect.
Why is this happening and how can I fix this issue?
If you're using ReSharper, hit F12 while the cursor is on the event handler name (assuming you're using ReSharper's default shortcuts)
That shortcut in the XAML designer isn't very reliable - it only works when the event handler method is defined in the code-behind for the XAML file. For example, if you have "Window.xaml" it will only work if the handler is in "Window.xaml.cs".
This breaks, for example, if the event handler is defined in a second partial class file like "Window_EventHandlers.cs". This particular one even generates a new blank event handler in the code-behind file which promptly fails to compile on a duplicate method definition - yuck!
If you can't find it, your best bet is probably a solution or project-wide search for the method name.
This is a known issue. There are several ways to fix it, including re installation.
Related
i have a very simple question but i just can't find the answer. I have an existing Windows forms project which shows me an interface with lots of different buttons when i run it in Visual Studio 2019.
Now i want to find a way to find the code belonging to a button. I already tried clicking the buttons, but nothing happens.
So my question is: How can i automatically jump to the code that is related to one of the buttons?
Thanks a lot!
I am assuming that when you say "the code belonging to a button", you are referring to the code that runs when the button is clicked. In this case there are several ways of getting to this code.
In Winforms (not sure about anything else) you should be able to double click on the button and visual studio should navigate automatically to the code in the Button.Click event. If there is no Button.Click event handler for the button, it will create one.
Another way to get there is to select the button in the designer and go to the properties window(press F4). In the properties window go to the events list(see images), then double click on the "Click" event in this list and you should be directed to the code in the Button.Click event handler. If there is none, it will create one.
I hope this helps. If not, provide more details about your issue.
Why visual studio generates event method with number postfix, Ex: instead generating Click event of a button as button_Click, it generates button_Click_1 where there is no click event present.
Well am quite certain you have a stale button_Click somewhere.. find it and remove it
In VS2013, I renamed one of my button event handlers and wanted to drop into the [Design] to change the property. I got a huge warning telling me that things are not as they seem (expected, since I changed the delegate's name) so I hit Ignore and Continue. This is the first time I've hit this button.
To my horror, what I saw was ... a blank template as opposed to my original winform. I have backups of my code, so I'm not too worried, but I was wondering how I'd go about restoring my Form1.cs[Design] without going back a code rev.
This is what my [Design] looks like now:
Did your error say this?:
By renaming the delegate in your code file, you hung the designer out to dry. Everytime you switch to the designer tab, it parses InitializeComponent() to draw your controls for editing, and since the reference to the original callback doesn't exist anymore, the designer doesn't know what to do when it encounters the unknown reference. By forcing its hand, it simply craps out like it was telling you it was going to do. The blank panel is just a result of it failing and drawing nothing.
Pop open your Form1.Designer file and find where the button's properties are set. The unknown reference is probably highlighted in red. Change the name to whatever you changed in your other file. Here's an example, but with a panel instead of a button:
And then your designer should return to normal. No worries about rolling anything back, it's a minor fix.
I’ve met strange behaviour for WPF design-time in Visual Studio 2010: after an instance of the Popup class was created, and I switched the code tab in Visual Studio to a different file, the Popup still remains on the screen!
I have a piece of code, which allows to reproduce this, but I am not sure if I should paste it here (it's not so short), so maybe I'll just give a link to it: here.
For unknown reasons beyond mere mortals' comprehension, Microsoft has decided this is the default behavior of the Popup class in WPF. You have to implement the "hiding" logic yourself. I suggest handling the Window.LocationChanged, Window.Activated and Window.Deactivated events of the Window containing the Popup and close it yourself.
Edit: To clarify myself, the Window events you need to handle are the events of the window that contains the Popup's PlacementTarget element. Usually when you create a popup, you set it relative to some element contained in an application's Window (similar to how the tooltips work). If this is your case, then my solution is correct, but I forgot to mention this point about the PlacementTarget.
In your code behind; you can simple check this boolean:
DesignerProperties.GetIsInDesignMode(this);
"this" represent the object containing the popup. For example the Window.
If true you can say:
myPopUp.IsOpen = false;
For Store Apps/WinRT:
Windows.ApplicationModel.DesignMode.DesignModeEnabled
I have a related question here where i have a user control with a command binding. The user control has being removed from the visual tree, yet the canExecute is still firing. My understanding of the Commanding model was that it bubbles and tunnels like routed events. So how can the CanExecute fire once the element with the command binding attached is no longer in the visual tree?
IMO, CommandBindings are really poorly implemented in WPF. You have to work around the fact that the system keeps a WeakReference to your control if it has a CommandBinding, even when the control is closed.
You will see lots of examples online on how to set up a CommandBinding in XAML code. The problem is all these examples are going to introduce performance problems into any app where they are pasted. The CommandBindings never go away properly on their own. At least, not for a long time.
The solution is to:
A) Do not set up CommandBindings in XAML. You have to use the code behind. Suggest using the Constructor after you have called InitializeComponent(). Use this.CommandBindings.Add() to add the CommandBindings with code.
B) handle the Closed() event of your Window or Control and call this.CommandBindings.Clear().
This is the only way I have been able to reliably get the CommandBindings to quit firing. I think this is a ridiculous way for this feature to have been implemented by Microsoft. The fact that so many online examples teach you to declare CommandBindings in XAML just exacerbates the problem.
My Guess is that there is an instance of the command registered with the commandmanager. Commands can be executed from many different sources not just UI for example shortcut keys.
Try calling CommandManager.InvalidateRequerySuggested(); and add a break point in your canexecute method to confirm that this is the case.
Hope this helps.