Community
Participate
Working Groups
We would like to understand the reason for referencing this class so either a) we introduce a simple implementation in 4.1 for the tests to compile or b) PDE changes their code so it compiles cleanly against 4.1.
Ok, this is part of the macro support, which is a tool for recording UI actions that was added to PDE in the very beginning. I don't know anyone who has ever used it and there are no open bugs involving it. In the code we have a IWorkbenchPart. We are trying to create a unique path that describes how to get to a specific control (getting a composite's children, counting which child the control is, recursively work for any nested composites). Is there an alternate way that we can get to the main composite of the workbench part? Arguably we could just remove the macro support altogether, or move it to the incubator.
Created attachment 190268 [details] MacroUtil patch v1 (In reply to comment #1) > Is there an alternate way that we can get to the main composite of the > workbench part? I don't think we'll ever expose this kind of method publicly as an API but we did add similar code elsewhere to get PDE itself to compile on 4.x (due to it having similar references in its code for the Plug-in Spy to function). The attached patch will use that code path instead for retrieving the same information.
(In reply to comment #2) > I don't think we'll ever expose this kind of method publicly as an API but we > did add similar code elsewhere to get PDE itself to compile on 4.x (due to it > having similar references in its code for the Plug-in Spy to function). This is certainly not something we would expect to see in API. If the patch uses a different code path and will play nice with 4.1, that is perfect.
Fixed in HEAD.
