springframework-rcp-dev — Spring Rich Client developer list

[Springframework-rcp-dev] [Spring-JIRA] Created: (RCP-488) InputApplicationDialog.getValidationReporter() could be public

[Benoit X. (JIRA) <no...@at...>]

InputApplicationDialog.getValidationReporter() could be public
--------------------------------------------------------------

                 Key: RCP-488
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-488
             Project: Spring Framework Rich Client Project
          Issue Type: Improvement
          Components: Helper Classes
            Reporter: Benoit Xhenseval


I'm trying to use the InputApplicationDialog and I think that a private method should be made public: getValidationReporter().

Some basic rules are created for string length for instance but I would like to validate the input once the user tries to press enter (e.g. check the DB/Server).

I wanted to use the setInputConstraint(Constraint c) and it works fine, the server detects a duplicate and returns false so the dialog cannot be closed via OK, however how could I notify the user in the error reporting area?

If the method getValidationReporter() was public, one could simply do it like this:

final InputApplicationDialog dia = new InputApplicationDialog(nameModel, "name");
dia.setTitle(getMessage("xxxx.title"));
dia.setInputLabelMessage("Enter a query name");
dia.setInputConstraint(new Constraint() {
    public boolean test(Object argument) {
                final String name = (String) argument;
                boolean found = ... check if the name already exist
                if (found) {
                    dia.getValidationReporter().setMessage(
                                    new DefaultMessage("not unique", Severity.ERROR));
                }
                return !found;
    }
});

dia.showDialog();
 
So, may I suggest that this method is made public?

Of course, there may be a better way... could someone enlighten me?

Thanks

Benoit


-- 
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] ComboBoxAutoCompletion and model events...

[Benoit X. <bx...@ob...>]

Hi

=20

I=92m using the ComboBoxAutoCompletionInterceptorFactory and that works =
fine
except that it sends PropertyChangeEvents on the model before the =
selection
is completed.

=20

Let=92s take a basic example of a combo box containing currencies: ADP, =
=85UAG,
UAH, UGX, USD, UYU.

If I want to select US Dollars, I start typing =91U=92 and UAG is =
selected AND
the model gets an event saying that the value is now UAG.

=20

This is not something that I=92d like (as a remote call is required for
instance), is there a way to ensure that the PropertyChangeEvent  is =
sent
when the selection is complete? E.g. when the focus is lost for =
instance?

=20

I=92m sure it is something that other project are facing.

=20

Any pointer or guideline would be welcomed and I would contribute the =
code
back to the community if suitable,

=20

Many thanks!

=20

Benoit

=20

PS: this was discussed a while back=85 HYPERLINK
"http://forum.springframework.org/showthread.php?t=3D20154&highlight=3Dco=
mbo+eve
nt"http://forum.springframework.org/showthread.php?t=3D20154&highlight=3D=
combo+e
vent

But I have not had a chance to look at it, has anyone done it?

=20

-------------------------------

IMPORTANT NOTICE This communication contains information that is =
considered
confidential and may also be privileged . It is for the exclusive use of =
the
intended recipient(s). If you are not the intended recipient(s) please =
note
that any form of distribution, copying or use of this communication or =
the
information in it is strictly prohibited and may be unlawful. If you =
have
received this communication in error please return it to the sender and
delete the original.

=20


No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.487 / Virus Database: 269.13.19/1008 - Release Date: =
14/09/2007
08:59
=20

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-487) MDI interface does not work properly with minimised windows

[Benoit X. (JIRA) <no...@at...>]

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

Benoit Xhenseval commented on RCP-487:
--------------------------------------

Apologies, it was indeed fixed. We did override the method where the fix was placed...

Thanks to Peter for fixing it so quickly

Regards
Benoit

> MDI interface does not work properly with minimised windows
> -----------------------------------------------------------
>
>                 Key: RCP-487
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-487
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>            Assignee: Peter De Bruycker
>
> HI
> This is probably something for Peter.
> If you have several windows open in an MDI, you can minimise them one by one
> But a minimized window can only be moved if it's the _last one_ that was minimized!
> it should be possible to reposition any minimized window.
> We try to move them by doing a single left click and hold on a minimised window and try to drag.  If it is now the last windows, it immediately re-opens it!
> We also noticed that there was no 'Minimize all' option to the right-click menu inside the MDI... That'd be great..
> Thanks!
> Benoit

