springframework-rcp-dev — Spring Rich Client developer list

[Springframework-rcp-dev] [Spring-JIRA] Resolved: (RCP-452) The no-arg constructor in ShowViewCommand should be removed

[Kevin S. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Stembridge resolved RCP-452.
----------------------------------

    Resolution: Won't Fix

> The no-arg constructor in ShowViewCommand should be removed
> -----------------------------------------------------------
>
>                 Key: RCP-452
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-452
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Command System
>    Affects Versions: 0.2.1
>         Environment: All
>            Reporter: Kevin Stembridge
>            Assignee: Kevin Stembridge
>            Priority: Trivial
>             Fix For: 0.3.0
>
>
> This is a change that was first raised on the dev mailing list but I'm also logging it as a JIRA issue because it is a backwards-incompatible change. 
> ShowViewCommand has the following two constructors, and I've also included the setViewDescriptor method:
>    public ShowViewCommand() {
>        super("showViewCommand");
>        setEnabled(true);
>    }
>    public ShowViewCommand(ViewDescriptor viewDescriptor, ApplicationWindow window) {
>        this();
>        setViewDescriptor(viewDescriptor);
>        setApplicationWindow(window);
>        setEnabled(true);
>    }
>    public final void setViewDescriptor(ViewDescriptor viewDescriptor) {
>        Assert.required(viewDescriptor, "viewDescriptor");
>        setId(viewDescriptor.getId());
>        setLabel(viewDescriptor.getShowViewCommandLabel());
>        setIcon(viewDescriptor.getIcon());
>        setCaption(viewDescriptor.getCaption());
>        this.viewDescriptor = viewDescriptor;
>    }
> I think the no-args constructor should be removed for the following reasons:
> * viewDescriptor is a required property, which is only enforced by the second constructor. We could override afterPropertiesSet to check for a non-null view descriptor but this  is a brittle approach because instances of this class are not created by the Spring IoC container.
> * The "showViewCommand" ID set by the no-args constructor will always be overridden when setViewDescriptor is eventually called.
> * The no-args constructor is never called by any RCP code anyway (apart from within the second constructor).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-221) Shadowed logger

[Yudhi W. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yudhi Widyatama updated RCP-221:
--------------------------------

    Attachment: RCP-221.patch

Won't simply remove the field in the subclass solves this issue? Its already declared protected in the superclass. (Unless we want to allow another subclass to replace the logger..)

> Shadowed logger
> ---------------
>
>                 Key: RCP-221
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-221
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>            Reporter: Geoffrey De Smet
>            Assignee: Oliver Hutchison
>            Priority: Trivial
>         Attachments: RCP-221.patch
>
>
> The logger in AbstractControlFactory  shadows the one in ApplicationServicesAccessor:
> public abstract class AbstractControlFactory extends ApplicationServicesAccessor implements ControlFactory {
>     protected Log logger = LogFactory.getLog(getClass());
>     //...
> }
> public class ApplicationServicesAccessor {
>     protected final Log logger = LogFactory.getLog(getClass());
>     //...
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-408) MessageDialog's ok button should be the default button (enter key should press it)

[Yudhi W. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yudhi Widyatama updated RCP-408:
--------------------------------

    Attachment: RCP-408.patch

makes the messagearea in AlertMessageAreaPane unfocusable. I think this solves RCP-408.

> MessageDialog's ok button should be the default button (enter key should press it)
> ----------------------------------------------------------------------------------
>
>                 Key: RCP-408
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-408
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Dialog System
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 0.3.0
>
>         Attachments: RCP-408.patch
>
>
> Now it's not the default button, so when a login succeeds, you have to press escape (instead of enter) to press it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-408) MessageDialog's ok button should be the default button (enter key should press it)

[Yudhi W. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25056 ] 

Yudhi Widyatama commented on RCP-408:
-------------------------------------

It is strange that MessageDialog chooses to make the Cancel button the default button. Even when we don't do this (by commenting getCancelCommandId, getCommandGroupMembers, and registerDefaultCommand in MessageDialog.class) the enter button still does nothing when the dialog first popped up. I think its about the focus, I need to press tab several times before I could close the dialog using enter key.
So I tried to make the message area unfocusable. Added  messageArea.setFocusable(false) in AlertMessageArea.init(Messagable), and now we could press enter key to 'OK' a MessageDialog.

> MessageDialog's ok button should be the default button (enter key should press it)
> ----------------------------------------------------------------------------------
>
>                 Key: RCP-408
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-408
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Dialog System
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 0.3.0
>
>
> Now it's not the default button, so when a login succeeds, you have to press escape (instead of enter) to press it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-320) SplashScreen doesn't work if the application is loaded from a directory which conatins spaces "My documents"

[Yudhi W. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25055 ] 

Yudhi Widyatama commented on RCP-320:
-------------------------------------

This issue doesn't exist anymore.
My configuration has the project root at "C:\Documents and Settings\user\spring-richclient\samples\petclinic\gui", 
and the splash screen still shows up  even when I moved the image into path "C:\Documents and Settings\user\spring-richclient\samples\petclinic\gui\src\main\resources\a b\splash-screen.jpg" (and changed the path in richclient-startup-context.xml accordingly). This issue should be marked closed/fixed. 

> SplashScreen doesn't work if the application is loaded from a directory which conatins spaces "My documents"
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: RCP-320
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-320
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>    Affects Versions: 0.1.0
>         Environment: Windows
>            Reporter: Amit Shah
>            Priority: Trivial
>
> splashScreen doesn't work if the path contains a space. This is explained in more details in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4466485

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] Do it for pleasure

[Katelyn M. <kud...@am...>]

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-402) cannot start application without dependency on jgoodies - looks

