View Issue Details

IDProjectCategoryView StatusLast Update
0001984NoesisGUIUnity3Dpublic2021-05-04 02:40
ReporterKeldorKatarnAssigned Tosfernandez 
PrioritynormalSeveritymajorReproducibilityalways
Status assignedResolutionopen 
Product Version3.0.11 
Target Version3.0.13Fixed in Version 
Summary0001984: MouseButtonEventArgs Source Property incorrect value
DescriptionThe MouseButtonEventArgs.Source property returns the wrong value. It returns what should be OriginalSource.
This is inconsistent with WPF and prevent implementing a lot of important logic.
TagsNo tags attached.
PlatformAny

Relationships

related to 0001981 assignedsfernandez KeyEventArgs is missing the OriginalSource property 

Activities

sfernandez

sfernandez

2021-04-27 21:01

manager   ~0007172

Could you please point out an scenario where you need to use the Source property instead of the OriginalSource?
Wouldn't the sender of the event be an option in those situations? WPF UIElement by default sets Source to be the sender.

Anyway, as you pointed out the meaning is not the same as in WPF, we should probably change this.
KeldorKatarn

KeldorKatarn

2021-04-27 21:48

reporter   ~0007174

Last edited: 2021-04-27 21:49

View 2 revisions

Imagine this layout:

    <DockPanel xmlns:b="http://schemas.microsoft.com/xaml/behaviors"
               xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
               xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
               Background="Transparent">
        <Menu Height="50" Background="Red" VerticalAlignment="Top" DockPanel.Dock="Top" />
        <ToolBar Height="50" Background="Blue" VerticalAlignment="Top" DockPanel.Dock="Top" />
        <b:Interaction.Behaviors>
            <!-- <behaviors:RemoveFocusBehavior /> -->
        </b:Interaction.Behaviors>
    </DockPanel>

The behavior does this:

        protected override void OnAttached()
        {
            base.OnAttached();
            
            AssociatedObject.PreviewMouseDown += OnPreviewMouseDown;
        }

        private void OnPreviewMouseDown(object sender, MouseButtonEventArgs args)
        {
            if (ReferenceEquals(args.Source, AssociatedObject))
            {
                Keyboard.ClearFocus();
            }
        }

If I click on the Menu, then args.Source will be Menu, if I click on the Toolbar, the args.Source will be Toolbar. if I click into the empty space, the args.Source will be DockPanel
However the sender will ALWAYS be DockPanel, since that's where the event handler attached.

Right now Noesis is putting Border or some other hit visual element in the Source property. That should be OriginalSource to detect the visual element that caused the event to be created.
But the logical control is supposed to be in Source.

Without this being correct, I can in this example not detect if I clicked any of the DockPanel's child elements or the DockPanel iteself where no child elements exist.

sfernandez

sfernandez

2021-04-29 12:20

manager   ~0007190

I see your point here.

>> Without this being correct, I can in this example not detect if I clicked any of the DockPanel's child elements or the DockPanel iteself where no child elements exist.
In this particular case you could check our Source (equivalent to WPF's OriginalSource) to determine if you clicked in the DockPanel, because the Source will be DockPanel unless you click in any child of that panel, right?
KeldorKatarn

KeldorKatarn

2021-04-29 19:57

reporter   ~0007196

Yes but I also had the case where I filled the remaining space with another child. So then it doesn't work anymore since I need to detect the specific child.
As I said I'm not sure if this usecase will even remain in my code. But it let me detect this problem and it's a massive inconsistency with WPF.
Considering how often I've used this property and Original source in my time as WPF developer, especially in Behaviors and special event logic, I think I can
say that those two properties are very powerful to implement certain logic and need to work as they do in WPF:
This is just one example for such a logic.
That's why I think it's important to make sure these work identically to WPF.
KeldorKatarn

KeldorKatarn

2021-04-30 08:22

reporter   ~0007198

I have another example for you regarding Source and OriginalSource.

Consider this situation:

        public FileDialogView()
        {
            InitializeComponent();
            Initialized += OnInitialized;
        }

        private void OnInitialized(object sender, EventArgs args)
        {
            var treeView = (TreeView)FindName("TreeView");
            treeView.AddHandler(TreeViewItem.SelectedEvent, new RoutedEventHandler(OnTreeViewItemSelected));
        }

        private void OnTreeViewItemSelected(object sender, RoutedEventArgs e)
        {
            Debug.Log($"sender: {sender}, e.Source: {e.Source}");
#if !NOESIS
            (e.OriginalSource as TreeViewItem)?.BringIntoView();
#endif
        }

In WPF e.Source is the TreeView and e.OriginalSource is the TreeViewItem

In Noesis e.Source is the TreeViewItem

That is inconsistent and breaks code between Blend and Noesis

Issue History

Date Modified Username Field Change
2021-04-27 01:23 KeldorKatarn New Issue
2021-04-27 17:13 KeldorKatarn Relationship added related to 0001981
2021-04-27 21:01 sfernandez Assigned To => sfernandez
2021-04-27 21:01 sfernandez Status new => feedback
2021-04-27 21:01 sfernandez Note Added: 0007172
2021-04-27 21:48 KeldorKatarn Note Added: 0007174
2021-04-27 21:48 KeldorKatarn Status feedback => assigned
2021-04-27 21:49 KeldorKatarn Note Edited: 0007174 View Revisions
2021-04-28 11:14 jsantos Target Version => 3.0.12
2021-04-29 12:20 sfernandez Status assigned => feedback
2021-04-29 12:20 sfernandez Note Added: 0007190
2021-04-29 19:57 KeldorKatarn Note Added: 0007196
2021-04-29 19:57 KeldorKatarn Status feedback => assigned
2021-04-30 08:22 KeldorKatarn Note Added: 0007198
2021-05-04 02:40 jsantos Target Version 3.0.12 => 3.0.13