-- 
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-487) MDI interface does not work properly with minimised windows

[Benoit X. (JIRA) <no...@at...>]

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

Benoit Xhenseval commented on RCP-487:
--------------------------------------

I do not think that it is fixed, I've just upgraded and cannot see any difference under JDK 1.5.0_12.

MDI, say you have 3 internal frames, F1, F2 and F3.

- If you minimise F1, you can select it and move it around
- If you minimise F1 and then F2, you can select and move F2 but touch F1 and it opens immediately

Only the LAST window minimised can have its icon moved.
I do not think I've missed something...

> MDI interface does not work properly with minimised windows
> -----------------------------------------------------------
>
>                 Key: RCP-487
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-487
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>            Assignee: Peter De Bruycker
>
> HI
> This is probably something for Peter.
> If you have several windows open in an MDI, you can minimise them one by one
> But a minimized window can only be moved if it's the _last one_ that was minimized!
> it should be possible to reposition any minimized window.
> We try to move them by doing a single left click and hold on a minimised window and try to drag.  If it is now the last windows, it immediately re-opens it!
> We also noticed that there was no 'Minimize all' option to the right-click menu inside the MDI... That'd be great..
> Thanks!
> Benoit

-- 
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-487) MDI interface does not work properly with minimised windows

[Peter De B. (JIRA) <no...@at...>]

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

Peter De Bruycker commented on RCP-487:
---------------------------------------

fix checked in.

about the minimize all command: working on it ;-)

> MDI interface does not work properly with minimised windows
> -----------------------------------------------------------
>
>                 Key: RCP-487
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-487
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>            Assignee: Peter De Bruycker
>
> HI
> This is probably something for Peter.
> If you have several windows open in an MDI, you can minimise them one by one
> But a minimized window can only be moved if it's the _last one_ that was minimized!
> it should be possible to reposition any minimized window.
> We try to move them by doing a single left click and hold on a minimised window and try to drag.  If it is now the last windows, it immediately re-opens it!
> We also noticed that there was no 'Minimize all' option to the right-click menu inside the MDI... That'd be great..
> Thanks!
> Benoit

-- 
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] Resolved: (RCP-487) MDI interface does not work properly with minimised windows

[Peter De B. (JIRA) <no...@at...>]

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

Peter De Bruycker resolved RCP-487.
-----------------------------------

      Assignee: Peter De Bruycker
    Resolution: Fixed

> MDI interface does not work properly with minimised windows
> -----------------------------------------------------------
>
>                 Key: RCP-487
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-487
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>            Assignee: Peter De Bruycker
>
> HI
> This is probably something for Peter.
> If you have several windows open in an MDI, you can minimise them one by one
> But a minimized window can only be moved if it's the _last one_ that was minimized!
> it should be possible to reposition any minimized window.
> We try to move them by doing a single left click and hold on a minimised window and try to drag.  If it is now the last windows, it immediately re-opens it!
> We also noticed that there was no 'Minimize all' option to the right-click menu inside the MDI... That'd be great..
> Thanks!
> Benoit

-- 
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] Created: (RCP-487) MDI interface does not work properly with minimised windows

[Benoit X. (JIRA) <no...@at...>]

MDI interface does not work properly with minimised windows
-----------------------------------------------------------

                 Key: RCP-487
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-487
             Project: Spring Framework Rich Client Project
          Issue Type: Bug
    Affects Versions: 0.3.0
            Reporter: Benoit Xhenseval


HI

This is probably something for Peter.

If you have several windows open in an MDI, you can minimise them one by one

But a minimized window can only be moved if it's the _last one_ that was minimized!
it should be possible to reposition any minimized window.

We try to move them by doing a single left click and hold on a minimised window and try to drag.  If it is now the last windows, it immediately re-opens it!

