Enhancements / new element context menu#41
Conversation
Avoid non-obvious ui patterns
Pattern Actions, Focus, and Click support
New VM to keep the clutter out of the mainvm.
8a90953 to
5f5fd50
Compare
b706d20 to
07d7597
Compare
Hi @mitchcapper I had some similar thoughts. I am not sure about Pattern Actions. I need to investigate how it could implemented. P.S. I published a new version 3.0.0. |
|
I use this and a few other features I added pretty heavily so I doubt I'll be switching back to main any time soon. I'll wait to hear on this though. |
|
@mitchcapper can you please create an Idea (https://github.com/FlaUI/FlaUInspect/discussions/categories/ideas) for your needs with description and design? |
8a0c19d to
07d7597
Compare
|
@dualbios I went ahead and created ideas for most of the items I think I have in here. Liked a lot of the 3.0 changes I saw in briefly looking at it, happy to see things becoming easier to maintain/more modular. Some of the code looked like it may have been inspired by some of my changes or at least we went down some exceptionally similar paths and with TreeViewBringIntoViewBehavior looks like you are planning some sort of auto selection/nav search. |
@mitchcapper thanks! I am going to proceed. |
|
Hello, in new version, how do I copy the xpath text? I cannot select it to copy it, is there another way? |
Looks like it is a bug. |

Each commit here is self contained but was easier than trying to do each as a separate PR. Most of the commits should be pretty self evident the biggest is the new context menu on elements to allow for a bit quicker actions:
There is some clunkyness around an ugly behavior with the TreeView where when we programmatically set the selected item through IsSelected it scrolls to the top by default. Scrollintoview works but puts it at the bottom. Right now I center it for known going to jump (we trigger the isselected change). Forcing the selected item is required due to how the patterns are currently generated (only for the selected item so if you right clicked it might not apply as it was based on the selected element not the right clicked one). This could be all avoided if we moved the pattern generation into the ElementViewModel instead and just bound to SelectedItem.Patterns that for the main window pane. Doing this would prevent the clunky workaround for getting the proper datacontext of the parent in the contextmenu (as they have a separate visual root from the entire window).
Let me know if there are any questions/changes/etc.