Community
Participate
Working Groups
In some cases there are ID conflicts between trees or other containers because of the properties used to identify the tree data item. Example: selecting a project when a test launch configuration is selected I need to further investigate to see if this should be resolved during playback (e.g. by returning all matches) or leave it up to the user to do the proper widget registration.
Created attachment 44862 [details] patch Needs to be more extensively tested.
The fix for this was merged with the series of other fixes that will be going in. The code will be checked in when 4.3 opens (July 10th).
Fix checked into CVS. Changes were restricted to a technology preview item.
ACTION: Please verify/close this defect.
Reporter: Please verify and close in preparation for shutting down the TPTP 4.4 release. Thanks.
Verified.
Closing.
This bug has to be reopened, as it is not a valid solution. Consider the build.properties editor as an example. If checking an item of the SourceBuild-Tree (of the Build page) during recording, the respectively named item in the BinaryBuild-Tree is selected during playback, as the command is played for the first match only. Playing it for all matches would also not be legal, as this would check both items during playback, even if only one was be checked during recording. A legal workaround would in my eyes be to ensure that ids are unique. This could be achieved by detecting dersolving unambiguities already during resolving (i.e. while recording) and by making the ids unique in such a case (e.g. by introducing an index to denote the proper match). The patch/revision of AGR uploaded to bug #133099 addresses this issue by reporting an unambiguity to the user during playback, so he can report the problem.
(In reply to comment #8) > This bug has to be reopened, as it is not a valid solution. Consider the > build.properties editor as an example. If checking an item of the > SourceBuild-Tree (of the Build page) during recording, the respectively named > item in the BinaryBuild-Tree is selected during playback, as the command is > played for the first match only. Playing it for all matches would also not be > legal, as this would check both items during playback, even if only one was be > checked during recording. > > A legal workaround would in my eyes be to ensure that ids are unique. This > could be achieved by detecting dersolving unambiguities already during > resolving (i.e. while recording) and by making the ids unique in such a case > (e.g. by introducing an index to denote the proper match). > > The patch/revision of AGR uploaded to bug #133099 addresses this issue by > reporting an unambiguity to the user during playback, so he can report the > problem. > As Alexander states, this defect has not been fixed in the current code. However, since the AGR was moved from a Technology Preview component to an As-Is component in TPTP 4.5 and As-Is components are primarily provided for prior users but imply no support (for example, defects, news group, and mailing lists) or commitment to triage or resolve opened defects, reopening and changing the resolution to WONTFIX. For this defect to be considered, please re-open with an attached patch including code to resolve the symptom and test cases to test the fix.