We also noticed that there was no 'Minimize all' option to the right-click menu inside the MDI... That'd be great..

Thanks!
Benoit

-- 
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-486) ShuttleList cannot be enabled/disabled

[Benoit X. (JIRA) <no...@at...>]

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

Benoit Xhenseval updated RCP-486:
---------------------------------

    Attachment: ShuttleList-patch.txt

patch for the ShuttleList.

> ShuttleList cannot be enabled/disabled
> --------------------------------------
>
>                 Key: RCP-486
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-486
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Helper Classes
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>         Attachments: ShuttleList-patch.txt
>
>
> Hi
> I'd like to offer a rough patch for the following issue.  It seems that the ShuttleList does not support changes to the 'enabled' meta data for a field.
> I've fixed this by simply overriding a setEnabled method on the ShuttleList which then enables (or not) the 2 lists and buttons).  The buttons had to become fields.
> I hope you can integrate this change.
> Thanks!
> Benoit

-- 
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] Created: (RCP-486) ShuttleList cannot be enabled/disabled

[Benoit X. (JIRA) <no...@at...>]

ShuttleList cannot be enabled/disabled
--------------------------------------

                 Key: RCP-486
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-486
             Project: Spring Framework Rich Client Project
          Issue Type: Bug
          Components: Helper Classes
    Affects Versions: 0.3.0
            Reporter: Benoit Xhenseval


Hi

I'd like to offer a rough patch for the following issue.  It seems that the ShuttleList does not support changes to the 'enabled' meta data for a field.

I've fixed this by simply overriding a setEnabled method on the ShuttleList which then enables (or not) the 2 lists and buttons).  The buttons had to become fields.

I hope you can integrate this change.

Thanks!
Benoit

-- 
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] Refactoring the docking code

[Jonny W. <jwr...@gm...>]

Hi Rogan,

I appreciate your consideration of my code when doing this refactoring.
It'll make keeping the jide integration code in-sync with the main code-base
easier.

As for the need for the JideApplicationWindow, I'm not sure what you mean
about different from standard behaviour. When I implemented the docking code
there was no other example or standard, so I just did what made sense to me
at the time. It seems that we may have a different view on the relative
roles of application windows, application pages and perspectives. How do you
see the roles of application window, application page and perspectives with
respect to a docking implementation? I'll also look at the vldocking code
when I get the chance, as I think it's worthwhile to have the docking
implementation consistent in their concepts and the introduction of these
refactorings seems like a good time to do that.

Regarding the perspectives, the exposure of the JideApplicationWindow in the
API, I'd say this a leaking of the implementation details into the API and
so could be done better for sure, so I don't see a problem there.

Jonny

On 9/10/07, Rogan Dawes <ro...@da...> wrote:
>
>
> Hi Jonny,
>
> Thanks for taking the time to take a look. I did consider your
> implementation of the JIDE docking code when doing the refactoring. The
> major difference that is not accounted for in the refactoring is the
> JideApplicationWindow code.
>
> I must admit, I'm not entirely sure why this is needed. Any reason that
> this has to be different to the standard behaviour? Can the JIDE
> DockableHolder not be a property of the JideApplicationPage, rather?
>
> I absolutely do plan to make a ChangePerspectiveCommand. You may have
> seen the PageDescriptorRegistry, ShowPageCommand and ShowPageMenu that I
> added at the beginning of the year. I was previously implementing
> Perspectives in their own Page. Unfortunately, this ends up requiring
> unclean changes to support persistence of Views across Perspective
> changes.
>
> 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
>

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

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

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

Jan Hoskens closed RCP-165.
---------------------------

    Resolution: Fixed

fixed in revision:
http://spring-rich-c.svn.sourceforge.net/spring-rich-c/?rev=1803&view=rev

changes to make added to upgrade to 0.3 page in site.

Thanks for the patch, Arne & sorry for the delay.

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch, RCP-165.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

-- 
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] concurrent modif in the multicaster

[Jan H. <jh...@sc...>]

The simpleApplicationEventMulticaster has a TaskExecutor property which
handles the event casting. You can opt to use a SyncTaskExecutor here to
have your events handled synchronously. 

