Community
Participate
Working Groups
User-defined dialog classes based on the Window class often need to accumulate data based on user-input, which is typically requested after a successful Window.open(). Although Window.open() returns the closing result, there exists no common interface for related user-data from the dialog and each and every dialog has to document non-generic getter methods to request these results (e.g. InputDialog has a "getValue" method). I propose to add a generic meta-data interface to either org.eclipse.jface.window.Window or org.eclipse.jface.dialogs.Dialog. Interestingly there already exists a similar interface in org.eclipse.swt.widgets.Widget: public Object getData (String key); public void setData (String key, Object value); which fulfills the above mentioned requirements. Because this interface is well-known to every SWT programmer, it would be natural to expect a similar one in the jface Window/Dialog classes. I would like to mention that this request was inspired by a current newsgroup thread eclipse.platform.swt, 2006-09-30 17:14 by Ali Naddaf: "How to get control values from a dialog?" Especially Tom Schindl's answer to that question lead to this proposal.
Created attachment 51621 [details] Patch to add set/getData
Since the SWT user data fulfills your requirements, can you not just attach your dialog data to the widget data of the underlying widget?
(In reply to comment #2) AFAIK, there exist no public accessor for "the" underlying widget available in one of the base classes (Window or Dialog). I don't think that the shell is appropriate, because it is not owned by the dialog. The only option I see is the public available member buttonBar. But this is also problematic, because according to its docs "[..] null until dialog is layed out.". This is bad, because the typical use case is: 1) Create some dialog. 2) Feed the dialog with input data. At this point the "setter" activity of the proposed getData interface would be used. But buttunBar is null at this point. 3) Open the dialog. 4) Close the dialog and read data. That is, after close has been called, the data needs to be available.
This message is part of a mass update...the bug is likely legitimate, but not a priority. Marking P5. Patches would be entertained.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