[Jan H. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Hoskens closed RCP-402.
---------------------------

      Assignee: Jan Hoskens
    Resolution: Fixed

Looks like this is a duplicate of RCP-409 which has been fixed. JGoodies looks isn't required anymore, the code linking to that library has been removed.

If you disagree with this, please reopen the issue.

> cannot start application without dependency on jgoodies - looks
> ---------------------------------------------------------------
>
>                 Key: RCP-402
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-402
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>    Affects Versions: 0.2.0
>            Reporter: Ryan Sonnek
>            Assignee: Jan Hoskens
>
> Looks like core spring-rich code is depending on jgoodies looks code.  Please update the spring-rich POM to automatically include this dependency so that every application doesn't need to do this manually.
> Caused by: java.lang.NoClassDefFoundError: com/jgoodies/looks/LookUtils
>         at org.springframework.richclient.control.SimpleInternalFrame.getHeaderBackground(SimpleInternalFrame.java:379)
>         at org.springframework.richclient.control.SimpleInternalFrame.buildHeader(SimpleInternalFrame.java:303)
>         at org.springframework.richclient.control.SimpleInternalFrame.<init>(SimpleInternalFrame.java:152)
>         at org.springframework.richclient.application.support.DefaultPageComponentPane.createControl(DefaultPageComponentPane.java:55)
>         at org.springframework.richclient.factory.AbstractControlFactory.getControl(AbstractControlFactory.java:48)
>         at org.springframework.richclient.application.support.DefaultApplicationPage.giveFocusTo(DefaultApplicationPage.java:66)
>         at org.springframework.richclient.application.support.AbstractApplicationPage.addPageComponent(AbstractApplicationPage.java:304)
>         at org.springframework.richclient.application.support.AbstractApplicationPage.showView(AbstractApplicationPage.java:283)
>         at org.springframework.richclient.application.support.AbstractApplicationPage.showView(AbstractApplicationPage.java:275)
>         at org.springframework.richclient.application.support.DefaultApplicationPage.addView(DefaultApplicationPage.java:47)
>         at org.springframework.richclient.application.support.SingleViewPageDescriptor.buildInitialLayout(SingleViewPageDescriptor.java:60)
>         at org.springframework.richclient.application.support.DefaultApplicationPage.createControl(DefaultApplicationPage.java:76)
>         at org.springframework.richclient.factory.AbstractControlFactory.getControl(AbstractControlFactory.java:48)
>         at org.springframework.richclient.application.support.DefaultApplicationWindow.setActivePage(DefaultApplicationWindow.java:47)
>         at org.springframework.richclient.application.support.AbstractApplicationWindow.showPage(AbstractApplicationWindow.java:194)
>         at org.springframework.richclient.application.support.AbstractApplicationWindow.showPage(AbstractApplicationWindow.java:161)
>         at org.springframework.richclient.application.Application.openWindow(Application.java:148)
>         at org.springframework.richclient.application.Application.start(Application.java:210)
>         at org.springframework.richclient.application.ApplicationLauncher.launchMyRichClient(ApplicationLauncher.java:223)
>         at org.springframework.richclient.application.ApplicationLauncher.<init>(ApplicationLauncher.java:103)
>         at com.codecrate.shard.ui.ShardApplicationLauncher.<init>(ShardApplicationLauncher.java:10)
>         at com.codecrate.shard.ui.ShardMinotaur.main(ShardMinotaur.java:34)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] Don't waste time!

[Willard M. <lun...@ap...>]

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-402) cannot start application without dependency on jgoodies - looks

[Yudhi W. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25022 ] 

Yudhi Widyatama commented on RCP-402:
-------------------------------------

Having run petclinic-standalone sample without JGoodies Looks, I think this issue doesn't exist anymore. This issue should be marked as fixed/ closed.

> cannot start application without dependency on jgoodies - looks
> ---------------------------------------------------------------
>
>                 Key: RCP-402
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-402
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>    Affects Versions: 0.2.0
>            Reporter: Ryan Sonnek
>
> Looks like core spring-rich code is depending on jgoodies looks code.  Please update the spring-rich POM to automatically include this dependency so that every application doesn't need to do this manually.
> Caused by: java.lang.NoClassDefFoundError: com/jgoodies/looks/LookUtils
>         at org.springframework.richclient.control.SimpleInternalFrame.getHeaderBackground(SimpleInternalFrame.java:379)
>         at org.springframework.richclient.control.SimpleInternalFrame.buildHeader(SimpleInternalFrame.java:303)
>         at org.springframework.richclient.control.SimpleInternalFrame.<init>(SimpleInternalFrame.java:152)
>         at org.springframework.richclient.application.support.DefaultPageComponentPane.createControl(DefaultPageComponentPane.java:55)
>         at org.springframework.richclient.factory.AbstractControlFactory.getControl(AbstractControlFactory.java:48)
>         at org.springframework.richclient.application.support.DefaultApplicationPage.giveFocusTo(DefaultApplicationPage.java:66)
>         at org.springframework.richclient.application.support.AbstractApplicationPage.addPageComponent(AbstractApplicationPage.java:304)
>         at org.springframework.richclient.application.support.AbstractApplicationPage.showView(AbstractApplicationPage.java:283)
>         at org.springframework.richclient.application.support.AbstractApplicationPage.showView(AbstractApplicationPage.java:275)
>         at org.springframework.richclient.application.support.DefaultApplicationPage.addView(DefaultApplicationPage.java:47)
>         at org.springframework.richclient.application.support.SingleViewPageDescriptor.buildInitialLayout(SingleViewPageDescriptor.java:60)
>         at org.springframework.richclient.application.support.DefaultApplicationPage.createControl(DefaultApplicationPage.java:76)
>         at org.springframework.richclient.factory.AbstractControlFactory.getControl(AbstractControlFactory.java:48)
>         at org.springframework.richclient.application.support.DefaultApplicationWindow.setActivePage(DefaultApplicationWindow.java:47)
>         at org.springframework.richclient.application.support.AbstractApplicationWindow.showPage(AbstractApplicationWindow.java:194)
>         at org.springframework.richclient.application.support.AbstractApplicationWindow.showPage(AbstractApplicationWindow.java:161)
>         at org.springframework.richclient.application.Application.openWindow(Application.java:148)
>         at org.springframework.richclient.application.Application.start(Application.java:210)
>         at org.springframework.richclient.application.ApplicationLauncher.launchMyRichClient(ApplicationLauncher.java:223)
>         at org.springframework.richclient.application.ApplicationLauncher.<init>(ApplicationLauncher.java:103)
>         at com.codecrate.shard.ui.ShardApplicationLauncher.<init>(ShardApplicationLauncher.java:10)
>         at com.codecrate.shard.ui.ShardMinotaur.main(ShardMinotaur.java:34)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-438) Inline validation of Integer fields

[Yudhi W. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yudhi Widyatama updated RCP-438:
--------------------------------

    Attachment: RCP-438.patch

I think this issue is rooted on the fact that NumberFormat.parse(String) parses from the start of the String and doesn't throw any exception on partial parses (the number stopped before the end of the String). The method NumberFormat.parse(String,ParsePosition) must be used if we want to know whether the parse completed for the whole String. There is some possible solution to this, we could either modify org.springframework.util.NumberUtils.parse, or modify org.springframework.binding.format.support.NumberFormatter.doParseValue, or decorate the java.text.NumberFormat so it throws ParseException when encountering partial parses.
This patch proposes a solution using the last approach, by decorating a NumberFormat, creating a customized FormatterFactory extending SimpleFormatterFactory, and changing DefaultConversionServiceFactoryBean so it uses the customized factory as a default FormatterFactory.

> Inline validation of Integer fields
> -----------------------------------
>
>                 Key: RCP-438
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-438
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Binding System
>    Affects Versions: 0.2.1
>            Reporter: Danie Roux
>         Attachments: RCP-438.patch
>
>
> Validation does not execute after initial key-press. 
> For example: 
> Fails validation
> a9999  
> .09js
> Passes validation
> 9aaaa
> 1.2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-472) Implement ExclusiveCommandGroup.createComboBox()

[Rogan D. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25016 ] 