Besides this, the concurrentModificationException might have nothing to
do with threading. It's possible that while events are cast, one of the
listeners is changing(adding/removing) the listener list of the
multicaster.

As for the gui updating, I'm guessing your different threads do gui
updating on the EDT (as it should be). So these are already
synchronized.

Kind Regards,
Jan

On Mon, 2007-09-10 at 16:12 +0100, Benoit Xhenseval wrote:
> Hi *,
> 
>  
> 
> First of all, many thanks for considering the Readony interceptor!
> That is super to have an official implementation.
> 
>  
> 
> I have just experienced the following problem a couple of times:
> 
>  
> 
> java.util.ConcurrentModificationException
> java.util.ConcurrentModificationException
>         at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:365)
>         at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:376)
>         at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:74)
>         at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:246)
>         at net.xxxxx.gui.domain.BusinessEventConsumer$2.run(BusinessEventConsumer.java:207)
>         at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
>         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 sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at foxtrot.pumps.ConditionalEventPump.pumpEvents(ConditionalEventPump.java:98)
>         at foxtrot.AbstractSyncWorker.post(AbstractSyncWorker.java:98)
>         at foxtrot.AbstractSyncWorker.post(AbstractSyncWorker.java:124)
>         at foxtrot.Worker.post(Worker.java:139)
>         at net.xxxxxx.gui.dao.AbstractRemoteDao.executeBlockingJobInBackground(AbstractRemoteDao.java:89)
> 
>  
> 
> My application may have more than 1 thread updating the GUI. As far as
> I can see, there is a scenario in my app where the server triggers a
> refresh on the GUI and the dispatching thread also tries to send an
> event.
> 
>  
> 
> Is there any reason why the
> SimpleApplicationEventMulticaster.multicastEvent is not synchronized?
> Should it be?
> 
> Should the synchronization be done via the
> AbstractApplicationContext.publishEvent?
> 
>  
> 
> I believe that some form of synchronization is required and that it
> should be done on either classes and not on the caller since there may
> be many…
> 
>  
> 
> These 2 classes are in spring-context…
> 
>  
> 
> The BusinessEventConsumer line 207 is like this:
> 
>         if(shouldTriggerScreenRefresh(event)) {
> 
>             SwingUtilities.invokeLater(new Runnable() {
> 
>                 public void run() {
> 
> 
> Application.instance().getApplicationContext().publishEvent(newClientAppEvent(event));
> 
>                 }
> 
>             });
> 
>         }
> 
>  
> 
> Suggestions welcomed…
> 
>  
> 
> Thanks
> 
>  
> 
> Benoit.
> 
>  
> 
>  
> 
>  
> 
> -------------------------------
> 
> IMPORTANT NOTICE This communication contains information that is
> considered confidential and may also be privileged . It is for the
> exclusive use of the intended recipient(s). If you are not the
> intended recipient(s) please note that any form of distribution,
> copying or use of this communication or the information in it is
> strictly prohibited and may be unlawful. If you have received this
> communication in error please return it to the sender and delete the
> original.
> 
>  
> 
> 
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.485 / Virus Database: 269.13.12/997 - Release Date:
> 09/09/2007 10:17
> 
> 
> -------------------------------------------------------------------------
> 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


 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm

Re: [Springframework-rcp-dev] Refactoring the docking code

[Rogan D. <ro...@da...>]

Jonny Wray wrote:
> Rogan,
> 
> This is Jonny Wray, author of the JIDE docking integration.
> 
> I looked over your refactorings wrt the JIDE related code and it looks 
> great. Good to know there's common ground between the two frameworks 
> that can be abstracted out. The one difference I notice is that you are 
> applying perspectives on a page, whereas I apply then on a window, at 
> least at the API level. However, in my implementation it actually 
> identifies the perspective on a page by page basis, so the changes 
> shouldn't be too hard to make and the code should be cleaner.
> 
> One other addition might be useful, a 'change perspective' command that 
> allows configuration of the specific perspective within the application 
> context, and a  doExecuteCommand method that calls switch on that 
> perspective.
> 
> thanks
> Jonny

