Opened 4 years ago

Closed 4 years ago

#799 closed defect (fixed)

GritsUIService: Exception opening the part after long running process

Reported by: sena Owned by: sena
Priority: normal Milestone: GRITS - 1.2
Component: GRITS core Version: GRITS 1.1.x
Severity: minor Keywords:


While running the gelato annotation I am getting the attached exception ("Application does not have an active window") if I leave the GRITS window and switch to another application (firefox, powerpoint etc.) and stay on the other application by the time the process finishes. Since the annotation process takes a while, this would be a common scenario.

The exception is not thrown if I wait for the process to finish with the focus on GRITS window.

This causes the newly created entry not being opened. But the user needs to double-click again to open it in the editor.

Attachments (1)

Exception.txt (8.6 KB) - added by sena 4 years ago.

Download all attachments as: .zip

Change History (4)

Changed 4 years ago by sena

Attachment: Exception.txt added

comment:1 Changed 4 years ago by shan

Owner: changed from shan to sena
Status: newassigned
  • One of the first type of errors that I warned against for adding GritsUIService. It is the eclipse framework that uses contexts based on a UI framework and to use their services you cannot violate their UI assumptions.
  • This error occurs when Grits UI Service calls Eclipse Part Service which internally invokes methods that expect an active window for finding a Part.
    • Even if there is an alternative to partService.findPart(..) still partService.showPart(..) is needed which again invokes methods that requires an active window.

In short Eclipse would use an active window in many of its UI Services and you have to comply with that.

Solution Summary

  • When you expect a process to be running for long duration and user minimizing it then check and wait till there is an active window available before opening the entry.

This could also be incorporated in the Grits UI Service but for a standard behavior one has to add this kind of checking and waiting in lots of places and it would be a waste of effort and resources.

comment:2 Changed 4 years ago by sena

Resolution: fixed
Status: assignedreview

I have fixed this bug for now by adding a method in GritsUIService to set the partService from the command handler instead of using the initially injected EPartService of GritsUIService before trying to open the part.

This might be related to the following bug in eclipse:

Also see

Handler's execute method has "EPartService" as an injected parameter and makes the following calls to open the part in the editor after the long running process:


comment:3 Changed 4 years ago by Rene Ranzinger

Status: reviewclosed
Note: See TracTickets for help on using tickets.