Menu
▾
▴
springframework-rcp-dev — Spring Rich Client developer list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(37) |
Jun
(141) |
Jul
(111) |
Aug
(91) |
Sep
(79) |
Oct
(151) |
Nov
(161) |
Dec
(93) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(40) |
Feb
(60) |
Mar
(43) |
Apr
(90) |
May
(31) |
Jun
(114) |
Jul
(35) |
Aug
(112) |
Sep
(305) |
Oct
(151) |
Nov
(122) |
Dec
(103) |
| 2006 |
Jan
(65) |
Feb
(57) |
Mar
(475) |
Apr
(276) |
May
(482) |
Jun
(134) |
Jul
(127) |
Aug
(188) |
Sep
(271) |
Oct
(220) |
Nov
(74) |
Dec
(41) |
| 2007 |
Jan
(121) |
Feb
(50) |
Mar
(36) |
Apr
(11) |
May
(31) |
Jun
(12) |
Jul
(73) |
Aug
(41) |
Sep
(59) |
Oct
(33) |
Nov
(60) |
Dec
(111) |
| 2008 |
Jan
(139) |
Feb
(49) |
Mar
(87) |
Apr
(43) |
May
(10) |
Jun
(25) |
Jul
(114) |
Aug
(17) |
Sep
(25) |
Oct
(199) |
Nov
(94) |
Dec
(45) |
| 2009 |
Jan
(36) |
Feb
(14) |
Mar
(29) |
Apr
(32) |
May
(49) |
Jun
(18) |
Jul
(68) |
Aug
(34) |
Sep
(34) |
Oct
(11) |
Nov
(10) |
Dec
(14) |
| 2010 |
Jan
(35) |
Feb
(12) |
Mar
(23) |
Apr
(17) |
May
(4) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
|
Nov
(10) |
Dec
|
| 2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
(8) |
Apr
(3) |
May
|
Jun
|
Jul
(4) |
Aug
(3) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(8) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(3) |
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
(1) |
May
(5) |
Jun
(1) |
Jul
(13) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(15) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-21 13:22:17
|
FormComponentInterceptor.processLabel is never called
-----------------------------------------------------
Key: RCP-494
URL: http://opensource.atlassian.com/projects/spring/browse/RCP-494
Project: Spring Framework Rich Client Project
Issue Type: Bug
Components: Binding System
Reporter: Peter De Bruycker
Assignee: Peter De Bruycker
FormComponentInterceptor.processLabel is never called
should be called from AbstractFormBuilder.createLabelFor method
--
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
|
|
From: Andy D. <an...@ma...> - 2007-10-19 17:26:24
|
Wow, I applied for a license and they sent one to me within 10 minutes for "Spring Richclient". - Andy Geoffrey De Smet wrote: > Andy, > > I 've requested a license for my work on drools-solver and > spring-richclient this morning. > They've already send me a license now, but it's noted to "JBoss drools", > so I can't share it with you, only drools committers :( > But just request a license, they don't seem to make a fuss about giving > one :) > > With kind regards, > Geoffrey De Smet > > > Andy DePue wrote: > >> I'm thinking about applying for an open source license for IntelliJ IDEA >> 7 for the Spring Richclient project. Has anyone here does this? Should >> I initiate this request, or is there another path for Spring related >> projects? >> >> Thanks, >> Andy >> >> >> ------------------------------------------------------------------------- >> 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/ >> > > > ------------------------------------------------------------------------- > 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 > > . > > |
|
From: Geoffrey De S. <ge0...@gm...> - 2007-10-19 15:37:25
|
Andy, I 've requested a license for my work on drools-solver and spring-richclient this morning. They've already send me a license now, but it's noted to "JBoss drools", so I can't share it with you, only drools committers :( But just request a license, they don't seem to make a fuss about giving one :) With kind regards, Geoffrey De Smet Andy DePue wrote: > I'm thinking about applying for an open source license for IntelliJ IDEA > 7 for the Spring Richclient project. Has anyone here does this? Should > I initiate this request, or is there another path for Spring related > projects? > > Thanks, > Andy > > > ------------------------------------------------------------------------- > 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/ |
|
From: Andy D. <an...@ma...> - 2007-10-18 18:22:20
|
I'm thinking about applying for an open source license for IntelliJ IDEA 7 for the Spring Richclient project. Has anyone here does this? Should I initiate this request, or is there another path for Spring related projects? Thanks, Andy |
|
From: Benoit X. (JIRA) <no...@at...> - 2007-10-11 17:00:04
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_26868 ]
Benoit Xhenseval commented on RCP-493:
--------------------------------------
Hi
I have noticed this Bug on the Sun website... it seems related:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4464162
I think that the exception should be caught and dealt in TextComponentPopup.
> cannot open system clipboard
> ----------------------------
>
> Key: RCP-493
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-493
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Affects Versions: 0.3.0
> Environment: Windows, JRE 1.5.0_12
> Reporter: Benoit Xhenseval
>
> Hi All,
> From time to time, switching back to a Spring RC window (ALT+TAB) from another Windows application seems to trigger this exception:
> java.lang.IllegalStateException: cannot open system clipboard
> I have not been able to reproduce this issue reliably, it happens from time to time.
> The stacktrace seems to be entirely in SpringRC/Swing.
> The issue faced is that the exception is thrown all the way to the user and there is no known things that I could do to remediate it. Furthermore, this does not seem to affect the application at all... so my suggestion would be to catch this exception in TextComponentPopup and simply log a warning?
> I know it would be better to find the root cause but that seems to be between Windows and the JRE...
> Has anyone seen this?
> java.lang.IllegalStateException: cannot open system clipboard
> java.lang.IllegalStateException: cannot open system clipboard
> at sun.awt.windows.WClipboard.openClipboard(Native Method)
> at sun.awt.datatransfer.ClipboardTransferable.(ClipboardTransferable.java:61)
> at sun.awt.datatransfer.SunClipboard.getContents(SunClipboard.java:130)
> at org.springframework.richclient.text.TextComponentPopup.canPasteFromClipboard
> (TextComponentPopup.java:261)
> at org.springframework.richclient.text.TextComponentPopup.updatePasteStatus(TextComponentPopup.java:253)
> at org.springframework.richclient.text.TextComponentPopup.access$2
> (TextComponentPopup.java:252)
> at org.springframework.richclient.text.TextComponentPopup$1.actionPerformed(TextComponentPopup.java:106)
> at javax.swing.Timer.fireActionPerformed(Timer.java
> :271)
> at javax.swing.Timer$DoPostEvent.run(Timer.java:201)
> 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 java.awt.EventDispatchThread.run
> (EventDispatchThread.java:110)
--
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
|
|
From: Benoit X. (JIRA) <no...@at...> - 2007-10-11 09:15:04
|
cannot open system clipboard
----------------------------
Key: RCP-493
URL: http://opensource.atlassian.com/projects/spring/browse/RCP-493
Project: Spring Framework Rich Client Project
Issue Type: Bug
Affects Versions: 0.3.0
Environment: Windows, JRE 1.5.0_12
Reporter: Benoit Xhenseval
Hi All,
>From time to time, switching back to a Spring RC window (ALT+TAB) from another Windows application seems to trigger this exception:
java.lang.IllegalStateException: cannot open system clipboard
I have not been able to reproduce this issue reliably, it happens from time to time.
The stacktrace seems to be entirely in SpringRC/Swing.
The issue faced is that the exception is thrown all the way to the user and there is no known things that I could do to remediate it. Furthermore, this does not seem to affect the application at all... so my suggestion would be to catch this exception in TextComponentPopup and simply log a warning?
I know it would be better to find the root cause but that seems to be between Windows and the JRE...
Has anyone seen this?
java.lang.IllegalStateException: cannot open system clipboard
java.lang.IllegalStateException: cannot open system clipboard
at sun.awt.windows.WClipboard.openClipboard(Native Method)
at sun.awt.datatransfer.ClipboardTransferable.(ClipboardTransferable.java:61)
at sun.awt.datatransfer.SunClipboard.getContents(SunClipboard.java:130)
at org.springframework.richclient.text.TextComponentPopup.canPasteFromClipboard
(TextComponentPopup.java:261)
at org.springframework.richclient.text.TextComponentPopup.updatePasteStatus(TextComponentPopup.java:253)
at org.springframework.richclient.text.TextComponentPopup.access$2
(TextComponentPopup.java:252)
at org.springframework.richclient.text.TextComponentPopup$1.actionPerformed(TextComponentPopup.java:106)
at javax.swing.Timer.fireActionPerformed(Timer.java
:271)
at javax.swing.Timer$DoPostEvent.run(Timer.java:201)
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 java.awt.EventDispatchThread.run
(EventDispatchThread.java:110)
--
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
|
|
From: Andy D. (JIRA) <no...@at...> - 2007-10-10 22:21:01
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy DePue closed RCP-492.
--------------------------
Resolution: Fixed
Fix committed (revision 1822). The overlay will be removed from the JRootPane's JLayeredPane when the target component is removed from the JRootPane's hierarchy. Fix includes regression test.
> OverlayHelper causes memory leak
> --------------------------------
>
> Key: RCP-492
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-492
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Components: Binding System
> Affects Versions: 0.1.0, 0.2.0, 0.2.1, 0.3.0
> Reporter: Andy DePue
> Assignee: Andy DePue
> Fix For: 0.3.0
>
>
> OverlayHelper causes a memory leak as follows:
> 1. When it is attached to a component, it finds an "overlay capable parent" of the component. In newer versions, this is always the JRootPane of the window. In older version of Spring Rich, the leak would surface when the component was not placed in a scrollpane.
> 2. It adds the overlay component to the JLayeredPane of this JRootPane.
> 3. It adds a listener, which happens to be an inner class, to the overlay component. Because the listener is an inner class, it maintains a hidden strong reference to the surrounding OverlayHelper instance.
> 4. The surrounding OverlayHelper instance holds a reference to the component receiving the overlay. This component is part of the form, so there is now a chain of strong references going from the JRootPane of your main window all the way to your whole form UI component hierarchy.
> 5. Close or navigate away from the form. Remove all references to the form. Think you are done with it and surely it will be GCed.
> 6. There is no code in OverlayHelper to remove the overlay from the JLayeredPane once the form is removed from the window, so not only does the JLayeredPane become cluttered with overlays, it also maintains strong references to all your form UIs.
> Note, if you never dispose of your form UIs, and reuse them (keeping them all in memory once loaded), then this probably isn't an issue for you. Otherwise, you eventually run out of memory.
> I'm going to look into fixing this myself, by having the OverlayHelper remove the overlay once the component it is attached to is removed from the JRootPane hierarchy.
--
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
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-10-10 20:05:59
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-481?page=
=3Dcom.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_=
26847 ]=20
Peter De Bruycker commented on RCP-481:
---------------------------------------
I cannot reproduce this behaviour. What exceptions did you have in your spr=
ing xml configuration?
> Exceptions disappear in ApplicationLauncher
> -------------------------------------------
>
> Key: RCP-481
> URL: http://opensource.atlassian.com/projects/spring/brow=
se/RCP-481
> Project: Spring Framework Rich Client Project
> Issue Type: Improvement
> Components: Application Framework
> Affects Versions: 0.3.0
> Reporter: Theo G=C3=BClcher
> Assignee: Peter De Bruycker
> Priority: Trivial
>
> http://forum.springframework.org/showthread.php?t=3D40931
> -------------------------------------------------------------------------=
--------
> Hi,
> I discovered some strange behavior at startup of my application. After th=
e splash screen became visible it suddenly disappeared and I did not see an=
y exception.
> I discovered that the following piece of code was responsible for hiding =
any exceptions:
> Code:
> public ApplicationLauncher(String startupContextPath, String[] rootCo=
ntextConfigLocations) {
> .....
> .....
> try {
> setRootApplicationContext(loadRootApplicationContext(rootCont=
extConfigLocations, startupContext));
> launchMyRichClient();
> }
> finally {
> destroySplashScreen();
> }
> }
> I think this code is very wrong, because any exceptions in the try block =
would just be swallowed without showing an exception in your console or log=
file, so I added a catch block, like this:
> Code:
> public ApplicationLauncher(String startupContextPath, String[] rootCo=
ntextConfigLocations) {
> .....
> .....
> try {
> setRootApplicationContext(loadRootApplicationContext(rootCont=
extConfigLocations, startupContext));
> launchMyRichClient();
> }
> catch (Exception e) {
> logger.error("Application launcher", e);
> }
> finally {
> destroySplashScreen();
> }
> }
> After that I discovered I had some exceptions in my spring xml configurat=
ion.
> Maybe a good idea if any of the contributors/submitters would change this=
in SVN?
> Thanks in advance,
> Theo.
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Andy D. (JIRA) <no...@at...> - 2007-10-10 19:47:03
|
OverlayHelper causes memory leak
--------------------------------
Key: RCP-492
URL: http://opensource.atlassian.com/projects/spring/browse/RCP-492
Project: Spring Framework Rich Client Project
Issue Type: Bug
Components: Binding System
Affects Versions: 0.2.1, 0.2.0, 0.1.0, 0.3.0
Reporter: Andy DePue
Assignee: Andy DePue
Fix For: 0.3.0
OverlayHelper causes a memory leak as follows:
1. When it is attached to a component, it finds an "overlay capable parent" of the component. In newer versions, this is always the JRootPane of the window. In older version of Spring Rich, the leak would surface when the component was not placed in a scrollpane.
2. It adds the overlay component to the JLayeredPane of this JRootPane.
3. It adds a listener, which happens to be an inner class, to the overlay component. Because the listener is an inner class, it maintains a hidden strong reference to the surrounding OverlayHelper instance.
4. The surrounding OverlayHelper instance holds a reference to the component receiving the overlay. This component is part of the form, so there is now a chain of strong references going from the JRootPane of your main window all the way to your whole form UI component hierarchy.
5. Close or navigate away from the form. Remove all references to the form. Think you are done with it and surely it will be GCed.
6. There is no code in OverlayHelper to remove the overlay from the JLayeredPane once the form is removed from the window, so not only does the JLayeredPane become cluttered with overlays, it also maintains strong references to all your form UIs.
Note, if you never dispose of your form UIs, and reuse them (keeping them all in memory once loaded), then this probably isn't an issue for you. Otherwise, you eventually run out of memory.
I'm going to look into fixing this myself, by having the OverlayHelper remove the overlay once the component it is attached to is removed from the JRootPane hierarchy.
--
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
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-10-10 09:05:01
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker resolved RCP-320.
-----------------------------------
Resolution: Cannot Reproduce
already fixed by other changes in the code base
> 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
> Assignee: Peter De Bruycker
> 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
|
|
From: Peter De B. <pet...@gm...> - 2007-10-10 09:02:39
|
I made some changes in SimpleSplashScreen: the imageResourcePath property is no longer a String type, but a Resource type. This allows for a more flexible configuration of the splashscreen. Normally, no changes are required in the richclient-startup.xmlconfiguration file, as the spring converter mechanism takes care of this. Peter |
|
From: Peter De B. (JIRA) <no...@at...> - 2007-10-10 08:40:05
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker resolved RCP-491.
-----------------------------------
Resolution: Fixed
Fix Version/s: 0.3.0
> CommandButtonIconInfo has different behaviour for JMenu, JMenuItem and other buttons
> ------------------------------------------------------------------------------------
>
> Key: RCP-491
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-491
> Project: Spring Framework Rich Client Project
> Issue Type: Improvement
> Components: Command System
> Reporter: Peter De Bruycker
> Assignee: Peter De Bruycker
> Fix For: 0.3.0
>
> Original Estimate: 0.12d
> Remaining Estimate: 0.12d
>
> correct CommandButtonIconInfo so the behaviour is for all types of buttons the same.
--
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
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-10-10 08:40:05
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker updated RCP-491:
----------------------------------
Remaining Estimate: (was: 0.12d)
Original Estimate: (was: 0.12d)
> CommandButtonIconInfo has different behaviour for JMenu, JMenuItem and other buttons
> ------------------------------------------------------------------------------------
>
> Key: RCP-491
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-491
> Project: Spring Framework Rich Client Project
> Issue Type: Improvement
> Components: Command System
> Reporter: Peter De Bruycker
> Assignee: Peter De Bruycker
> Fix For: 0.3.0
>
>
> correct CommandButtonIconInfo so the behaviour is for all types of buttons the same.
--
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
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-10-10 08:35:59
|
CommandButtonIconInfo has different behaviour for JMenu, JMenuItem and other buttons
------------------------------------------------------------------------------------
Key: RCP-491
URL: http://opensource.atlassian.com/projects/spring/browse/RCP-491
Project: Spring Framework Rich Client Project
Issue Type: Improvement
Components: Command System
Reporter: Peter De Bruycker
Assignee: Peter De Bruycker
correct CommandButtonIconInfo so the behaviour is for all types of buttons the same.
--
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
|
|
From: Benoit X. <bx...@ob...> - 2007-10-09 21:45:40
|
Hi All, =20 I=92d hate to see this mail list polluted=85 but it is so rare to see a = job for a Spring Rich Client that some of its developers may be interested? I hope it is ok, it is not for an agency, ObjectLab Financial is my = company. =20 ObjectLab Financial recently launched its global portfolio financing product; we=92ve had a number of successful leads recently and are in = the process of signing up several clients. As such, we are recruiting and have 2 positions in London: =B7 A proficient J2EE Developer: JDK 5, EJB/POJOs, Spring, = Hibernate, JBoss, Mule, JMS, ActiveMQ, XML, JAXB etc see HYPERLINK "http://www.objectlab.co.uk/jobs/index.shtml?j2ee.inc"http://www.objectla= b.c o.uk/jobs/index.shtml?j2ee.inc =B7 A proficient Swing Developer: JDK 5, Swing, Spring 2 (Spring = Rich Client a plus), Jasper Reports, etc see HYPERLINK "http://www.objectlab.co.uk/jobs/index.shtml?swing.inc"http://www.objectl= ab. co.uk/jobs/index.shtml?swing.inc =20 Both roles should attract dedicated, hardworking developers looking for = a challenge, lots of responsibilities and rewards. They will make a = difference working amongst a friendly, delivery-focused team. =20 We will offer a competitive package that will be complemented with performance related bonuses (including stock options). =20 If you are not interested, I would be grateful if you could pass onto serious Java Developers that would fit the requirements. =20 Many thanks =20 Benoit. =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.488 / Virus Database: 269.14.5/1058 - Release Date: = 08/10/2007 16:54 =20 |
|
From: Peter De B. <pet...@gm...> - 2007-10-09 06:10:46
|
All,
A DesktopCommandGroupFactory interface and default implementation have been
introduced. This class provides support for a context menu on a JDesktopPane
(with tile, cascade and minimize all commands, and an entry for each open
window). The default implementation also has support for customizing the
cascade command (resize frames yes/no and the cascade offset).
usage:
<bean id="applicationPageFactory" class="
org.springframework.richclient.application.mdi.DesktopApplicationPageFactory
">
<property name="desktopCommandGroupFactory">
<bean class="
org.springframework.richclient.application.mdi.contextmenu.DefaultDesktopCommandGroupFactory
">
<property name="cascadeResizesFrames"
value="false"/>
</bean>
</property>
</bean>
regards,
Peter
|
|
From: Benoit X. <bx...@ob...> - 2007-10-08 21:19:03
|
Hi All,
Peter, thanks for the MinimizeAllCommand.
I was wondering how you suggest to configure the CascadeCommand to have
resizeFrame = false;
The issue is that the command is not a bean but created explicitly in
DesktopPaneContextMenuFactory
CascadeCommand cascadeCommand = new CascadeCommand( desktop );
And the DesktopPaneContextMenuFactory is itself instantiated explicitly in
DesktopApplicationPage
Any suggestion welcomed...
Best regards
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.
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Andy DePue
Sent: 08 October 2007 21:40
To: spr...@li...
Subject: Re: [Springframework-rcp-dev] CommandButtonIconInfo question
I'm all for the change myself.
- Andy
Peter De Bruycker wrote:
> If no one objects, I'm going to change the existing code in
> CommandButtonIconInfo, so if someone has a remark, please answer this
> mail.
>
>
>
> On 10/8/07, * Benoit Xhenseval* <bx...@ob...
> <mailto:bx...@ob...>> wrote:
>
> That would be great. It would also be useful to have the ability
> to have an icon at the "parent" of the sub-menu; at the moment I
> do not think that either work when there is a submenu.
>
>
> what do you mean with "the parent of the sub-menu"?
>
>
> I'm willing to test any new code on this subject
>
>
>
> great
>
> (and the "minimise all" command that, I believe, you were working on?)
>
>
> yep, still on my list
>
>
> Thanks a lot,
>
>
>
> Kind regards
>
>
>
> 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.
>
>
>
> *From:* spr...@li...
> <mailto:spr...@li...>
> [mailto:spr...@li...
> <mailto:spr...@li...>]
> *On Behalf Of *Peter De Bruycker
> *Sent:* 07 October 2007 21:18
> *To:* Spr...@li...
> <mailto:Spr...@li...>
> *Subject:* [Springframework-rcp-dev] CommandButtonIconInfo question
>
>
>
> The CommandButtonIconInfo.configure method sets the icon
> properties (icon, selectedIcon, disabledIcon, pressedIcon and
> rolloverIcon) on a command button.
>
> But there's different behaviour depending on the effective type of
> the button:
>
> On a JMenu, all icons are set to null,
> on a JMenuItem, the icon and disabledIcon are set,
> and on all other types, all icons are set.
>
> This means that when creating a popup menu with a sub menu, the
> sub menu will never have an icon.
>
> Wouldn't it be better to just set all the icons on all types of
> buttons? That way, the icons are completely configured using the
> images.properties.
>
> What do you think?
>
> Peter
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.14.4/1056 - Release Date:
> 07/10/2007 18:12
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.14.4/1056 - Release Date:
> 07/10/2007 18:12
>
>
>
-------------------------------------------------------------------------
> 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...
> <mailto:Spr...@li...>
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>
-------------------------------------------------------------------------
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
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.14.4/1056 - Release Date: 07/10/2007
18:12
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.14.4/1056 - Release Date: 07/10/2007
18:12
|
|
From: Andy D. <an...@ma...> - 2007-10-08 20:45:20
|
I've been eying ConfigurableFormModel.add(String propertyName,
ValueModel valueModel) in order to support binding components to derived
properties, but it doesn't appear "add" will work unless a property with
'propertyName' exists on the backing object. There is even a comment in
the code that says:
// XXX: this is very broken as it assumes that the added value
model was derived
// from the property access strategy when this is not always the
case.
What I'd like to do is allow someone to bind to an expression rather
than a property. Something like: binder.bindControl(control,
"${subtotal + tax + shipping}"). Internally, I'll add a custom property
to the form using the add(...) method above, with the ValueModel
computing the result of the expression, as well as listening to the
individual properties involved in the expression so that it fires a
property change event when any of the source properties change. Anyway,
if the "add(...)" method worked, this would be fairly easy to implement.
Anyone have a problem if I go in and make add(...) work on properties
that do not exist on the backing bean? Does anyone rely on add(...)
throwing an exception for non-existing properties?
- Andy
|
|
From: Andy D. <an...@ma...> - 2007-10-08 20:29:12
|
I'm all for the change myself. - Andy Peter De Bruycker wrote: > If no one objects, I'm going to change the existing code in > CommandButtonIconInfo, so if someone has a remark, please answer this > mail. > > > > On 10/8/07, * Benoit Xhenseval* <bx...@ob... > <mailto:bx...@ob...>> wrote: > > That would be great. It would also be useful to have the ability > to have an icon at the "parent" of the sub-menu; at the moment I > do not think that either work when there is a submenu. > > > what do you mean with "the parent of the sub-menu"? > > > I'm willing to test any new code on this subject > > > > great > > (and the "minimise all" command that, I believe, you were working on?) > > > yep, still on my list > > > Thanks a lot, > > > > Kind regards > > > > 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. > > > > *From:* spr...@li... > <mailto:spr...@li...> > [mailto:spr...@li... > <mailto:spr...@li...>] > *On Behalf Of *Peter De Bruycker > *Sent:* 07 October 2007 21:18 > *To:* Spr...@li... > <mailto:Spr...@li...> > *Subject:* [Springframework-rcp-dev] CommandButtonIconInfo question > > > > The CommandButtonIconInfo.configure method sets the icon > properties (icon, selectedIcon, disabledIcon, pressedIcon and > rolloverIcon) on a command button. > > But there's different behaviour depending on the effective type of > the button: > > On a JMenu, all icons are set to null, > on a JMenuItem, the icon and disabledIcon are set, > and on all other types, all icons are set. > > This means that when creating a popup menu with a sub menu, the > sub menu will never have an icon. > > Wouldn't it be better to just set all the icons on all types of > buttons? That way, the icons are completely configured using the > images.properties. > > What do you think? > > Peter > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.488 / Virus Database: 269.14.4/1056 - Release Date: > 07/10/2007 18:12 > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.488 / Virus Database: 269.14.4/1056 - Release Date: > 07/10/2007 18:12 > > > ------------------------------------------------------------------------- > 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... > <mailto:Spr...@li...> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 > |
|
From: Peter De B. <pet...@gm...> - 2007-10-08 18:14:51
|
If no one objects, I'm going to change the existing code in CommandButtonIconInfo, so if someone has a remark, please answer this mail. On 10/8/07, Benoit Xhenseval <bx...@ob...> wrote: > > That would be great. It would also be useful to have the ability to have > an icon at the "parent" of the sub-menu; at the moment I do not think that > either work when there is a submenu. > what do you mean with "the parent of the sub-menu"? I'm willing to test any new code on this subject > great (and the "minimise all" command that, I believe, you were working on?) > yep, still on my list Thanks a lot, > > > > Kind regards > > > > 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. > > > > *From:* spr...@li... [mailto: > spr...@li...] *On Behalf Of *Peter > De Bruycker > *Sent:* 07 October 2007 21:18 > *To:* Spr...@li... > *Subject:* [Springframework-rcp-dev] CommandButtonIconInfo question > > > > The CommandButtonIconInfo.configure method sets the icon properties (icon, > selectedIcon, disabledIcon, pressedIcon and rolloverIcon) on a command > button. > > But there's different behaviour depending on the effective type of the > button: > > On a JMenu, all icons are set to null, > on a JMenuItem, the icon and disabledIcon are set, > and on all other types, all icons are set. > > This means that when creating a popup menu with a sub menu, the sub menu > will never have an icon. > > Wouldn't it be better to just set all the icons on all types of buttons? > That way, the icons are completely configured using the images.properties. > > What do you think? > > Peter > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.488 / Virus Database: 269.14.4/1056 - Release Date: > 07/10/2007 18:12 > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.488 / Virus Database: 269.14.4/1056 - Release Date: > 07/10/2007 18:12 > > ------------------------------------------------------------------------- > 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 > > |
|
From: Benoit X. <bx...@ob...> - 2007-10-08 16:08:31
|
That would be great. It would also be useful to have the ability to have = an icon at the =93parent=94 of the sub-menu; at the moment I do not think = that either work when there is a submenu. =20 I=92m willing to test any new code on this subject (and the =93minimise all=94 command that, I believe, you were working = on?) =20 Thanks a lot, =20 Kind regards =20 Benoit =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 From: spr...@li... [mailto:spr...@li...] On Behalf = Of Peter De Bruycker Sent: 07 October 2007 21:18 To: Spr...@li... Subject: [Springframework-rcp-dev] CommandButtonIconInfo question =20 The CommandButtonIconInfo.configure method sets the icon properties = (icon, selectedIcon, disabledIcon, pressedIcon and rolloverIcon) on a command button. But there's different behaviour depending on the effective type of the button:=20 On a JMenu, all icons are set to null, on a JMenuItem, the icon and disabledIcon are set, and on all other types, all icons are set. This means that when creating a popup menu with a sub menu, the sub menu will never have an icon.=20 Wouldn't it be better to just set all the icons on all types of buttons? That way, the icons are completely configured using the = images.properties. What do you think? Peter No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.4/1056 - Release Date: = 07/10/2007 18:12 No virus found in this outgoing message. Checked by AVG Free Edition.=20 Version: 7.5.488 / Virus Database: 269.14.4/1056 - Release Date: = 07/10/2007 18:12 =20 |
|
From: Peter De B. <pet...@gm...> - 2007-10-07 20:18:31
|
The CommandButtonIconInfo.configure method sets the icon properties (icon, selectedIcon, disabledIcon, pressedIcon and rolloverIcon) on a command button. But there's different behaviour depending on the effective type of the button: On a JMenu, all icons are set to null, on a JMenuItem, the icon and disabledIcon are set, and on all other types, all icons are set. This means that when creating a popup menu with a sub menu, the sub menu will never have an icon. Wouldn't it be better to just set all the icons on all types of buttons? That way, the icons are completely configured using the images.properties. What do you think? Peter |
|
From: Andy D. <an...@ma...> - 2007-10-05 20:12:25
|
You are correct! Yes, the error message should still appear at the top AND the form should not be committable, but the "x" overlay should not appear. - Andy Peter De Bruycker wrote: > Andy, > > Just to make sure we're on the same track: > > 1. there are some custom components that you want exclude from the > overlay mechanism > 2. there are certain (type of) constraints that you always want to > exclude from the overlay mechanism -> do you still want the error > message to show at the top of the dialog?? > > Peter > > On 10/4/07, *Andy DePue* <an...@ma... > <mailto:an...@ma...>> wrote: > > Thanks for the response, Peter. Your assumption is correct (no > overlay > on custom component). However, I just ran into a new case today where > we have a certain type of validation that we want to always work > in this > way (validation error, but no "x"). I'm thinking the only way to > accomplish this would be to add some sort of flag to the validation > message itself? > > > > That would be difficult. The validation message is just that: a message. > > > - Andy > > > Peter De Bruycker wrote: > > Andy, > > > > I assume you're talking about custom components that you want to > > exclude from the x-overlays. > > > > In that case, I would go for the client property on the component. > > > > Define a String > > OverlayValidationInterceptorFactory.DONT_OVERLAY_PROPERTY constant > > > > then you can do the following in your form: > > > > customComponent = ...; > > > customComponent.putClientProperty(OverlayValidationInterceptorFactory.DONT_OVERLAY_PROPERTY, > > Boolean.TRUE ); > > > > then we can adapt the OverlayValidationInterceptor to ignore > > components that have this property set tot true. > > > > What do you think? > > > > Peter > > > > On 10/3/07, *Andy DePue* < an...@ma... > <mailto:an...@ma...> > > <mailto:an...@ma... <mailto:an...@ma...>>> > wrote: > > > > Hello all, > > As you know, if you have a form with a validation error > then you > > get a > > really cool little "x" in the corner of the component with > the error. > > However, I have some rather complex forms and there are some > > validations > > where I do not desire the little "x" error indicator on the > component > > itself. I want the validation error to prevent the user from > > committing, just like it does now, and I also want the error > > message in > > the top of the form, but I do not want the "x" on the > component. > > I'm thinking about implementing a mechanism where you can > tell the > > overlay helper not to "x" particular fields. Does anyone > else see > > this > > as a good idea? If so, would it make more sense to put the > flag on a > > field basis (maybe a flag in FieldMetadata or a userMetadata), a > > validation-type basis (certain validations do not produce > the 'x' - > > maybe a new validation error type), or a component basis (a > particular > > client property on the component)? OR, maybe this functionality > > already > > exists, and I just don't know about it? :) > > > > Thanks, > > Andy > > > > > > > ------------------------------------------------------------------------- > > 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... > <mailto:Spr...@li...> > > <mailto:Spr...@li... > <mailto:Spr...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > > > > > ------------------------------------------------------------------------ > > > > > > ------------------------------------------------------------------------- > > 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... > <mailto:Spr...@li...> > > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > > ------------------------------------------------------------------------- > 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... > <mailto:Spr...@li...> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 > |
|
From: Peter De B. <pet...@gm...> - 2007-10-05 08:00:51
|
Andy, Just to make sure we're on the same track: 1. there are some custom components that you want exclude from the overlay mechanism 2. there are certain (type of) constraints that you always want to exclude from the overlay mechanism -> do you still want the error message to show at the top of the dialog?? Peter On 10/4/07, Andy DePue <an...@ma...> wrote: > > Thanks for the response, Peter. Your assumption is correct (no overlay > on custom component). However, I just ran into a new case today where > we have a certain type of validation that we want to always work in this > way (validation error, but no "x"). I'm thinking the only way to > accomplish this would be to add some sort of flag to the validation > message itself? That would be difficult. The validation message is just that: a message. - Andy > > > Peter De Bruycker wrote: > > Andy, > > > > I assume you're talking about custom components that you want to > > exclude from the x-overlays. > > > > In that case, I would go for the client property on the component. > > > > Define a String > > OverlayValidationInterceptorFactory.DONT_OVERLAY_PROPERTY constant > > > > then you can do the following in your form: > > > > customComponent = ...; > > customComponent.putClientProperty( > OverlayValidationInterceptorFactory.DONT_OVERLAY_PROPERTY, > > Boolean.TRUE); > > > > then we can adapt the OverlayValidationInterceptor to ignore > > components that have this property set tot true. > > > > What do you think? > > > > Peter > > > > On 10/3/07, *Andy DePue* <an...@ma... > > <mailto:an...@ma...>> wrote: > > > > Hello all, > > As you know, if you have a form with a validation error then you > > get a > > really cool little "x" in the corner of the component with the > error. > > However, I have some rather complex forms and there are some > > validations > > where I do not desire the little "x" error indicator on the > component > > itself. I want the validation error to prevent the user from > > committing, just like it does now, and I also want the error > > message in > > the top of the form, but I do not want the "x" on the component. > > I'm thinking about implementing a mechanism where you can tell the > > overlay helper not to "x" particular fields. Does anyone else see > > this > > as a good idea? If so, would it make more sense to put the flag on > a > > field basis (maybe a flag in FieldMetadata or a userMetadata), a > > validation-type basis (certain validations do not produce the 'x' - > > maybe a new validation error type), or a component basis (a > particular > > client property on the component)? OR, maybe this functionality > > already > > exists, and I just don't know about it? :) > > > > Thanks, > > Andy > > > > > > > ------------------------------------------------------------------------- > > 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... > > <mailto:Spr...@li...> > > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > 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 > > > > ------------------------------------------------------------------------- > 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 > |
|
From: Andy D. <an...@ma...> - 2007-10-04 15:26:27
|
Thanks for the response, Peter. Your assumption is correct (no overlay on custom component). However, I just ran into a new case today where we have a certain type of validation that we want to always work in this way (validation error, but no "x"). I'm thinking the only way to accomplish this would be to add some sort of flag to the validation message itself? - Andy Peter De Bruycker wrote: > Andy, > > I assume you're talking about custom components that you want to > exclude from the x-overlays. > > In that case, I would go for the client property on the component. > > Define a String > OverlayValidationInterceptorFactory.DONT_OVERLAY_PROPERTY constant > > then you can do the following in your form: > > customComponent = ...; > customComponent.putClientProperty(OverlayValidationInterceptorFactory.DONT_OVERLAY_PROPERTY, > Boolean.TRUE); > > then we can adapt the OverlayValidationInterceptor to ignore > components that have this property set tot true. > > What do you think? > > Peter > > On 10/3/07, *Andy DePue* <an...@ma... > <mailto:an...@ma...>> wrote: > > Hello all, > As you know, if you have a form with a validation error then you > get a > really cool little "x" in the corner of the component with the error. > However, I have some rather complex forms and there are some > validations > where I do not desire the little "x" error indicator on the component > itself. I want the validation error to prevent the user from > committing, just like it does now, and I also want the error > message in > the top of the form, but I do not want the "x" on the component. > I'm thinking about implementing a mechanism where you can tell the > overlay helper not to "x" particular fields. Does anyone else see > this > as a good idea? If so, would it make more sense to put the flag on a > field basis (maybe a flag in FieldMetadata or a userMetadata), a > validation-type basis (certain validations do not produce the 'x' - > maybe a new validation error type), or a component basis (a particular > client property on the component)? OR, maybe this functionality > already > exists, and I just don't know about it? :) > > Thanks, > Andy > > > ------------------------------------------------------------------------- > 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... > <mailto:Spr...@li...> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 > |
406 messages has been excluded from this view by a project administrator.
