| AGR incorrectly records non-UI (programmatic) action and playback fails [message #62558] | 
Thu, 30 March 2006 04:17   | 
 
Eclipse User  | 
 | 
 | 
   | 
 
I have a problem with AGR recording. I recorded a simple test case with  
our custom plugin. In the test case I create a new project, which also  
opens an editor, and afterwards I delete the project from the eclipse  
navigator and check "also delete contents in filesystem". The delete  
operation automatically closes the open editor. In the generated macro,  
I see the following near the end: 
 
       <shell  
id=" org.eclipse.ui.internal.progress.ProgressMonitorFocusJobDial og "  
return-code="0"> 
          <command type="close-workbenchpart" contextId="editor"  
widgetId="com.esim.eclipse.rapid.ui.UDOEditor/aaa.RXD"/> 
          <command type="wait"/> 
       </shell> 
       <command type="wait"/> 
 
This looks like the close action of our custom editor. However it should  
not be reocrded since it is closed programmatically and not as response  
to a user action. Also during playback AGR can't execute the action and  
reports timeout after a while. 
I tried recording a similar test case using the JDT, where I create a  
java project, new class and delete the project (which also closes the  
class editor) and in this case AGR does not record the close action.  
Both our plugin and JDT seem to use the same method to close the editor  
(WorkbenchPart.closeEditor). 
Before I investigate deeper, does anyone know if this is a known bug and  
if there is a workaround (one workaround is to close the editor manually  
before deleting the project). 
I am using AGR and TPTP from 02281515. We made some modifications to the  
AGR (mainly added a custom launcher needed by our plugin) but nothing  
related to the recording/playback that I know of. 
 
Thanks, 
Lior
 |  
 |  
  | 
| Re: AGR incorrectly records non-UI (programmatic) action and playback fails [message #63266 is a reply to message #62558] | 
Sat, 01 April 2006 11:28   | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Hi Lior, 
 
Yes, this is already a known issue.  I have opened defect 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=110810 to resolve it.  The 
only workaround is to modify the macro or have the editor closed before 
deleting the project. 
 
 
"Lior David" <lior@e-sim.com> wrote in message 
news:e0g7su$lqa$1@utils.eclipse.org... 
> I have a problem with AGR recording. I recorded a simple test case with 
> our custom plugin. In the test case I create a new project, which also 
> opens an editor, and afterwards I delete the project from the eclipse 
> navigator and check "also delete contents in filesystem". The delete 
> operation automatically closes the open editor. In the generated macro, 
> I see the following near the end: 
> 
>        <shell 
> id=" org.eclipse.ui.internal.progress.ProgressMonitorFocusJobDial og " 
> return-code="0"> 
>           <command type="close-workbenchpart" contextId="editor" 
> widgetId="com.esim.eclipse.rapid.ui.UDOEditor/aaa.RXD"/> 
>           <command type="wait"/> 
>        </shell> 
>        <command type="wait"/> 
> 
> This looks like the close action of our custom editor. However it should 
> not be reocrded since it is closed programmatically and not as response 
> to a user action. Also during playback AGR can't execute the action and 
> reports timeout after a while. 
> I tried recording a similar test case using the JDT, where I create a 
> java project, new class and delete the project (which also closes the 
> class editor) and in this case AGR does not record the close action. 
> Both our plugin and JDT seem to use the same method to close the editor 
> (WorkbenchPart.closeEditor). 
> Before I investigate deeper, does anyone know if this is a known bug and 
> if there is a workaround (one workaround is to close the editor manually 
> before deleting the project). 
> I am using AGR and TPTP from 02281515. We made some modifications to the 
> AGR (mainly added a custom launcher needed by our plugin) but nothing 
> related to the recording/playback that I know of. 
> 
> Thanks, 
> Lior
 |  
 |  
  | 
Powered by 
FUDForum. Page generated in 0.03365 seconds