Hi Jonny,

Thanks for taking the time to take a look. I did consider your 
implementation of the JIDE docking code when doing the refactoring. The 
major difference that is not accounted for in the refactoring is the 
JideApplicationWindow code.

I must admit, I'm not entirely sure why this is needed. Any reason that 
this has to be different to the standard behaviour? Can the JIDE 
DockableHolder not be a property of the JideApplicationPage, rather?

I absolutely do plan to make a ChangePerspectiveCommand. You may have 
seen the PageDescriptorRegistry, ShowPageCommand and ShowPageMenu that I 
added at the beginning of the year. I was previously implementing 
Perspectives in their own Page. Unfortunately, this ends up requiring 
unclean changes to support persistence of Views across Perspective changes.

Rogan

Re: [Springframework-rcp-dev] Refactoring the docking code

[Jonny W. <jwr...@gm...>]

Rogan,

This is Jonny Wray, author of the JIDE docking integration.

I looked over your refactorings wrt the JIDE related code and it looks
great. Good to know there's common ground between the two frameworks that
can be abstracted out. The one difference I notice is that you are applying
perspectives on a page, whereas I apply then on a window, at least at the
API level. However, in my implementation it actually identifies the
perspective on a page by page basis, so the changes shouldn't be too hard to
make and the code should be cleaner.

One other addition might be useful, a 'change perspective' command that
allows configuration of the specific perspective within the application
context, and a  doExecuteCommand method that calls switch on that
perspective.

thanks
Jonny

[Springframework-rcp-dev] concurrent modif in the multicaster

[Benoit X. <bx...@ob...>]

Hi *,

=20

First of all, many thanks for considering the Readony interceptor! That =
is
super to have an official implementation.

=20

I have just experienced the following problem a couple of times:

=20

java.util.ConcurrentModificationException
java.util.ConcurrentModificationException
        at
java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:3=
65)
        at =
java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:376)
        at
org.springframework.context.event.SimpleApplicationEventMulticaster.multi=
cas
tEvent(SimpleApplicationEventMulticaster.java:74)
        at
org.springframework.context.support.AbstractApplicationContext.publishEve=
nt(
AbstractApplicationContext.java:246)
        at
net.xxxxx.gui.domain.BusinessEventConsumer$2.run(BusinessEventConsumer.ja=
va:
207)
        at =
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
        at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread=
.ja
va:242)
        at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.j=
ava
:163)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
        at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl
.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at
foxtrot.pumps.ConditionalEventPump.pumpEvents(ConditionalEventPump.java:9=
8)
        at foxtrot.AbstractSyncWorker.post(AbstractSyncWorker.java:98)
        at foxtrot.AbstractSyncWorker.post(AbstractSyncWorker.java:124)
        at foxtrot.Worker.post(Worker.java:139)
        at
net.xxxxxx.gui.dao.AbstractRemoteDao.executeBlockingJobInBackground(Abstr=
act
RemoteDao.java:89)

=20

My application may have more than 1 thread updating the GUI. As far as I =
can
see, there is a scenario in my app where the server triggers a refresh =
on
the GUI and the dispatching thread also tries to send an event.

=20

Is there any reason why the =
SimpleApplicationEventMulticaster.multicastEvent
is not synchronized? Should it be?

Should the synchronization be done via the
AbstractApplicationContext.publishEvent?

=20

I believe that some form of synchronization is required and that it =
should
be done on either classes and not on the caller since there may be =
many=85

=20

These 2 classes are in spring-context=85

=20

The BusinessEventConsumer line 207 is like this:

        if (shouldTriggerScreenRefresh(event)) {

            SwingUtilities.invokeLater(new Runnable() {

                public void run() {

=20
Application.instance().getApplicationContext().publishEvent(new
ClientAppEvent(event));

                }

            });

        }

=20

Suggestions welcomed=85

=20

Thanks

=20

Benoit.

=20

=20

=20

-------------------------------