Rogan Dawes commented on RCP-472:
---------------------------------

any chance of getting this applied?

Or am I going about this the wrong way?


> Implement ExclusiveCommandGroup.createComboBox()
> ------------------------------------------------
>
>                 Key: RCP-472
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-472
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Command System
>    Affects Versions: 0.3.0
>         Environment: Any
>            Reporter: Rogan Dawes
>         Attachments: combobox.patch, combobox.patch
>
>
> An ExclusiveCommandGroup can manifest as a series of RadioButtons, or a single selection Menu. Another way to present this (in the minimum space) is to use a JComboBox. The attached patch implements this idea.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-480) VLDocking: Closing a Page throws an exception.

[Jan H. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Hoskens closed RCP-480.
---------------------------

      Assignee: Jan Hoskens
    Resolution: Cannot Reproduce

As stated in the comments, this issue was invalid, so closing the issue.

> VLDocking: Closing a Page throws an exception.
> ----------------------------------------------
>
>                 Key: RCP-480
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-480
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>            Assignee: Jan Hoskens
>
> Hi
> I've tried to run the sample for VLDocking and it seems to work fine until one tries to close a window, in which case, the following exception happens:
> java.lang.NoSuchMethodError: org.springframework.richclient.application.ApplicationPage.close(Lorg/springframework/richclient/application/PageComponent;)V
>         at org.springframework.richclient.application.vldocking.VLDockingApplicationPage$DockableListener.dockableStateChanged(VLDockingApplicationPage.java:270)
>         at com.vlsolutions.swing.docking.DockingContext.fireDockableStateChange(DockingContext.java:451)
>         at com.vlsolutions.swing.docking.DockingDesktop.fireDockingAction(DockingDesktop.java:3749)
>         at com.vlsolutions.swing.docking.DockingDesktop.close(DockingDesktop.java:2102)
>         at com.vlsolutions.swing.docking.DockTabbedPane$5.actionPerformed(DockTabbedPane.java:397)
>         at com.vlsolutions.swing.tabbedpane.SmartIconJButton.fireAction(SmartIconJButton.java:300)
>         at com.vlsolutions.swing.tabbedpane.JTabbedPaneSmartIcon.onMouseReleased(JTabbedPaneSmartIcon.java:387)
>         at com.vlsolutions.swing.tabbedpane.JTabbedPaneSmartIconManager.mouseReleased(JTabbedPaneSmartIconManager.java:138)
>         at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:232)
>         at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
>         at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
>         at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
>         at java.awt.Component.processMouseEvent(Component.java:5501)
>         at javax.swing.JComponent.processMouseEvent(JComponent.java:3135)
>         at java.awt.Component.processEvent(Component.java:5266)
>         at java.awt.Container.processEvent(Container.java:1966)
>         at java.awt.Component.dispatchEventImpl(Component.java:3968)
>         at java.awt.Container.dispatchEventImpl(Container.java:2024)
>         at java.awt.Component.dispatchEvent(Component.java:3803)
>         at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
>         at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
>         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
>         at java.awt.Container.dispatchEventImpl(Container.java:2010)
>         at java.awt.Window.dispatchEventImpl(Window.java:1778)
>         at java.awt.Component.dispatchEvent(Component.java:3803)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
>         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
>         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
>         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
>         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
>         at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
> It seems that the close(PageComponent pc) method does not exist on the PageComponent used for VLDocking.
> Thanks

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] Super pills for you and your wife

[Tony S. <ric...@ba...>]

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-14) org.springframework.richclient.table.ListTableModel is missing a call to init().

[Quinten V. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25001 ] 

Quinten Verheyen commented on RCP-14:
-------------------------------------

I am using 0.3.0-SNAPSHOT and encountered the same error, there is no init() call since there is no such method, so I guess some refactoring reintroduced this bug ?

> org.springframework.richclient.table.ListTableModel  is missing a call to init().
> ---------------------------------------------------------------------------------
>
>                 Key: RCP-14
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-14
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>            Reporter: Ville Peurala
>            Assignee: Peter De Bruycker
>             Fix For: 0.1.0
>
>
> Class ListTableModel does not call init(), which creates column names and classes. So a NullPointerException gets thrown from BaseTableModel's method getColumnCount() when trying to use an anonymous inner class implementation of ListTableModel (which implements the two methods declared abstract by ListTableModel). 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-482) VLDocking throws a NullPointerException, on closing a duplicate window

[Tobias V. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_24979 ] 

Tobias Vogel commented on RCP-482:
----------------------------------

Hm, you're right on this one. I just thought this has been clarified already, as VLDocking 2.1.3 is actually in the Spring-RCP repository.

> VLDocking throws a NullPointerException, on closing a duplicate window
> ----------------------------------------------------------------------
>
>                 Key: RCP-482
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-482
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>         Environment: Windows XP SP2, Java 1.5, Spring-RCP 0.3.0-SNAPSHOT current SVN Head (Revision 1785)
>            Reporter: Tobias Vogel
>
> I integrated VLDocking into my application. So far it works pretty well, besides one thing:
> - I open the application with one (or multiple) views (described in the context by VLDockingViewDescriptor") open
> - I choose the "NewWindowCommand" from the window menu (already integrated in a vanilla rcp project)
> - I then again try to close the window again which leads to the NullPointerException
> The relevant line in the DockViewTitleBar (see stacktrace below) looks like this:
> > tb.target.getDockKey().setNotification(false);
> Seems like the dock keys don't get duplicated while duplicating the windows, as the original window doesn't show this behaviour.
> Here's the stacktrace:
> [ERROR,MessagesDialogExceptionHandler,AWT-EventQueue-0] Uncaught throwable handled
> java.lang.NullPointerException
> 	at com.vlsolutions.swing.docking.DockViewTitleBar$FocusHighlighter.propertyChange(DockViewTitleBar.java:743)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:347)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
> 	at java.awt.KeyboardFocusManager.firePropertyChange(KeyboardFocusManager.java:1387)
> 	at java.awt.KeyboardFocusManager.setGlobalFocusOwner(KeyboardFocusManager.java:525)
> 	at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:469)
> 	at java.awt.Component.dispatchEventImpl(Component.java:4282)
> 	at java.awt.Container.dispatchEventImpl(Container.java:2116)
> 	at java.awt.Component.dispatchEvent(Component.java:4240)
> 	at java.awt.KeyboardFocusManager.processCurrentLightweightRequests(KeyboardFocusManager.java:2590)
> 	at java.awt.KeyboardFocusManager.retargetFocusEvent(KeyboardFocusManager.java:2837)
> 	at java.awt.Component.dispatchEventImpl(Component.java:4275)
> 	at java.awt.Container.dispatchEventImpl(Container.java:2116)
> 	at java.awt.Window.dispatchEventImpl(Window.java:2429)
> 	at java.awt.Component.dispatchEvent(Component.java:4240)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
> 	at java.awt.SequencedEvent.dispatch(SequencedEvent.java:98)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:177)
> 	at java.awt.Dialog$1.run(Dialog.java:1039)
> 	at java.awt.Dialog$3.run(Dialog.java:1091)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.awt.Dialog.show(Dialog.java:1089)
> 	at javax.swing.JOptionPane.showOptionDialog(JOptionPane.java:853)
> 	at org.springframework.richclient.exceptionhandling.AbstractDialogExceptionHandler.notifyUserAboutException(AbstractDialogExceptionHandler.java:77)
> 	at org.springframework.richclient.exceptionhandling.AbstractLoggingExceptionHandler.uncaughtException(AbstractLoggingExceptionHandler.java:48)
> 	at org.springframework.richclient.exceptionhandling.delegation.AbstractExceptionHandlerDelegate.uncaughtExceptionPurged(AbstractExceptionHandlerDelegate.java:70)
> 	at org.springframework.richclient.exceptionhandling.delegation.AbstractExceptionHandlerDelegate.uncaughtException(AbstractExceptionHandlerDelegate.java:66)
> 	at org.springframework.richclient.exceptionhandling.delegation.DelegatingExceptionHandler.uncaughtException(DelegatingExceptionHandler.java:66)
> 	at org.springframework.richclient.exceptionhandling.AwtExceptionHandlerAdapterHack.handle(AwtExceptionHandlerAdapterHack.java:48)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.awt.EventDispatchThread.handleException(EventDispatchThread.java:389)
> 	at java.awt.EventDispatchThread.processException(EventDispatchThread.java:295)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:287)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
> 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-482) VLDocking throws a NullPointerException, on closing a duplicate window

