Hi team
Here’s a collection of various aspects I’d find helpful to be improved for the Object Repository. Happy to hear your thoughts (and potential additions)!
Filtering and Sortation
Would be phenomenal to be able to better filter or sort objects, such as:
- Search only within current screen (or application)
[I reckon there’s going to be a few users searching for their elements in vain, as they have set their search focus on just a specific screen…] - Sort elements alphabetically (current), sort by Element Type (then alphabetically)
- Filter by element type
Mass-Update of a Window-Selector
Currently, if you’re adding various elements to a screen, you’ve got to edit the window selector manually. However, all child-elements (or a specific multi-selection of elements) would require the same window selector. A “mass-update” functionality for the screen or a selection of elements would be fantastic. I had built my own .xaml to loop through all elements in the .objects folder and search/replace specific window selectors to get to the desired solution.
Edit “Window Selector” within “Capture Elements”/Recorder
Also helpful for single elements would be to adjust the Window Selector directly when capturing new elements (and not as mentioned above, afterwards via Edit Descriptor - or via the “UI Explorer”).
Capture Elements and UI Explorer
If you use the above-mentioned “Capture Elements” (recording functionality) and access the UI Explorer to configure a selector further, it’ll disable the “Save & Continue” button that is usually displayed when you capture elements (and move on to select/capture the next element). However, when using the “UI Explorer” you’ll have to click on “Start recording” button again to be able to “Save & Continue”.
Undo Changes (esp. Delete)
Is there a possibility to implement “undo” changes in the OR? Especially “delete” - although there’s a warning displayed - is extremely powerful.
Copy Elements
The “Copy” and “Copy Tree” options are fairly confusing; perhaps some people use those. What’s also very intuitive for users is to select multiple items (2 or more) and wanting to copy/paste those.
Warn about Duplicate Names
I’m a great fan of the “Element already Exists” hint. It’d be great to also get a warning (and option to create element nonetheless) if the same name already exists within the same screen. Now it goes unnoticed and simply a (2) is added. It’d be great to suggest to work i.e. with “ElementName_Info” (i.e. “Surname_Search” and “Surname_Result” if the field/label exists multiple times on the same screen).
This could also be a great “Analyzer Rule” as you’ll see below.
Do not adjust “focus” onto the Parent Screen after editing the Descriptor of an Element
It appears to be fixed now, but in former versions (i.e. 23.10.*) the focus in the OR jumped to the parent-screen of an object when you edited the descriptor of an element. It would often end up in multi-selections - and the only option in the context menu (right-click) for multi-selections is “Delete”. This “focus” on parent-screen was also annoying as in larger screens (where the amount of elements would span more than 1 page, you’d continuously need to scroll back to where you were - and more elements in the OR tears down performance).
Workflow Analyzer Rules for OR
Certain rules and patterns might need to be in place for the Object Repository. It would be great to have rules checking how the elements (or screens / window selectors) are configured. I’ve written pipeline scripts to warn/throw errors if idx-elements are used or certain patterns do not match in the window selector, but having a specific set of Workflow Analyzer Rules would be extremely helpful!
(Also should not tolerate i.e. duplicate names in same screen with (n) suffix as mentioned above.)
.objects Folder Improvements
Is there a way - possibliy optional for more advanced users - to adjust the “cryptic” .objects folder? Allow us to set unique IDs of Applications, Screens and Elements, but that make it much easier to navigate through the folder. This is for various reasons:
- Either because we manually want to check an element in the folder path itself
- It allows for simplified validations and analyzer rules
- It allows for improved reviews (git collabs, which are close to impossible currently)
Happy to hear your thoughts and additions!
Cheers
Roman
