Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 293025 - [Dialogs] Need a public method to set return code of Dialog
Summary: [Dialogs] Need a public method to set return code of Dialog
Status: RESOLVED INVALID
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.6   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 3.6 M4   Edit
Assignee: Susan McCourt CLA
QA Contact: Susan McCourt CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 94153
  Show dependency tree
 
Reported: 2009-10-22 08:28 EDT by Prakash Rangaraj CLA
Modified: 2009-11-24 21:24 EST (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Prakash Rangaraj CLA 2009-10-22 08:28:16 EDT 
Right now we can set the return code from outside of the Dialog class. We need a way to do that for Bug# 94153
Comment 1 Remy Suen CLA 2009-10-22 09:39:48 EDT 
Changing setReturnCode(int) to public should be binary compatible but would cause problems with source compatibility I believe. I'm not personally gung-ho about this and would prefer if reflection was used in the handler myself.
Comment 2 Paul Webster CLA 2009-10-22 09:52:57 EDT 
Well, we would have to make sure that we follow our API evolution rules.

PW
Comment 3 Susan McCourt CLA 2009-10-22 20:16:11 EDT 
(In reply to comment #1)
> Changing setReturnCode(int) to public should be binary compatible but would
> cause problems with source compatibility I believe. I'm not personally gung-ho
> about this and would prefer if reflection was used in the handler myself.

I don't think I understand how this affects source compatibility if the visibility is increasing.  

On the other hand, if we don't think it's appropriate/necessary to add API for this particular use case, reflection seems like a good alternative.  And I know that we use reflection already in handlers (for things like select all).
Comment 4 Remy Suen CLA 2009-10-22 20:26:28 EDT 
(In reply to comment #3)
> I don't think I understand how this affects source compatibility if the
> visibility is increasing.

I use 3.5 and extend Window and write...

protected void setReturnCode(int i) {
    super.setReturnCode(i);
}

...then next year I download 3.6 where setReturnCode(int) has been changed to 'public', I will get a compiler error now because my "version" of the method is 'protected' and it has _reduced_ the visibility of the overridden method in question.
Comment 5 Susan McCourt CLA 2009-10-22 20:36:28 EDT 
good example.  My brain is really full right now and I couldn't come up with it.
Comment 6 Prakash Rangaraj CLA 2009-11-09 03:41:03 EST 
See: Bug# 94153 comment# 14 This request is no longer needed.
Comment 7 Susan McCourt CLA 2009-11-24 21:24:05 EST 
closing per comment 6