[Geoffrey De S. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_24978 ] 

Geoffrey De Smet commented on RCP-482:
--------------------------------------

Vldocking is GPL (aka commercial unfriendly) instead of ASL or LGPL,
so this might present a problem of us hosting it in our repo in the first place.
If the sources are uploaded too it's probably ok (but I am not a lawyer).

Since it's GPL I don't see it getting into repo1.maven.org any time soon,
but the bigger issue might be that it could impose that the vldocking code is split into it's own project,
because that integration code probably also needs to be GPL licenced...

> VLDocking throws a NullPointerException, on closing a duplicate window
> ----------------------------------------------------------------------
>
>                 Key: RCP-482
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-482
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>         Environment: Windows XP SP2, Java 1.5, Spring-RCP 0.3.0-SNAPSHOT current SVN Head (Revision 1785)
>            Reporter: Tobias Vogel
>
> I integrated VLDocking into my application. So far it works pretty well, besides one thing:
> - I open the application with one (or multiple) views (described in the context by VLDockingViewDescriptor") open
> - I choose the "NewWindowCommand" from the window menu (already integrated in a vanilla rcp project)
> - I then again try to close the window again which leads to the NullPointerException
> The relevant line in the DockViewTitleBar (see stacktrace below) looks like this:
> > tb.target.getDockKey().setNotification(false);
> Seems like the dock keys don't get duplicated while duplicating the windows, as the original window doesn't show this behaviour.
> Here's the stacktrace:
> [ERROR,MessagesDialogExceptionHandler,AWT-EventQueue-0] Uncaught throwable handled
> java.lang.NullPointerException
> 	at com.vlsolutions.swing.docking.DockViewTitleBar$FocusHighlighter.propertyChange(DockViewTitleBar.java:743)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:347)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
> 	at java.awt.KeyboardFocusManager.firePropertyChange(KeyboardFocusManager.java:1387)
> 	at java.awt.KeyboardFocusManager.setGlobalFocusOwner(KeyboardFocusManager.java:525)
> 	at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:469)
> 	at java.awt.Component.dispatchEventImpl(Component.java:4282)
> 	at java.awt.Container.dispatchEventImpl(Container.java:2116)
> 	at java.awt.Component.dispatchEvent(Component.java:4240)
> 	at java.awt.KeyboardFocusManager.processCurrentLightweightRequests(KeyboardFocusManager.java:2590)
> 	at java.awt.KeyboardFocusManager.retargetFocusEvent(KeyboardFocusManager.java:2837)
> 	at java.awt.Component.dispatchEventImpl(Component.java:4275)
> 	at java.awt.Container.dispatchEventImpl(Container.java:2116)
> 	at java.awt.Window.dispatchEventImpl(Window.java:2429)
> 	at java.awt.Component.dispatchEvent(Component.java:4240)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
> 	at java.awt.SequencedEvent.dispatch(SequencedEvent.java:98)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:177)
> 	at java.awt.Dialog$1.run(Dialog.java:1039)
> 	at java.awt.Dialog$3.run(Dialog.java:1091)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.awt.Dialog.show(Dialog.java:1089)
> 	at javax.swing.JOptionPane.showOptionDialog(JOptionPane.java:853)
> 	at org.springframework.richclient.exceptionhandling.AbstractDialogExceptionHandler.notifyUserAboutException(AbstractDialogExceptionHandler.java:77)
> 	at org.springframework.richclient.exceptionhandling.AbstractLoggingExceptionHandler.uncaughtException(AbstractLoggingExceptionHandler.java:48)
> 	at org.springframework.richclient.exceptionhandling.delegation.AbstractExceptionHandlerDelegate.uncaughtExceptionPurged(AbstractExceptionHandlerDelegate.java:70)
> 	at org.springframework.richclient.exceptionhandling.delegation.AbstractExceptionHandlerDelegate.uncaughtException(AbstractExceptionHandlerDelegate.java:66)
> 	at org.springframework.richclient.exceptionhandling.delegation.DelegatingExceptionHandler.uncaughtException(DelegatingExceptionHandler.java:66)
> 	at org.springframework.richclient.exceptionhandling.AwtExceptionHandlerAdapterHack.handle(AwtExceptionHandlerAdapterHack.java:48)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.awt.EventDispatchThread.handleException(EventDispatchThread.java:389)
> 	at java.awt.EventDispatchThread.processException(EventDispatchThread.java:295)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:287)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
> 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] Pharmacy paradice

[Isiah R. <dor...@br...>]

Re: [Springframework-rcp-dev] To bean or not to bean.

[Andy D. <an...@ma...>]

I'm late to the discussion, and I like the idea you present, but I want 
to be sure care is taken to provide for non standard "beans" or form 
objects.  We have several cases where we use DataObjects (as in the SDO 
spec) as opposed to JavaBeans.  We get these to work with the Spring 
Rich Form framework by using a custom PropertyAccessStrategy (amongst 
other things).  Since the form framework already has the idea of a 
"ValueModel", why not have some sort of ClassModel (insert better name 
here) that drives the layout of the FormModel properties?  A convenience 
method could be provided that adapts a Java Class to a ClassModel.

  - Andy


