Community
Participate
Working Groups
From experience, indexing context menu items and toolbar items has proved to be an ineffective way of resolving these items. Find a better approach to resolve them.
Downgrading this to a defect. The policy currently employed is proving to be a nuisance. The indices of menu items constantly change and cause macro breakage. We will need to support the current and the new policy. Keep the following in mind: 1) Users should have the ability to specify a unique ID for a menu/toolbar item just like how a unique ID can be specified for widgets. 2) Use a default set of (property, weight) pairs if a user entry can't be found. Example of properties: 1) Index with variance of 2 (extrinsic property) 2) The presence of an item relative to other items (extrinsic property) 3) The implemented class (intrinsic property) 4) Keyboard shortcut (intrinsic property) 5) Associated icon (extrinsic property)
You didn't mention using the "name" property in the menu. Is that something you can't see? That seems like the most obvious thing to use - it's what users go by - though of course such a test only works in one locale. Ideally, you could go by the message property file tag that leads to the name: that would give you locale independence. Maybe after recording you could consult the appropriate plugin's property file and do a reverse lookup from the menu item's name to its tag, and store the tag in the script. Then on playback you could look up the tag in the message file and match the string you find against the menu items' names. Also, using the menu item's name makes the test script more human-readable.
Thanks for your input Allan. I purposely left out the message property because of the locale dependency issue. I have tried not to use any properties that would make the macro locale dependent. Mostly because of feature https://bugs.eclipse.org/bugs/show_bug.cgi?id=110108 which will require a macro to run under different translations. I don't think the user experience will be that well if the tool prompted the user for the properties files for a specific label. I already have this feature open for making a macro more human-readable: https://bugs.eclipse.org/bugs/show_bug.cgi?id=111018
Try this: instead of ignoring the name of the menu item on playback, use it as a "hint." If *any* item in the menu matches the text of the label you saw during record, then that's your winner. If *none* of them matches, then use the other (less-reliable) attributes you recorded. This way, a playback in the same locale as the recording will be highly reliable, and a playback in another locale (or if the label changes) is still possible. (This advice applies only if the label is more reliable in the original locale than your alternatives. Right now you know it's more reliable than the index.) Regarding message property tags: I don't propose prompting the user for them. Rather, you can grovel in the plugin's message properties file yourself and find them, like this: During record: 1. Get the label from the UI. 2. Look in the plug-in's properties file for a string that matches. 3. Save the tag for that entry as a property in the recorded script. During playback: 4. Look in the plug-in's locale-appropriate properties file for the tag. 5. Get the string that corresponds to that tag. 6. Match the string against the item names in the menu. 7. If you find a match, that's your winner. Here's an example. During a recording session in English, let's say the string in the menu the user hit is "Convert." You look in the current locale's properties file to find that string and pull its tag; let's say the tag is "CONVERT_ITEM_LABEL." Now there's a playback in the French locale. You should look in the now-current properties file (French) for the CONVERT_ITEM_LABEL tag. The string you find will be "Convertir" or something. So your menu item is the one whose label is "Convertir." This is a fuzzy algorithm. The first fuzzy part is finding the properties file. Each each plug-in is free to use any system for internationalization, but there are only a couple of systems in actual use, mostly based on OSGI bundles. In the case of menu items, most of these come from plugin.xml files where the system of turning tags into locale-specific strings is rigid and well-known. The second fuzzy part is matching "Convert" to CONVERT_ITEM_LABEL during record: if there is more than one entry in the properties file whose text is "Convert," you don't know which to use. You can give up on this trick at that point, or you can store them all and check each of them for a match at run time. Either they'll all translate to the same word (so it doesn't matter which one(s) you use), or they will translate differently but only one will match the menu you're seeing during playback. The third fuzzy part is that there might not be a properties file you can find, or it might not have any entry whose text matches the menu item. In that case you're only as bad off as you were before. The unhappy case is when you find a matching string in the properties file, save its tag, and look it up at run time, only to find that the program wasn't using the properties file for that string, so no menu item matches the text you fond. The WORST case is when ANOTHER menu item, a WRONG menu item, matches the string for the (wrong) tag you found. I think this is unlikely, and the probability of this failure is small enough that the trick is a net win overall. If you can find the properties files.
I think you're right about the added reliability if there is a label for me to use. I will use the label with a high weight. If the label of a menu item equals to that of the one recorded, then that menu item will be selected. Otherwise other attributes have to be true in order for me to classify an item as a match. I'm still going to stay away from properties files (i.e. the added reliability will be present when the macro is run in the same locale that it was recorded in) Thanks again for your useful comments.
No considered for 4.2, Version=future
Sorry, forget about the previous change and comment. (Version back to = 4.2)
Created attachment 31578 [details] Patch Patch. I will check this in when the stream officially opens in Jan 2006.
Patch checked into head
ACTION: Please verify/close this defect.
Closing by default since not closed by the originator in the 7+ months since being resolved. Please reopen if the issue is still present in the latest TPTP release or the resolution is not correct.