IMPORTANT NOTICE This communication contains information that is =
considered
confidential and may also be privileged . It is for the exclusive use of =
the
intended recipient(s). If you are not the intended recipient(s) please =
note
that any form of distribution, copying or use of this communication or =
the
information in it is strictly prohibited and may be unlawful. If you =
have
received this communication in error please return it to the sender and
delete the original.

=20


No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.485 / Virus Database: 269.13.12/997 - Release Date: =
09/09/2007
10:17
=20

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-485) A readonly text field should not stay at beginning of text by default

[Peter De B. (JIRA) <no...@at...>]

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

Peter De Bruycker commented on RCP-485:
---------------------------------------

implemented using setCaretPosition approach

> A readonly text field should not stay at beginning of text by default
> ---------------------------------------------------------------------
>
>                 Key: RCP-485
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-485
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>            Assignee: Peter De Bruycker
>         Attachments: ReadonlyTextCaretFormComponentInterceptorFactory.java, screenshot-1.jpg, screenshot-2.jpg
>
>
> Hi
> I would like to give this small class based on FormComponentInterceptorFactory.
> The aim is to force a read-only text field to keep its caret at position 0. A user would prefer to see the beginning of the text in such a field rather that the end.
> This picture shows how it is now:
> http://www.objectlab.co.uk/jfree/disabled.png
> and how it looks with the fix:
> http://www.objectlab.co.uk/jfree/disabled2.png
> It is ok to release under Apache2 licence.
> Feel free to comment/amend/improve.
> Thanks
> Benoit

-- 
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] Resolved: (RCP-485) A readonly text field should not stay at beginning of text by default

[Peter De B. (JIRA) <no...@at...>]

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

Peter De Bruycker resolved RCP-485.
-----------------------------------

    Resolution: Fixed

> A readonly text field should not stay at beginning of text by default
> ---------------------------------------------------------------------
>
>                 Key: RCP-485
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-485
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>            Assignee: Peter De Bruycker
>         Attachments: ReadonlyTextCaretFormComponentInterceptorFactory.java, screenshot-1.jpg, screenshot-2.jpg
>
>
> Hi
> I would like to give this small class based on FormComponentInterceptorFactory.
> The aim is to force a read-only text field to keep its caret at position 0. A user would prefer to see the beginning of the text in such a field rather that the end.
> This picture shows how it is now:
> http://www.objectlab.co.uk/jfree/disabled.png
> and how it looks with the fix:
> http://www.objectlab.co.uk/jfree/disabled2.png
> It is ok to release under Apache2 licence.
> Feel free to comment/amend/improve.
> Thanks
> Benoit

-- 
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-485) A readonly text field should not stay at beginning of text by default

[Peter De B. (JIRA) <no...@at...>]

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

Peter De Bruycker commented on RCP-485:
---------------------------------------

I don't think changing the updatePolicy is an option, as this was introduced in jdk 1.5. Since we're providing compatibility with 1.4, I think the only option is setCaretPosition

> A readonly text field should not stay at beginning of text by default
> ---------------------------------------------------------------------
>
>                 Key: RCP-485
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-485
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>            Assignee: Peter De Bruycker
>         Attachments: ReadonlyTextCaretFormComponentInterceptorFactory.java, screenshot-1.jpg, screenshot-2.jpg
>
>
> Hi
> I would like to give this small class based on FormComponentInterceptorFactory.
> The aim is to force a read-only text field to keep its caret at position 0. A user would prefer to see the beginning of the text in such a field rather that the end.
> This picture shows how it is now:
> http://www.objectlab.co.uk/jfree/disabled.png
> and how it looks with the fix:
> http://www.objectlab.co.uk/jfree/disabled2.png
> It is ok to release under Apache2 licence.
> Feel free to comment/amend/improve.
> Thanks
> Benoit

-- 
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-485) A readonly text field should not stay at beginning of text by default

[Benoit X. (JIRA) <no...@at...>]

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

Benoit Xhenseval updated RCP-485:
---------------------------------

    Attachment: screenshot-2.jpg

The caret does not move automatically