Jan Hoskens wrote:
> Hi all,
>
> There are some basic things in RCP that keep bothering me. More
> specific, the way how the FormModel is created and how it's handled when
> it is reset.
>
> FormModel creation is done by providing a bean which is actually as
> expected. After all we're working with spring, aren't we? Well, there
> are two things I want to point out here:
>
> 1) when you create your FormModel, you provide a bean that will be used
> to provide the necessary valueModels (VMs). Well, that's what you think
> it will do. Say you just created that FormModel with beanA, then right
> before showing that screen you set another FormObject beanB. Then the
> process of component creation kicks in and starts creating bindings and
> the necessary VMs. But at this moment beanB will be used to create VMs
> and VMM (ValueModel MetaData). BeanA was never used! And more
> troublesome, the VMM can result in a wrongly created binding. Say beanA
> only has read access to propertyX, and you expect a readonly field at
> that place, but beanB also provides write access to propertyX, so you'll
> get a writable field.
>
> In short, the bean given at formModel creation isn't always used, it's
> the current bean that is of importance when VMs are created. It even
> goes as far as: VMs can be created at any time always based on the
> current bean which may have been changed over time.
>
> 2) now I know this may seem strange in a spring-world, but why do I even
> need to specify a bean? The formModel and it's whole structure of VMs
> could be created by looking at Class or Interface level. It is only a
> structure that afterwards will be used to contain beans. Wouldn't it be
> wonderful to have something like "new FormModel(MyInterface)" not having
> to create a dummy bean? Take for example a back-end which provides the
> beans. No default constructor is present and the client isn't supposed
> to create new beans (only edit). However, RCP requires a bean to create
> the formModel, and thus need to provide a dummy bean somehow.
>
>
> Besides the creation aspect: FormModel reset and setting a null
> formObject results in a special handling. The current formObject is used
> to instantiate a new bean by calling a default constructor on its class.
> So resetting the form actually places a new bean as formObject and this
> bean can be different at at any time.
>
> And now the real reason of this mail (finally!). 
>
> Some of these issues could be resolved by storing the initially provided
> bean and reusing this when resetting/setting null. This would prevent
> the need to have a default constructor, but would not prevent the
> creation of VMs on a current bean instead of the initially provided one
> though. For some the latter may not be an issue. You do need to be aware
> that when creating the formModel, the given bean should be a dummy one.
>
> The second issue is the main thing I've been pondering of: to bean or
> not to bean. Should we create the formModel based on beans (current
> situation) or based on class/interface? We could create a FormModel
> based on a class/interface, then set a FormObject when needed and
> provide a null handling. The method getFormObject might actually return
> null while no default constructor is needed. No bean at creation time is
> needed. Now for al this magic to happen, I need to inform you that the
> current implementation does rely on the beans plumbing of spring. This
> isn't bad, but does mean a that some serious refactoring/implementing is
> needed before this will work. Before I jump into this pit, I'm wondering
> if this all makes sense. Is this worth the trip? Would you benefit from
> this change? I'm guessing it would, but I'd like to have some feedback
> on this first.
>
> ps: it might be that these things have been surfaced a while ago and
> that I'm just reopening the discussion. Haven't yet searched the mail
> archive. (I remember whining about this a year or so ago, but did I mail
> it??)
>
> Kind Regards,
> Jan
>
>
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
> .
>
>   

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-482) VLDocking throws a NullPointerException, on closing a duplicate window

[Tobias V. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_24966 ] 

Tobias Vogel commented on RCP-482:
----------------------------------

I found the solution, it's a bug in the VLDocking lib, see: http://www.vlsolutions.com/en/documentation/news/pressrelease20070308.php
-> DockViewTitleBar : fixed a NullPointerException related to property change propagation

Currently Spring-RCP only has version 2.1.3 available in their maven repository, maybe you could integrate version 2.1.4? I temprarily installed it locally in my maven repository, but it would be fine, if a project could be built directly from a clean checkout without any further steps needed.

> VLDocking throws a NullPointerException, on closing a duplicate window
> ----------------------------------------------------------------------
>
>                 Key: RCP-482
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-482
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>         Environment: Windows XP SP2, Java 1.5, Spring-RCP 0.3.0-SNAPSHOT current SVN Head (Revision 1785)
>            Reporter: Tobias Vogel
>
> I integrated VLDocking into my application. So far it works pretty well, besides one thing:
> - I open the application with one (or multiple) views (described in the context by VLDockingViewDescriptor") open
> - I choose the "NewWindowCommand" from the window menu (already integrated in a vanilla rcp project)
> - I then again try to close the window again which leads to the NullPointerException
> The relevant line in the DockViewTitleBar (see stacktrace below) looks like this:
> > tb.target.getDockKey().setNotification(false);
> Seems like the dock keys don't get duplicated while duplicating the windows, as the original window doesn't show this behaviour.
> Here's the stacktrace:
> [ERROR,MessagesDialogExceptionHandler,AWT-EventQueue-0] Uncaught throwable handled
> java.lang.NullPointerException
> 	at com.vlsolutions.swing.docking.DockViewTitleBar$FocusHighlighter.propertyChange(DockViewTitleBar.java:743)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:347)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
> 	at java.awt.KeyboardFocusManager.firePropertyChange(KeyboardFocusManager.java:1387)
> 	at java.awt.KeyboardFocusManager.setGlobalFocusOwner(KeyboardFocusManager.java:525)
> 	at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:469)
> 	at java.awt.Component.dispatchEventImpl(Component.java:4282)
> 	at java.awt.Container.dispatchEventImpl(Container.java:2116)
> 	at java.awt.Component.dispatchEvent(Component.java:4240)
> 	at java.awt.KeyboardFocusManager.processCurrentLightweightRequests(KeyboardFocusManager.java:2590)
> 	at java.awt.KeyboardFocusManager.retargetFocusEvent(KeyboardFocusManager.java:2837)
> 	at java.awt.Component.dispatchEventImpl(Component.java:4275)
> 	at java.awt.Container.dispatchEventImpl(Container.java:2116)
> 	at java.awt.Window.dispatchEventImpl(Window.java:2429)
> 	at java.awt.Component.dispatchEvent(Component.java:4240)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
> 	at java.awt.SequencedEvent.dispatch(SequencedEvent.java:98)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:177)
> 	at java.awt.Dialog$1.run(Dialog.java:1039)
> 	at java.awt.Dialog$3.run(Dialog.java:1091)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.awt.Dialog.show(Dialog.java:1089)
> 	at javax.swing.JOptionPane.showOptionDialog(JOptionPane.java:853)
> 	at org.springframework.richclient.exceptionhandling.AbstractDialogExceptionHandler.notifyUserAboutException(AbstractDialogExceptionHandler.java:77)
> 	at org.springframework.richclient.exceptionhandling.AbstractLoggingExceptionHandler.uncaughtException(AbstractLoggingExceptionHandler.java:48)
> 	at org.springframework.richclient.exceptionhandling.delegation.AbstractExceptionHandlerDelegate.uncaughtExceptionPurged(AbstractExceptionHandlerDelegate.java:70)
> 	at org.springframework.richclient.exceptionhandling.delegation.AbstractExceptionHandlerDelegate.uncaughtException(AbstractExceptionHandlerDelegate.java:66)
> 	at org.springframework.richclient.exceptionhandling.delegation.DelegatingExceptionHandler.uncaughtException(DelegatingExceptionHandler.java:66)
> 	at org.springframework.richclient.exceptionhandling.AwtExceptionHandlerAdapterHack.handle(AwtExceptionHandlerAdapterHack.java:48)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.awt.EventDispatchThread.handleException(EventDispatchThread.java:389)
> 	at java.awt.EventDispatchThread.processException(EventDispatchThread.java:295)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:287)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
> 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [Springframework-rcp-dev] To bean or not to bean. => Class based formmodels

