Ticket #1167 (closed defect: fixed)
Opened 2012-05-11T11:48:54-05:00
Last modified 2013-04-12T15:55:10-05:00
New Image fails to appear
| Reported by: | gharris | Owned by: | curtis |
|---|---|---|---|
| Priority: | critical | Milestone: |
|
| Component: | Display API | Version: | |
| Severity: | critical | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description
Looks as thought the AbstractImageDisplayViewer.view(...), where the event subscription occurs, is not called before the DisplayCreatedEvent is published. (I'm using Windows.)
Change History
comment:1 Changed 2012-05-11T12:37:15-05:00 by curtis
- Status changed from new to assigned
- Severity changed from serious to critical
- Component changed from other to ij-display
- Priority changed from major to critical
- Milestone set to imagej-2.0.0-beta2
- Owner set to curtis
comment:3 Changed 2012-05-17T13:34:07-05:00 by curtis
I believe this is fixed with the recent display fixes, particularly f307e6373b861f679f046ffbc2a8d37caccad718.
comment:4 Changed 2012-05-17T13:34:11-05:00 by curtis
- Status changed from accepted to closed
- Resolution set to fixed
Yep, there are still some problems with the headless display refactoring. I am working on it on the fix-displays branch, which I hope to at least partially merge today, though not before I better understand certain mysterious behavior.
Intuitively, I do think DisplayCreatedEvent should be published first, and then the display viewer logic should pick up that event and create the DisplayViewer accordingly (which calls the view method). So the order of operations there isn't necessarily wrong... but there is definitely something funny about the chain of events somewhere.