UPDATE: So, I have a solution to my immediate problem. I haven't succeeded in making "my own" TreeView class. But, the reason I wanted to do that was because controls based on ButtonBase don't function in a Popup from a TreeView, and with the help of #MarkFeldman, I have found a solution that comes at it from a different angle.
The problem is that the MouseDown and MouseUp events bubble, and that bubbling crosses the logical tree boundary between the Popup and its owner. So, when you click on something hosted inside the Popup, the TreeViewItem and TreeView that ultimately own the Popup get to hear about it. This then triggers code inside the TreeView that checks, "Do I have focus?", and if not, helpfully sets focus back to itself -- but being a separate logical tree, the Popup has its own focus context, and so this effectively steals focus from the Button control while it is in the middle of processing a click. The Button responds to this by ignoring the click.
This erroneous handling in the TreeView only happens when MouseDown and MouseUp events reach it. What if there were a way to prevent it from seeing those events in the first place? Well, if you intercept the PreviewMouseDown and PreviewMouseUp events and mark them Handled, then the framework doesn't generate MouseDown and MouseUp events to begin with.
Looking at the Reference Source, it looks like ButtonBase's click handling is tied up in a couple of protected methods:
https://referencesource.microsoft.com/#PresentationFramework/src/Framework/System/Windows/Controls/Primitives/ButtonBase.cs,414
https://referencesource.microsoft.com/#PresentationFramework/src/Framework/System/Windows/Controls/Primitives/ButtonBase.cs,478
This means you can call them from your own subclasses! So, instead of making "my own" TreeView where all controls behave properly, instead I can make "my own" CheckBox that works properly in a Popup from a TreeView. Since all of the actual click handling is directly accessible, and the events it normally responds to use the same EventArgs type as the Preview events, and on top of it the default handling takes care of marking the events as Handled, the entire implementation boils down to this:
public class CheckBoxThatWorks : CheckBox
{
protected override void OnPreviewMouseLeftButtonDown(MouseButtonEventArgs e) => base.OnMouseLeftButtonDown(e);
protected override void OnPreviewMouseLeftButtonUp(MouseButtonEventArgs e) => base.OnMouseLeftButtonUp(e);
}
Nice!
ORIGINAL QUESTION:
I need to make a clone of the TreeView WPF class -- a copy of the control that runs out of my own code. (There is a bug in the control and Microsoft doesn't seem to deem it high-enough priority to fix, and it makes it completely impossible to host buttons (including check boxes and radio buttons) within pop-ups shown from TreeViewItems. link)
I am running into serious difficulties with the amount of internal shenanigans Microsoft has undertaken in the implementation of base WPF controls. A couple of issues I've bumped into:
Controls have a property HandlesScrolling that allows them to take over basic scrolling handling from ScrollViewer. But, it's marked internal, making it seemingly impossible for me to have a control of my own that does its own handling of scrolling from keyboard input. I was going to try having my TreeView handle keyboard scrolling in OnPreviewKeyDown instead of OnKeyDown, so that it can prevent KeyDown events from being raised for the keys it intercepts. I haven't gotten far enough to know what caveats there might be about this.
The Visual States system allows you to declare what styles should be applied when different states are entered, but actually entering states seems to be tied up in the virtual method ChangeVisualState on the Control type. All controls that want to switch between visual states can override this method and inspect their state to determine which Visual State should be shown. Oh wait. They can't because the method is internal! Apparently only Microsoft gets to create controls that set their own visual states??
Are there any strategies I can use to work around these limitations, or am I just completely out of luck?
Related
Scenario: The customers have the ability to set an annotation to the PDF page. This is handled as a richtextbox object. There's a bug, however, that when the user is making an annotation and wants to scroll down manually (drag scrollbar down), that the annotation moves with it.
I want to implement code that detects the scroll event, so that the annotation can be exited and placed properly before the program scrolls down/up.
What was to be a simple procedure, ended up in a not so simple venture, but I'm getting used to that evolution in programming...
We can see the WM_VSCROLL message with spy++, but can't find it with a Console.Writeline in wmdproc, which points to it being handled by an event, but for the life of us, we can't find which event exactly.
We tried overriding our mistery scroll event in both the MainForm as its parent, but no success. Also tried overriding it in the PDFViewCtrl, but it forbids us to override there.
So we're kind of at a loss here. We know the event is handled, we just can't find where.
We use Pdftron and DevExpress, but it's worth noting that we do not use their DE's PDFViewer. Ours is a PDFViewCtrl loaded into a DevExpress Xtraform.
The annotation scrolling is the expected behaviour. Triggering the lost focus event when clicking on the scroll bars is not possible with the PDFViewCtrl class.
I've been playing around with events in WPF and have so far I've got good mileage out of 'Source' and 'OriginalSource' properties of the event args as well as using the sending control and FocusManager. Here's the thing, when a chain of events starts firing, is there any way to know what control will be ending up with focus at the end barring any intervening logic throughout the chain of events?
I'm afraid that the only reliable way of doing this is actually letting focus change and then handling it in some PreviewGotKeyboardFocus handler at top view level.
You can then know which control was going to get the focus, and cancel the change with e.Handled = true.
PD. There's a function in all UIElements called PredictFocus, but it only works with positional traverse changes, not with tab-based changes (or custom focusing).
I have a WinForm app, the form has TabControl, control has three tabs tabPage1,tabPage2,tabPage3.
The Tab 'tabPage3' is hosting a User defined control which internally has one or more child controls.
Now my problem lies in tabPage3,
I know it is a pure Winforms behavior, until your parent is not activated child controls Onload event won't fire.
I have a requirement to force the Onload event to fire when the focus is on tabPage1, tabPage2. Is there any way to force the Onload event to fire.
I have already visited following links but didn't find any clue. Link Link Link
This is a very unusual requirement, strongly smells like an XY problem. The Load event is heavily over-used in Winforms, a side-effect of it being the default event for a Form or UserControl. One of the behaviors inherited from VB6, the Load event was a big deal in that language. What you want can easily be accomplished by not giving Winforms a choice:
public UserControl3() {
InitializeComponent();
CreateHandle();
}
The CreateHandle() call does the forcing, OnLoad will immediately run. But do be aware that this happens very early, too early to do the kind of things that you'd really want to use OnLoad() or the Load event for. Which are rather limited, it is only truly necessary to discover the actual Location and Size of the control. Anything else belongs in the constructor. Surely including the code that you now run in OnLoad().
Strongly favor using the constructor instead.
I had a similar problem for a previous project, for my needs I managed to just iterate over every tab page in the forms constructor (or possibly OnLoad I can't remember) and then reset the index back to 0 before ever showing the end user.
Something similar to:
for(int i = 1; i < tabControl.TabCount; i++)
tabControl.SelectTab(i);
tabControl.SelectTab(0);
In Windows Forms when a UserControl or Form first time becomes visible the Load event is fired.
http://msdn.microsoft.com/en-us/library/system.windows.forms.usercontrol.load.aspx
Is there any such event for controls like Checkbox, TextBox, Label ?
No. You could use the HandleCreated event, it is fired when the native window for the control is created. The first event you can rely on to run after the class constructor ran. It is triggered when the parent adds the control to its Controls collection and the control becomes visible.
Beware however that it this event can fire more than once. Controls may be re-created when certain properties get reassigned, the kind that requires the native CreateWindowEx() function to be called with new style flags. So you'll at least need to carry around a bool flag that keeps track of this.
Also note that setting properties of a control after the native window is created is pretty inefficient. All Winforms controls were designed to allow properties to be set before the native window is created. Whatever code you are generating almost surely should use the class constructor instead. Either of the derived control itself. Or in the code of the parent, much like InitializeComponent() does for a form or user-control.
The same is true for the existing Load event. It tends to be over-used due to the VB6 legacy where the Load event was very important. In Winforms however it is only required for code that depends on the final location and size of a control or form. Which may be different from the design properties due to form scaling. Any other code belongs in the constructor.
I have a full screen WPF application built for a touch monitor, and I have some Listboxs on the main screen.
When I flick the 'Listbox' it scrolls fine, but when it gets to the end of the list, the entire application gets pulled down from the top of the screen, can I stop this behavior somehow?
Has anyone else seen this?
Yes, that default behaviour of the ListBox (or rather, the ScrollViewer inside the default ListBox template) is weird - when I first came across it, I thought it must be a practical joke. In fact, it's really hard to find any documentation about it - but it is briefly mentioned here:
The ManipulationBoundaryFeedback event enables applications or components to provide visual feedback when an object hits a boundary. For example, the Window class handles the ManipulationBoundaryFeedback event to cause the window to slightly move when its edge is encountered.
So, a way around it is to handle ManipulationBoundaryFeedback on the ListBox, and set Handled to true:
<ListBox ManipulationBoundaryFeedback="OnManipulationBoundaryFeedback">
// ...
</ListBox>
Code-behind:
private void OnManipulationBoundaryFeedback(object sender, ManipulationBoundaryFeedbackEventArgs e)
{
e.Handled = true;
}