[Roland R. <rr...@vd...>]

+1 to creating a FormModel based on a class (or interface)

This could make it possible to create FormModels on abstract Classes and 
do some sort of inheritance, instead of creating an FormModel (and Form) 
for every implementation of the base class.

Roll

Geoffrey De Smet wrote:
> +1  to creating a FormModel based on a Class (or interface)
>
> We 've discussed this before, but no one felt strong enough to implement it:
>
>
> Replay of an old mail of mine "Class based formmodels - WDYT"
>
> ===
> Currently form models are instance based.
> - they can't handle null values. A possible use case for a null value
> could be the details form of a master-detail view when nothing is
> selected. I think Larry had to sort of hack that.
> - it limits us from dependency injecting forms (as they need a form
> model based on an instance)
>
> Should they be class based,
> just like ORM mappings are also class based?
> What do you think?
>
>
> Backward compatibility can be ensured like this:
>
> public FormModel(Object o) {
>     this(o.getClass());
>     setFormObject(o);
> }
> ===
>
> spring-core always uses bean instances, but spring-core is an 
> initialization framework NOT a binding framework.
> jpa, hibernate, toplink are class based, they are binding frameworks (to 
> the database instead of the gui however).
>
> With kind regards,
> Geoffrey De Smet
>
> Benoit Xhenseval schreef:
>   
>> Hi all,
>>
>> I agree with Jan's case and go further in that replacing the form object
>> seems to trigger some strange behaviour due to the call to reset. I'm not
>> sure it is actually required... surely not in all cases anyway.
>>
>> This is especially true if one has a lot of "business" logic hanging of the
>> model (things handled by PropertyListeners on some properties). Changing the
>> formObject then has a massive ripple effect due to the reset call, it then
>> requires some specific code to simply "be ignored!".  I did raise this about
>> a year ago as I was facing exactly the case of having to provide a 'dummy'
>> bean before asking the user for the Id of the bean and then fetch it and
>> display it by calling setFormObject... I'd like FormModel to be able to take
>> a class/interface.
>>
>> It would also be useful to have the ability to enable / disable ALL
>> PropertyListeners in the subsequent ValueModels. So one could have a 'dead'
>> form, set the object, then enable logic for handling potential changes.
>>
>> I'd like to add that a parametizable/generics FormModel would also be useful
>> I think. But that would either require a move to 1.5 or to be in the tiger
>> module. Furthermore, it would be useful to provide helper methods on
>> ValueModel to get an Integer, a String, a Date, a BigDecimal... that would
>> remove much casting... Again, use of generics could help.
>>
>> In any case, please do not break dramatically the existing interfaces...
>>
>> My £0.02 worth comments,
>>
>> Thanks
>>
>> Benoit
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On Behalf Of
>> Rogan Dawes
>> Sent: 20 July 2007 10:05
>> To: spr...@li...
>> Subject: Re: [Springframework-rcp-dev] To bean or not to bean.
>>
>> Jan Hoskens wrote:
>>     
>>> Hi all,
>>>
>>>       
>>> The second issue is the main thing I've been pondering of: to bean or
>>> not to bean. Should we create the formModel based on beans (current
>>> situation) or based on class/interface? We could create a FormModel
>>> based on a class/interface, then set a FormObject when needed and
>>> provide a null handling. The method getFormObject might actually return
>>> null while no default constructor is needed. No bean at creation time is
>>> needed. Now for al this magic to happen, I need to inform you that the
>>> current implementation does rely on the beans plumbing of spring. This
>>> isn't bad, but does mean a that some serious refactoring/implementing is
>>> needed before this will work. Before I jump into this pit, I'm wondering
>>> if this all makes sense. Is this worth the trip? Would you benefit from
>>> this change? I'm guessing it would, but I'd like to have some feedback
>>> on this first.
>>>
>>> ps: it might be that these things have been surfaced a while ago and
>>> that I'm just reopening the discussion. Haven't yet searched the mail
>>> archive. (I remember whining about this a year or so ago, but did I mail
>>> it??)
>>>
>>> Kind Regards,
>>> Jan
>>>       
>> Hi Jan,
>>
>> Not having worked very heavily with FormModels, but struggling when I 
>> did, I agree with your analysis.
>>
>> It DOES make more sense to have the FormModel based on a Class or 
>> Interface, rather than an instance.
>>
>> Rogan
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Springframework-rcp-dev mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition. 
>> Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19/07/2007
>> 18:10
>>  
>>
>> No virus found in this outgoing message.
>> Checked by AVG Free Edition. 
>> Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19/07/2007
>> 18:10
>>  
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>   

Re: [Springframework-rcp-dev] To bean or not to bean. => Class based formmodels

[Geoffrey De S. <ge0...@gm...>]

+1  to creating a FormModel based on a Class (or interface)

We 've discussed this before, but no one felt strong enough to implement it:


Replay of an old mail of mine "Class based formmodels - WDYT"

===
Currently form models are instance based.
- they can't handle null values. A possible use case for a null value
could be the details form of a master-detail view when nothing is
selected. I think Larry had to sort of hack that.
- it limits us from dependency injecting forms (as they need a form
model based on an instance)

Should they be class based,
just like ORM mappings are also class based?
What do you think?


Backward compatibility can be ensured like this:

public FormModel(Object o) {
    this(o.getClass());
    setFormObject(o);
}
===

spring-core always uses bean instances, but spring-core is an 
initialization framework NOT a binding framework.
jpa, hibernate, toplink are class based, they are binding frameworks (to 
the database instead of the gui however).

With kind regards,
Geoffrey De Smet