> A readonly text field should not stay at beginning of text by default
> ---------------------------------------------------------------------
>
>                 Key: RCP-485
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-485
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>         Attachments: ReadonlyTextCaretFormComponentInterceptorFactory.java, screenshot-1.jpg, screenshot-2.jpg
>
>
> Hi
> I would like to give this small class based on FormComponentInterceptorFactory.
> The aim is to force a read-only text field to keep its caret at position 0. A user would prefer to see the beginning of the text in such a field rather that the end.
> This picture shows how it is now:
> http://www.objectlab.co.uk/jfree/disabled.png
> and how it looks with the fix:
> http://www.objectlab.co.uk/jfree/disabled2.png
> It is ok to release under Apache2 licence.
> Feel free to comment/amend/improve.
> Thanks
> Benoit

-- 
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-485) A readonly text field should not stay at beginning of text by default

[Benoit X. (JIRA) <no...@at...>]

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

Benoit Xhenseval updated RCP-485:
---------------------------------

    Attachment: screenshot-1.jpg

the field is automatically scrolled

> A readonly text field should not stay at beginning of text by default
> ---------------------------------------------------------------------
>
>                 Key: RCP-485
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-485
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>         Attachments: ReadonlyTextCaretFormComponentInterceptorFactory.java, screenshot-1.jpg
>
>
> Hi
> I would like to give this small class based on FormComponentInterceptorFactory.
> The aim is to force a read-only text field to keep its caret at position 0. A user would prefer to see the beginning of the text in such a field rather that the end.
> This picture shows how it is now:
> http://www.objectlab.co.uk/jfree/disabled.png
> and how it looks with the fix:
> http://www.objectlab.co.uk/jfree/disabled2.png
> It is ok to release under Apache2 licence.
> Feel free to comment/amend/improve.
> Thanks
> Benoit

-- 
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-485) A readonly text field should not stay at beginning of text by default

[Benoit X. (JIRA) <no...@at...>]

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

Benoit Xhenseval updated RCP-485:
---------------------------------

    Attachment: ReadonlyTextCaretFormComponentInterceptorFactory.java

first cut...

> A readonly text field should not stay at beginning of text by default
> ---------------------------------------------------------------------
>
>                 Key: RCP-485
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-485
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>         Attachments: ReadonlyTextCaretFormComponentInterceptorFactory.java, screenshot-1.jpg
>
>
> Hi
> I would like to give this small class based on FormComponentInterceptorFactory.
> The aim is to force a read-only text field to keep its caret at position 0. A user would prefer to see the beginning of the text in such a field rather that the end.
> This picture shows how it is now:
> http://www.objectlab.co.uk/jfree/disabled.png
> and how it looks with the fix:
> http://www.objectlab.co.uk/jfree/disabled2.png
> It is ok to release under Apache2 licence.
> Feel free to comment/amend/improve.
> Thanks
> Benoit

-- 
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] Created: (RCP-485) A readonly text field should not stay at beginning of text by default

[Benoit X. (JIRA) <no...@at...>]

A readonly text field should not stay at beginning of text by default
---------------------------------------------------------------------

                 Key: RCP-485
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-485
             Project: Spring Framework Rich Client Project
          Issue Type: New Feature
    Affects Versions: 0.3.0
            Reporter: Benoit Xhenseval


Hi
I would like to give this small class based on FormComponentInterceptorFactory.

The aim is to force a read-only text field to keep its caret at position 0. A user would prefer to see the beginning of the text in such a field rather that the end.

This picture shows how it is now:
http://www.objectlab.co.uk/jfree/disabled.png

and how it looks with the fix:
http://www.objectlab.co.uk/jfree/disabled2.png

It is ok to release under Apache2 licence.
Feel free to comment/amend/improve.

Thanks
Benoit

-- 
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] Position of caret for readonly fields

[Peter De B. <pet...@gm...>]

Do something  like this:

[code]
            textComponent.getDocument().addDocumentListener( new
DocumentListener() {
                public void removeUpdate( DocumentEvent e ) {
                    fixCaret();
                }

                public void insertUpdate( DocumentEvent e ) {
                    fixCaret();
                }

                public void changedUpdate( DocumentEvent e ) {
                    fixCaret();
                }

                private void fixCaret() {
                    if( !textComponent.hasFocus() ) {
                        // need to invoke later, as the text change also
changes the caret
                        // position
                        SwingUtilities.invokeLater( new Runnable() {
                            public void run() {
                                textComponent.setCaretPosition( 0 );
                            }
                        } );
                    }
                }

            } );
[/code]

On 9/7/07, Peter De Bruycker <pet...@gm...> wrote:
>
>
>
> On 9/7/07, Rogan Dawes <ro...@da...> wrote:
> >
> > Andy DePue wrote:
> > >   If this is a Swing "feature", then I'm not aware of a simple setting
> > > somewhere (maybe someone else knows of one?).  I do know that
> > > DefaultCaret has a setUpdatePolicy method.  You would have to get the
> > > Caret from the JTextField, make sure it is a DefaultCaret, cast it to
> > > DefaultCaret, and invoke setUpdatePolicy(DefaultCaret.NEVER_UPDATE).
> > > Even then, I haven't tested this, so I'm not sure if it would have the
> >
> > > desired effect.  Another approach would be to implement a
> > > FormComponentInterceptor that automatically handles any JTextField
> > that
> > > is not enabled so that the caret it always placed at the beginning of
> > > the field.  See SelectAllFormComponentInterceptorFactory for an
> > example
> > > of what an interceptor looks like.
> > >
> > >   - Andy
> >
> > How about calling
> >
> > http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/text/JTextComponent.html#setCaretPosition(int)<http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/text/JTextComponent.html#setCaretPosition%28int%29>
> >
> > with a value of 0 after setting the text?
>
>
>
> exactly,
>
> But what better place to do this than in a FormComponentInterceptor?
>
>
>
> Rogan
> >
> > -------------------------------------------------------------------------
> >
> > 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] Position of caret for readonly fields

[Peter De B. <pet...@gm...>]

On 9/7/07, Rogan Dawes <ro...@da...> wrote:
>
> Andy DePue wrote:
> >   If this is a Swing "feature", then I'm not aware of a simple setting
> > somewhere (maybe someone else knows of one?).  I do know that
> > DefaultCaret has a setUpdatePolicy method.  You would have to get the
> > Caret from the JTextField, make sure it is a DefaultCaret, cast it to
> > DefaultCaret, and invoke setUpdatePolicy(DefaultCaret.NEVER_UPDATE).
> > Even then, I haven't tested this, so I'm not sure if it would have the
> > desired effect.  Another approach would be to implement a
> > FormComponentInterceptor that automatically handles any JTextField that
> > is not enabled so that the caret it always placed at the beginning of
> > the field.  See SelectAllFormComponentInterceptorFactory for an example
> > of what an interceptor looks like.
> >
> >   - Andy
>
> How about calling
>
> http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/text/JTextComponent.html#setCaretPosition(int)
>
> with a value of 0 after setting the text?



exactly,

But what better place to do this than in a FormComponentInterceptor?



Rogan
>
> -------------------------------------------------------------------------
> 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] Position of caret for readonly fields

[Rogan D. <ro...@da...>]

Andy DePue wrote:
>   If this is a Swing "feature", then I'm not aware of a simple setting 
> somewhere (maybe someone else knows of one?).  I do know that 
> DefaultCaret has a setUpdatePolicy method.  You would have to get the 
> Caret from the JTextField, make sure it is a DefaultCaret, cast it to 
> DefaultCaret, and invoke setUpdatePolicy(DefaultCaret.NEVER_UPDATE).  
> Even then, I haven't tested this, so I'm not sure if it would have the 
> desired effect.  Another approach would be to implement a 
> FormComponentInterceptor that automatically handles any JTextField that 
> is not enabled so that the caret it always placed at the beginning of 
> the field.  See SelectAllFormComponentInterceptorFactory for an example 
> of what an interceptor looks like.
> 
>   - Andy

How about calling 
http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/text/JTextComponent.html#setCaretPosition(int)

with a value of 0 after setting the text?

Rogan