Benoit Xhenseval schreef:
> Hi all,
> 
> I agree with Jan's case and go further in that replacing the form object
> seems to trigger some strange behaviour due to the call to reset. I'm not
> sure it is actually required... surely not in all cases anyway.
> 
> This is especially true if one has a lot of "business" logic hanging of the
> model (things handled by PropertyListeners on some properties). Changing the
> formObject then has a massive ripple effect due to the reset call, it then
> requires some specific code to simply "be ignored!".  I did raise this about
> a year ago as I was facing exactly the case of having to provide a 'dummy'
> bean before asking the user for the Id of the bean and then fetch it and
> display it by calling setFormObject... I'd like FormModel to be able to take
> a class/interface.
> 
> It would also be useful to have the ability to enable / disable ALL
> PropertyListeners in the subsequent ValueModels. So one could have a 'dead'
> form, set the object, then enable logic for handling potential changes.
> 
> I'd like to add that a parametizable/generics FormModel would also be useful
> I think. But that would either require a move to 1.5 or to be in the tiger
> module. Furthermore, it would be useful to provide helper methods on
> ValueModel to get an Integer, a String, a Date, a BigDecimal... that would
> remove much casting... Again, use of generics could help.
> 
> In any case, please do not break dramatically the existing interfaces...
> 
> My £0.02 worth comments,
> 
> Thanks
> 
> Benoit
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> Rogan Dawes
> Sent: 20 July 2007 10:05
> To: spr...@li...
> Subject: Re: [Springframework-rcp-dev] To bean or not to bean.
> 
> Jan Hoskens wrote:
>> Hi all,
>>
> 
>> The second issue is the main thing I've been pondering of: to bean or
>> not to bean. Should we create the formModel based on beans (current
>> situation) or based on class/interface? We could create a FormModel
>> based on a class/interface, then set a FormObject when needed and
>> provide a null handling. The method getFormObject might actually return
>> null while no default constructor is needed. No bean at creation time is
>> needed. Now for al this magic to happen, I need to inform you that the
>> current implementation does rely on the beans plumbing of spring. This
>> isn't bad, but does mean a that some serious refactoring/implementing is
>> needed before this will work. Before I jump into this pit, I'm wondering
>> if this all makes sense. Is this worth the trip? Would you benefit from
>> this change? I'm guessing it would, but I'd like to have some feedback
>> on this first.
>>
>> ps: it might be that these things have been surfaced a while ago and
>> that I'm just reopening the discussion. Haven't yet searched the mail
>> archive. (I remember whining about this a year or so ago, but did I mail
>> it??)
>>
>> Kind Regards,
>> Jan
> 
> Hi Jan,
> 
> Not having worked very heavily with FormModels, but struggling when I 
> did, I agree with your analysis.
> 
> It DOES make more sense to have the FormModel based on a Class or 
> Interface, rather than an instance.
> 
> Rogan
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19/07/2007
> 18:10
>  
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition. 
> Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19/07/2007
> 18:10
>  
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [Springframework-rcp-dev] Spring validation framework integration (springmodules-springrcp)

[Xavier B. <xav...@ac...>]

Don't worry for the late and thanks for the ValangRichValidator
information as well as the upload to the project of the RCP-477.

I haven't used the validation modules neather, but I read the
documentation and it's objective is to work with a web client
applications as well with a rich client applications.

I'm evaluating to use it in my application for this reason because I'm
using remoting to use some services and I wan't the validation in the
domain level to reuse it in both sides.

Regards
Xavier

On 7/20/07, Jan Hoskens <jh...@sc...> wrote:
> Sorry for the late reply, but I haven't yet used the modules validation
> framework. In the mean time you might have seen that there's a
> ValangRichValidator which uses the validation framework. You could check
> that one out and use it instead of the "normal" RulesValidator". Don't
> know how well it is integrated though.
>
> Kind Regards,
> Jan
>
> On Tue, 2007-07-10 at 12:24 -0500, Xavier Breton wrote:
> > Hi,
> >
> > Is there any integration between spring modules validation framework
> > and the spring rich client?
> >
> > Regards,
> > Xavier
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-482) VLDocking throws a NullPointerException, on closing a duplicate window

[Tobias V. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_24916 ] 

Tobias Vogel commented on RCP-482:
----------------------------------

I discovered it now the same on minimizing a window, but this still is not reproducible by certain steps. Seems liek a timing issue to me. Probably a component is destructed/replace too early or too late. If I find time this weekend I'll see, if I can dig into the source code a little and maybe track it down.

> VLDocking throws a NullPointerException, on closing a duplicate window
> ----------------------------------------------------------------------
>
>                 Key: RCP-482
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-482
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>         Environment: Windows XP SP2, Java 1.5, Spring-RCP 0.3.0-SNAPSHOT current SVN Head (Revision 1785)
>            Reporter: Tobias Vogel
>
> I integrated VLDocking into my application. So far it works pretty well, besides one thing:
> - I open the application with one (or multiple) views (described in the context by VLDockingViewDescriptor") open
> - I choose the "NewWindowCommand" from the window menu (already integrated in a vanilla rcp project)
> - I then again try to close the window again which leads to the NullPointerException
> The relevant line in the DockViewTitleBar (see stacktrace below) looks like this:
> > tb.target.getDockKey().setNotification(false);
> Seems like the dock keys don't get duplicated while duplicating the windows, as the original window doesn't show this behaviour.
> Here's the stacktrace:
> [ERROR,MessagesDialogExceptionHandler,AWT-EventQueue-0] Uncaught throwable handled
> java.lang.NullPointerException
> 	at com.vlsolutions.swing.docking.DockViewTitleBar$FocusHighlighter.propertyChange(DockViewTitleBar.java:743)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:347)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
> 	at java.awt.KeyboardFocusManager.firePropertyChange(KeyboardFocusManager.java:1387)
> 	at java.awt.KeyboardFocusManager.setGlobalFocusOwner(KeyboardFocusManager.java:525)
> 	at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:469)
> 	at java.awt.Component.dispatchEventImpl(Component.java:4282)
> 	at java.awt.Container.dispatchEventImpl(Container.java:2116)
> 	at java.awt.Component.dispatchEvent(Component.java:4240)
> 	at java.awt.KeyboardFocusManager.processCurrentLightweightRequests(KeyboardFocusManager.java:2590)
> 	at java.awt.KeyboardFocusManager.retargetFocusEvent(KeyboardFocusManager.java:2837)
> 	at java.awt.Component.dispatchEventImpl(Component.java:4275)
> 	at java.awt.Container.dispatchEventImpl(Container.java:2116)
> 	at java.awt.Window.dispatchEventImpl(Window.java:2429)
> 	at java.awt.Component.dispatchEvent(Component.java:4240)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
> 	at java.awt.SequencedEvent.dispatch(SequencedEvent.java:98)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:177)
> 	at java.awt.Dialog$1.run(Dialog.java:1039)
> 	at java.awt.Dialog$3.run(Dialog.java:1091)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.awt.Dialog.show(Dialog.java:1089)
> 	at javax.swing.JOptionPane.showOptionDialog(JOptionPane.java:853)
> 	at org.springframework.richclient.exceptionhandling.AbstractDialogExceptionHandler.notifyUserAboutException(AbstractDialogExceptionHandler.java:77)
> 	at org.springframework.richclient.exceptionhandling.AbstractLoggingExceptionHandler.uncaughtException(AbstractLoggingExceptionHandler.java:48)
> 	at org.springframework.richclient.exceptionhandling.delegation.AbstractExceptionHandlerDelegate.uncaughtExceptionPurged(AbstractExceptionHandlerDelegate.java:70)
> 	at org.springframework.richclient.exceptionhandling.delegation.AbstractExceptionHandlerDelegate.uncaughtException(AbstractExceptionHandlerDelegate.java:66)
> 	at org.springframework.richclient.exceptionhandling.delegation.DelegatingExceptionHandler.uncaughtException(DelegatingExceptionHandler.java:66)
> 	at org.springframework.richclient.exceptionhandling.AwtExceptionHandlerAdapterHack.handle(AwtExceptionHandlerAdapterHack.java:48)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.awt.EventDispatchThread.handleException(EventDispatchThread.java:389)
> 	at java.awt.EventDispatchThread.processException(EventDispatchThread.java:295)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:287)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
> 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-406) Wizard validation fires before reaching step

[Ryan S. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_24915 ] 

Ryan Sonnek commented on RCP-406:
---------------------------------

It's been almost a year since this was opened, and when I ran into these issues, I basically hopped off of the spring RCP bandwagon.  I haven't worked on it since.  

If spring-rcp supports my usecase (using whatever code solution), that's great.  my current code is here, but my project is opensource if there's anything interesting for you:
https://shard.dev.java.net/source/browse/shard/shard-minotaur/src/main/java/com/codecrate/shard/ui/

{code}
public void addPages() {
      addPage(new FormBackedWizardPage(new AbilityScoreForm(getWizardForm().getFormModel())));
      addPage(new FormBackedWizardPage(new RaceForm(getWizardForm().getFormModel(), raceDao, alignmentDao)));
      addPage(new FormBackedWizardPage(new BioForm(getWizardForm().getFormModel())));
}
{code}

Feel free to take this usecase and run with it.  I won't be working with spring-rcp to test any changes to the API.

> Wizard validation fires before reaching step
> --------------------------------------------
>
>                 Key: RCP-406
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-406
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>    Affects Versions: 0.1.0, 0.2.0, 0.2.1
>            Reporter: Ryan Sonnek
>            Assignee: Jan Hoskens
>            Priority: Critical
>             Fix For: 0.3.0
>
>
> Consider this simple scenerio:
> 1.  MyObject has two properties, firstName and lastName.
> 2.  register "required" validator for both properties.
> 3.  for some reason, i built a wizard where the firstName and lastName are on two different steps of the wizard.
> 4.  When launching the wizard, I'm unable to get past the first step because it says one of the properties is required.
> This is wrong because I haven't yet got to that step in the wizard to fill in that property.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-482) VLDocking throws a NullPointerException, on closing a duplicate window

[Rogan D. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_24914 ] 

Rogan Dawes commented on RCP-482:
---------------------------------

I see it as well.

Thing is, there is no "special handling" needed to open an additional window, as far as I can tell. To the best of my knowledge, the second and subsequent windows should be created in exactly the same way as the fist one.

I'm completely puzzled. Sorry.

> VLDocking throws a NullPointerException, on closing a duplicate window
> ----------------------------------------------------------------------
>
>                 Key: RCP-482
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-482
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>         Environment: Windows XP SP2, Java 1.5, Spring-RCP 0.3.0-SNAPSHOT current SVN Head (Revision 1785)
>            Reporter: Tobias Vogel
>
> I integrated VLDocking into my application. So far it works pretty well, besides one thing:
> - I open the application with one (or multiple) views (described in the context by VLDockingViewDescriptor") open
> - I choose the "NewWindowCommand" from the window menu (already integrated in a vanilla rcp project)
> - I then again try to close the window again which leads to the NullPointerException
> The relevant line in the DockViewTitleBar (see stacktrace below) looks like this:
> > tb.target.getDockKey().setNotification(false);
> Seems like the dock keys don't get duplicated while duplicating the windows, as the original window doesn't show this behaviour.
> Here's the stacktrace:
> [ERROR,MessagesDialogExceptionHandler,AWT-EventQueue-0] Uncaught throwable handled
> java.lang.NullPointerException
> 	at com.vlsolutions.swing.docking.DockViewTitleBar$FocusHighlighter.propertyChange(DockViewTitleBar.java:743)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:347)
> 	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
> 	at java.awt.KeyboardFocusManager.firePropertyChange(KeyboardFocusManager.java:1387)
> 	at java.awt.KeyboardFocusManager.setGlobalFocusOwner(KeyboardFocusManager.java:525)
> 	at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:469)
> 	at java.awt.Component.dispatchEventImpl(Component.java:4282)
> 	at java.awt.Container.dispatchEventImpl(Container.java:2116)
> 	at java.awt.Component.dispatchEvent(Component.java:4240)
> 	at java.awt.KeyboardFocusManager.processCurrentLightweightRequests(KeyboardFocusManager.java:2590)
> 	at java.awt.KeyboardFocusManager.retargetFocusEvent(KeyboardFocusManager.java:2837)
> 	at java.awt.Component.dispatchEventImpl(Component.java:4275)
> 	at java.awt.Container.dispatchEventImpl(Container.java:2116)
> 	at java.awt.Window.dispatchEventImpl(Window.java:2429)
> 	at java.awt.Component.dispatchEvent(Component.java:4240)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
> 	at java.awt.SequencedEvent.dispatch(SequencedEvent.java:98)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:177)
> 	at java.awt.Dialog$1.run(Dialog.java:1039)
> 	at java.awt.Dialog$3.run(Dialog.java:1091)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.awt.Dialog.show(Dialog.java:1089)
> 	at javax.swing.JOptionPane.showOptionDialog(JOptionPane.java:853)
> 	at org.springframework.richclient.exceptionhandling.AbstractDialogExceptionHandler.notifyUserAboutException(AbstractDialogExceptionHandler.java:77)
> 	at org.springframework.richclient.exceptionhandling.AbstractLoggingExceptionHandler.uncaughtException(AbstractLoggingExceptionHandler.java:48)
> 	at org.springframework.richclient.exceptionhandling.delegation.AbstractExceptionHandlerDelegate.uncaughtExceptionPurged(AbstractExceptionHandlerDelegate.java:70)
> 	at org.springframework.richclient.exceptionhandling.delegation.AbstractExceptionHandlerDelegate.uncaughtException(AbstractExceptionHandlerDelegate.java:66)
> 	at org.springframework.richclient.exceptionhandling.delegation.DelegatingExceptionHandler.uncaughtException(DelegatingExceptionHandler.java:66)
> 	at org.springframework.richclient.exceptionhandling.AwtExceptionHandlerAdapterHack.handle(AwtExceptionHandlerAdapterHack.java:48)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at java.awt.EventDispatchThread.handleException(EventDispatchThread.java:389)
> 	at java.awt.EventDispatchThread.processException(EventDispatchThread.java:295)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:287)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
> 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira