springframework-rcp-dev — Spring Rich Client developer list

Re: [Springframework-rcp-dev] Optional error validation overlay

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

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_PROPERTYconstant

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...> 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...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] Optional error validation overlay

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

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

[Springframework-rcp-dev] [Spring-JIRA] Resolved: (RCP-461) provide close() method on View

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

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

Peter De Bruycker resolved RCP-461.
-----------------------------------

    Resolution: Fixed

checked in

> provide close() method on View
> ------------------------------
>
>                 Key: RCP-461
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-461
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Application Framework
>    Affects Versions: 0.2.1
>            Reporter: Peter De Bruycker
>            Assignee: Peter De Bruycker
>             Fix For: 0.3.0
>
>
> provide a close() method on View. This will allow for programmatic closing of a view.

-- 
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] Thanks for applying patch to ExtTabbedPane.

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

Hi Peter,

=20

Thanks for applying the patch.

=20

I have a related question for you, yesterday I just tried to customize =
the
title on tabs in such a way that the selected one is displayed in bold =
(yes,
it is one of my crazy user requirements).

=20

I=92ve found it surprisingly convoluted=85

1/ that is why I needed the getTab(..)

2/ even with that how do you detect what is actually selected?
(TabbedDialogPage.getActivePage() returns the page behind the tab =
number, it
is not taking into account the visibility).

3/ there is no single method to override when a tab is simply selected
(something like onTabSelected(Tab tab, Boolean selected) would be =
great=85

     I=92ve found that the TabbedDialogPage uses a =
DefaultSingleSelectionModel
but that calls only the =91super=92 class setActivePage, so I could not =
override
that=85

=20

Simple problem=85 detecting a tab selection in order to change the =
title=85

=20

Would you have some suggestions? Is it something that you=92d consider =
adding
to the TabbedDialogPage?

=20

Many thanks

Tot ziens,

=20

Benoit.

=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.488 / Virus Database: 269.13.33/1034 - Release Date: =
27/09/2007
17:00
=20

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-258) Hide titlebar, edit border etc of PageComponentPane

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

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

Peter De Bruycker closed RCP-258.
---------------------------------

    Resolution: Duplicate

> Hide titlebar, edit border etc of PageComponentPane
> ---------------------------------------------------
>
>                 Key: RCP-258
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-258
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Application Framework
>            Reporter: Kees de Kooter
>            Assignee: Oliver Hutchison
>
> I want to be able to configure the titlebar, border, margin etc. of the page container panel, without having to create my own subclasses.

-- 
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-123) From mailing list: Shadow toolbar icon

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

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

Peter De Bruycker resolved RCP-123.
-----------------------------------

    Resolution: Fixed

checked in.

The ToolBarCommandButtonConfigurer has an extra property: enableShadow: if set to true, a shadow effect is applied to the icons on mouse rollover

> From mailing list: Shadow toolbar icon
> --------------------------------------
>
>                 Key: RCP-123
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-123
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Peter De Bruycker
>            Assignee: Peter De Bruycker
>            Priority: Minor
>
> Add support for shadow tool bar icons:
> http://forum.springframework.org/viewtopic.php?t=6096

-- 
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-136) The ConfirmationDialog is not packed.

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

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

Peter De Bruycker resolved RCP-136.
-----------------------------------

    Resolution: Cannot Reproduce

unable to reproduce: probably already fixed

> The ConfirmationDialog is not packed.
> -------------------------------------
>
>                 Key: RCP-136
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-136
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>            Reporter: Matthew Wilson
>            Assignee: Peter De Bruycker
>            Priority: Minor
>         Attachments: dialog-not-packed.jpg
>
>
> When using the ConfirmationDialog, pack is not called on the frame.

-- 
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-59) Add callback to ApplicationLifecycleAdvisor for the shutdown stage of an application

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

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

Peter De Bruycker resolved RCP-59.
----------------------------------

    Resolution: Fixed

patch applied

> Add callback to ApplicationLifecycleAdvisor for the shutdown stage of an application
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-59
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-59
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Calvin Yu
>            Assignee: Peter De Bruycker
>            Priority: Minor
>         Attachments: Application.java.patch, ApplicationLifecycleAdvisor.java.patch
>
>
> There are currently two ways to ensure extra processing is done before an application is shutdown: 1) in ApplicationLifecycleAdvisor.onPreWindowClose(), and by 2) overriding Application.close().  Both options are sub-optimal solutions because you still have to check that all windows are closed before doing processing.
> There should be an extra onPreShutdown() method in the ApplicationLifecycleAdvisor class for this use.

-- 
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-111) Text and icon in toolbar

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

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

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

new classes introduced:

MenuItemButtonConfigurer
ToolBarButtonConfigurer
PullDownMenuButtonConfigurer

DefaultCommandServices works with these new classes.

The ToolBarButtonConfigurer has properties to customize text placement:
showText: default false
textBelowIcon: default true: show text below the icon, of next to it

if showText is false, and there's no icon, the text WILL be shown (does this behaviour have to change?)


To use this: inject a DefaultCommandServices bean into your ApplicationServices, and inject the customized ToolBarButtonConfigurer into the DefaultCommandServices.

> Text and icon in toolbar
> ------------------------
>
>                 Key: RCP-111
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-111
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>            Reporter: Claudio Romano
>            Assignee: Peter De Bruycker
>            Priority: Minor
>
> The toolbar should be customisable thru the properties framework to show text or icon or both.
> Link to discussion thread:
> http://forum.springframework.org/viewtopic.php?t=4018

-- 
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-111) Text and icon in toolbar

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

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

Peter De Bruycker resolved RCP-111.
-----------------------------------

    Resolution: Fixed

> Text and icon in toolbar
> ------------------------
>
>                 Key: RCP-111
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-111
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>            Reporter: Claudio Romano
>            Assignee: Peter De Bruycker
>            Priority: Minor
>
> The toolbar should be customisable thru the properties framework to show text or icon or both.
> Link to discussion thread:
> http://forum.springframework.org/viewtopic.php?t=4018

-- 
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-483) missing to remove view from ApplicationEventMulticaster when view is closed

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

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

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

if we add code to remove the view from the ApplicationEventMulticaster, the best place would be AbstractApplicationPage.

The code to add the view as an application listener is in DefaultViewDescriptor.createView method.

Wouldn't it be better if this code is also moved to AbstractApplicationPage (i.e. the createPageComponent method)?

> missing to remove view from ApplicationEventMulticaster when view is closed
> ---------------------------------------------------------------------------
>
>                 Key: RCP-483
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-483
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>            Reporter: Christian Heilmann
>            Priority: Critical
>
> In DefaultViewDescriptor.createView() the view is added to the ApplicationEventMulticaster (ApplicationEventMulticaster.addApplicationListener(view)) as Listener.
> But when closing the view, it is missing to remove the view from the ApplicationEventMulticaster (ApplicationEventMulticaster.removeApplicationListener(view)).
> Please remove the view from the ApplicationEventMulticaster when it is closed.

-- 
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-489) start Application / showPage() should be called on EDT

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

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

Peter De Bruycker resolved RCP-489.
-----------------------------------

    Resolution: Cannot Reproduce

> start Application / showPage() should be called on EDT
> ------------------------------------------------------
>
>                 Key: RCP-489
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-489
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Application Framework
>            Reporter: Christian Heilmann
>            Assignee: Peter De Bruycker
>            Priority: Minor
>
> The ApplicationLauncher should start the Application on the EDT or the showPage()-Method should be called the first time on the EDT.
> On Views it is often the case that in onFocusGained() you make a asynchronous remote-call to get the data to set in the model in the view.
> So it is a good thing, to put some Assert.isTrue(SwingUtilities.isisEventDispatchThread()) in your Views, to check, that the model or gui-components are never changed outside the EDT.
> But now the check in Views is the first-time not possible, because the Lifecycle-Methods of the Views are called the first time, when the Application is starting, outside the EDT.

-- 
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-489) start Application / showPage() should be called on EDT

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

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

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

Are you sure you are working with the latest code?

I checked it, and the application is started on the EDT:

in ApplicationLauncher.launchMyRichClient application.start() is called using SwingUtilities.invokeLater

hope this helps,

Peter

> start Application / showPage() should be called on EDT
> ------------------------------------------------------
>
>                 Key: RCP-489
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-489
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Application Framework
>            Reporter: Christian Heilmann
>            Assignee: Peter De Bruycker
>            Priority: Minor
>
> The ApplicationLauncher should start the Application on the EDT or the showPage()-Method should be called the first time on the EDT.
> On Views it is often the case that in onFocusGained() you make a asynchronous remote-call to get the data to set in the model in the view.
> So it is a good thing, to put some Assert.isTrue(SwingUtilities.isisEventDispatchThread()) in your Views, to check, that the model or gui-components are never changed outside the EDT.
> But now the check in Views is the first-time not possible, because the Lifecycle-Methods of the Views are called the first time, when the Application is starting, outside the EDT.

-- 
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-490) Issue in ExtTabbedPane if the title change for a Tab placed after an invisible one

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

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

Peter De Bruycker resolved RCP-490.
-----------------------------------

    Resolution: Fixed

patch applied

> Issue in ExtTabbedPane if the title change for a Tab placed after an invisible one
> ----------------------------------------------------------------------------------
>
>                 Key: RCP-490
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-490
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>            Reporter: Benoit Xhenseval
>            Assignee: Peter De Bruycker
>         Attachments: ExtTabbedPane-patch.txt
>
>
> Hi,
> This is probably something for Peter.
> I'm using the TabbedDialogPage and ExtTabbedPane (cheers Peter) and I think that I've found a bug.
> When the title changes (say due to a page complete event), the propertyChangeHandler is called in ExtTabbedPane and this is use to call:
> tabbedPane.setTitleAt(index,...)
> Unfortunately, the index is incorrect if the Tab is placed after an invisible tab. The index should be determined calling the method determineUIIndex(tab).
> I will suggest a patch which would only change the title/icon etc if the tab is visible and use the correct index.
> I'd be grateful if you could consider it.
> Many 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-490) Issue in ExtTabbedPane if the title change for a Tab placed after an invisible one

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

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

Benoit Xhenseval commented on RCP-490:
--------------------------------------

While I'm at it... I'd like to suggest adding the following method to the TabbedDialogPage.java

    protected Tab getTab(final DialogPage page) {
        return (Tab) page2tab.get(page);
    }

That way a subclass could get access to the Tab if required (eg to show title in bold in the decorateTitle if selected).

> Issue in ExtTabbedPane if the title change for a Tab placed after an invisible one
> ----------------------------------------------------------------------------------
>
>                 Key: RCP-490
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-490
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>            Reporter: Benoit Xhenseval
>         Attachments: ExtTabbedPane-patch.txt
>
>
> Hi,
> This is probably something for Peter.
> I'm using the TabbedDialogPage and ExtTabbedPane (cheers Peter) and I think that I've found a bug.
> When the title changes (say due to a page complete event), the propertyChangeHandler is called in ExtTabbedPane and this is use to call:
> tabbedPane.setTitleAt(index,...)
> Unfortunately, the index is incorrect if the Tab is placed after an invisible tab. The index should be determined calling the method determineUIIndex(tab).
> I will suggest a patch which would only change the title/icon etc if the tab is visible and use the correct index.
> I'd be grateful if you could consider it.
> Many 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-490) Issue in ExtTabbedPane if the title change for a Tab placed after an invisible one

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

Issue in ExtTabbedPane if the title change for a Tab placed after an invisible one
----------------------------------------------------------------------------------

                 Key: RCP-490
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-490
             Project: Spring Framework Rich Client Project
          Issue Type: Bug
            Reporter: Benoit Xhenseval
         Attachments: ExtTabbedPane-patch.txt

Hi,

This is probably something for Peter.

I'm using the TabbedDialogPage and ExtTabbedPane (cheers Peter) and I think that I've found a bug.

When the title changes (say due to a page complete event), the propertyChangeHandler is called in ExtTabbedPane and this is use to call:
tabbedPane.setTitleAt(index,...)

Unfortunately, the index is incorrect if the Tab is placed after an invisible tab. The index should be determined calling the method determineUIIndex(tab).

I will suggest a patch which would only change the title/icon etc if the tab is visible and use the correct index.

I'd be grateful if you could consider it.

Many 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-490) Issue in ExtTabbedPane if the title change for a Tab placed after an invisible one

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

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

Benoit Xhenseval updated RCP-490:
---------------------------------

    Attachment: ExtTabbedPane-patch.txt

The suggested patch.
Thanks!

> Issue in ExtTabbedPane if the title change for a Tab placed after an invisible one
> ----------------------------------------------------------------------------------
>
>                 Key: RCP-490
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-490
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>            Reporter: Benoit Xhenseval
>         Attachments: ExtTabbedPane-patch.txt
>
>
> Hi,
> This is probably something for Peter.
> I'm using the TabbedDialogPage and ExtTabbedPane (cheers Peter) and I think that I've found a bug.
> When the title changes (say due to a page complete event), the propertyChangeHandler is called in ExtTabbedPane and this is use to call:
> tabbedPane.setTitleAt(index,...)
> Unfortunately, the index is incorrect if the Tab is placed after an invisible tab. The index should be determined calling the method determineUIIndex(tab).
> I will suggest a patch which would only change the title/icon etc if the tab is visible and use the correct index.
> I'd be grateful if you could consider it.
> Many 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] Advice on JavaHelp

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

replace the processComponent in the interceptor to this:

[snip]
        public void processComponent(String propertyName, JComponent
component) {
            String key =3D getHelpKey(propertyName);

            if(broker.getHelpSet().getCombinedMap().isValidID(key,
broker.getHelpSet())) {
                broker.enableHelpKey(component, getHelpKey(propertyName),
broker.getHelpSet());
            }
        }
[/snip]

Peter


On 9/20/07, Peter De Bruycker <pet...@gm...> wrote:
>
>
> Benoit,
>
> I haven't used any of the tools. I would opt for authoring the help in
> docbook, and then transforming it with an ant build script to pdf and
> javahelp.
>
> regards,
>
> Peter
>  <http://jhelpdev.sourceforge.net/>
>
>
> On 9/20/07, Benoit Xhenseval < bx...@ob...> wrote:
> >
> >  Peter,
> >
> >
> >
> > This works beautifully, many thanks for providing the code and
> > guidelines for a view.
> >
> >
> >
> > As for feedback, it seems that an exception will be raised every time a
> > formId.propertyName is not found in the HelpSet. This is a bit brutal,
> > unfortunately I have not found a way to actually check whether an entry
> > exists or not and disable the F1 accordingly. It would be a most useful
> > thing to be able to do.
> >
> >
> >
> > Finally, could any of you share your experience with a decent authoring
> > tool? Which one do you use? (we would like to be able to produce a
> > PDF/manual as well as the HelpSet from the same source).
> >
> >
> >
> > We've found 3 main candidates:
> >
> > -          Adobe RobotHelp (expensive, $999)
> > http://www.adobe.com/products/robohelp/
> >
> > -          HelpBreeze $249, http://www.solutionsoft.com/javahelp.htm
> >
> > -          Helen 2 $169, http://www.software7.biz/
> >
> >
> >
> > Anyone used these?
> >
> > Is there another one that could handle both documents and JavaHelp
> > creation?
> >
> >
> >
> > Many thanks!
> >
> > Kind regards from London,
> >
> >
> >
> > Benoit
> >
> >
> >
> > -------------------------------
> >
> > IMPORTANT NOTICE This communication contains information that is
> > considered confidential and may also be privileged . It is for the excl=
usive
> > 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 b=
e
> > unlawful. If you have received this communication in error please retur=
n it
> > to the sender and delete the original.
> >
> >
> >
> > *From:* spr...@li... [mailto:
> > spr...@li...] *On Behalf Of *P=
eter
> > De Bruycker
> > *Sent:* 18 September 2007 14:30
> > *To:* spr...@li...
> > *Subject:* Re: [Springframework-rcp-dev] Advice on JavaHelp
> >
> >
> >
> > Benoit,
> >
> > to have context sensitive help in a view you can follow this method:
> >
> > 1. create your help html files
> > 2. create entries in your <xxxxxx>.jhm file
> > 3. in your view.createControl() method: get a reference to your helpset=
,
> > create a helpbroker, and enable help on individual components in your v=
iew.
> > 4. to have a help button in your view: create a button with a help icon=
,
> > then call HelpBroker.enableHelpOnButton()
> >
> >
> > Some spring-rich specific class wrapping HelpBroker should still be
> > created, so the helpset and broker can be reused by the views and the
> > JavaHelpFormComponentInterceptorFactory.
> > If you'd like to, you can create this class, and contribute it to the
> > project ;-)
> >
> >
> > hope this helps,
> >
> > Peter
> >
> > On 9/18/07, *Benoit Xhenseval *<bx...@ob...> wrote:
> >
> > Hi *,
> >
> >
> >
> > I'd like to benefit from our experience here. Have you developed some
> > JavaHelp?
> >
> > If so, which tool did you find easiest to keep a "manual" as well as a
> > javahelp export?
> >
> >
> >
> > How did you integrate it in a SpringRC application? I have used the
> > HelpContentCommand:
> >
> > org.springframework.richclient.command.support.HelpContentsCommand
> >
> >
> >
> > This is useful, however, has anyone done some Context-sensitive help? I=
s
> > there any support in Spring RC for it? An "F1" key?
> >
> > Like the ability to specify a help path for a view or a field?  We have
> > the .label, .caption, .icon, .image fields etc  it would be great to ad=
d a
> > .helpPath or something similar with an overlay=85
> >
> >
> >
> > Any suggestion, comment, experience, code would be welcomed!
> >
> >
> >
> > Many thanks, as usual,
> >
> >
> >
> > Benoit.
> >
> >
> >
> > -------------------------------
> >
> > IMPORTANT NOTICE This communication contains information that is
> > considered confidential and may also be privileged . It is for the excl=
usive
> > 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 b=
e
> > unlawful. If you have received this communication in error please retur=
n it
> > to the sender and delete the original.
> >
> >
> >
> >
> >
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.487 / Virus Database: 269.13.22/1013 - Release Date:
> > 17/09/2007 13:29
> >
> >
> >
> > -----------------------------------------------------------------------=
--
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> >
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.487 / Virus Database: 269.13.22/1013 - Release Date:
> > 17/09/2007 13:29
> >
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date:
> > 18/09/2007 11:53
> >
> >
> > -----------------------------------------------------------------------=
--
> > 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
> >
> >
>

Re: [Springframework-rcp-dev] Advice on JavaHelp

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

Benoit,

I haven't used any of the tools. I would opt for authoring the help in
docbook, and then transforming it with an ant build script to pdf and
javahelp.

regards,

Peter
<http://jhelpdev.sourceforge.net/>


On 9/20/07, Benoit Xhenseval < bx...@ob...> wrote:
>
>  Peter,
>
>
>
> This works beautifully, many thanks for providing the code and guidelines
> for a view.
>
>
>
> As for feedback, it seems that an exception will be raised every time a
> formId.propertyName is not found in the HelpSet. This is a bit brutal,
> unfortunately I have not found a way to actually check whether an entry
> exists or not and disable the F1 accordingly. It would be a most useful
> thing to be able to do.
>
>
>
> Finally, could any of you share your experience with a decent authoring
> tool? Which one do you use? (we would like to be able to produce a
> PDF/manual as well as the HelpSet from the same source).
>
>
>
> We've found 3 main candidates:
>
> -          Adobe RobotHelp (expensive, $999)
> http://www.adobe.com/products/robohelp/
>
> -          HelpBreeze $249, http://www.solutionsoft.com/javahelp.htm
>
> -          Helen 2 $169, http://www.software7.biz/
>
>
>
> Anyone used these?
>
> Is there another one that could handle both documents and JavaHelp
> creation?
>
>
>
> Many thanks!
>
> Kind regards from London,
>
>
>
> Benoit
>
>
>
> -------------------------------
>
> IMPORTANT NOTICE This communication contains information that is
> considered confidential and may also be privileged . It is for the exclus=
ive
> 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 *Pet=
er
> De Bruycker
> *Sent:* 18 September 2007 14:30
> *To:* spr...@li...
> *Subject:* Re: [Springframework-rcp-dev] Advice on JavaHelp
>
>
>
> Benoit,
>
> to have context sensitive help in a view you can follow this method:
>
> 1. create your help html files
> 2. create entries in your <xxxxxx>.jhm file
> 3. in your view.createControl() method: get a reference to your helpset,
> create a helpbroker, and enable help on individual components in your vie=
w.
> 4. to have a help button in your view: create a button with a help icon,
> then call HelpBroker.enableHelpOnButton()
>
>
> Some spring-rich specific class wrapping HelpBroker should still be
> created, so the helpset and broker can be reused by the views and the
> JavaHelpFormComponentInterceptorFactory.
> If you'd like to, you can create this class, and contribute it to the
> project ;-)
>
>
> hope this helps,
>
> Peter
>
> On 9/18/07, *Benoit Xhenseval *<bx...@ob...> wrote:
>
> Hi *,
>
>
>
> I'd like to benefit from our experience here. Have you developed some
> JavaHelp?
>
> If so, which tool did you find easiest to keep a "manual" as well as a
> javahelp export?
>
>
>
> How did you integrate it in a SpringRC application? I have used the
> HelpContentCommand:
>
> org.springframework.richclient.command.support.HelpContentsCommand
>
>
>
> This is useful, however, has anyone done some Context-sensitive help? Is
> there any support in Spring RC for it? An "F1" key?
>
> Like the ability to specify a help path for a view or a field?  We have
> the .label, .caption, .icon, .image fields etc  it would be great to add =
a
> .helpPath or something similar with an overlay=85
>
>
>
> Any suggestion, comment, experience, code would be welcomed!
>
>
>
> Many thanks, as usual,
>
>
>
> Benoit.
>
>
>
> -------------------------------
>
> IMPORTANT NOTICE This communication contains information that is
> considered confidential and may also be privileged . It is for the exclus=
ive
> 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.487 / Virus Database: 269.13.22/1013 - Release Date:
> 17/09/2007 13:29
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.487 / Virus Database: 269.13.22/1013 - Release Date:
> 17/09/2007 13:29
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date:
> 18/09/2007 11:53
>
> -------------------------------------------------------------------------
> 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
>
>

Re: [Springframework-rcp-dev] Advice on JavaHelp

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

Peter,

=20

This works beautifully, many thanks for providing the code and =
guidelines
for a view.

=20

As for feedback, it seems that an exception will be raised every time a
formId.propertyName is not found in the HelpSet. This is a bit brutal,
unfortunately I have not found a way to actually check whether an entry
exists or not and disable the F1 accordingly. It would be a most useful
thing to be able to do.

=20

Finally, could any of you share your experience with a decent authoring
tool? Which one do you use? (we would like to be able to produce a
PDF/manual as well as the HelpSet from the same source).

=20

We=92ve found 3 main candidates:

-          Adobe RobotHelp (expensive, $999) HYPERLINK
"http://www.adobe.com/products/robohelp/"http://www.adobe.com/products/ro=
boh
elp/

-          HelpBreeze $249, HYPERLINK
"http://www.solutionsoft.com/javahelp.htm"http://www.solutionsoft.com/jav=
ahe
lp.htm=20

-          Helen 2 $169, HYPERLINK
"http://www.software7.biz/"http://www.software7.biz/=20

=20

Anyone used these?

Is there another one that could handle both documents and JavaHelp =
creation?

=20

Many thanks!

Kind regards from London,

=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: 18 September 2007 14:30
To: spr...@li...
Subject: Re: [Springframework-rcp-dev] Advice on JavaHelp

=20

Benoit,

to have context sensitive help in a view you can follow this method:

1. create your help html files
2. create entries in your <xxxxxx>.jhm file
3. in your view.createControl() method: get a reference to your helpset,
create a helpbroker, and enable help on individual components in your =
view.=20
4. to have a help button in your view: create a button with a help icon,
then call HelpBroker.enableHelpOnButton()


Some spring-rich specific class wrapping HelpBroker should still be =
created,
so the helpset and broker can be reused by the views and the
JavaHelpFormComponentInterceptorFactory.=20
If you'd like to, you can create this class, and contribute it to the
project ;-)


hope this helps,

Peter

On 9/18/07, Benoit Xhenseval <HYPERLINK
"mailto:bx...@ob..."bx...@ob...> wrote:

Hi *,

=20

I'd like to benefit from our experience here. Have you developed some
JavaHelp?

If so, which tool did you find easiest to keep a "manual" as well as a
javahelp export?

=20

How did you integrate it in a SpringRC application? I have used the
HelpContentCommand:

org.springframework.richclient.command.support.HelpContentsCommand

=20

This is useful, however, has anyone done some Context-sensitive help? Is
there any support in Spring RC for it? An "F1" key?

Like the ability to specify a help path for a view or a field?  We have =
the
.label, .caption, .icon, .image fields etc  it would be great to add a
.helpPath or something similar with an overlay=85

=20

Any suggestion, comment, experience, code would be welcomed!

=20

Many thanks, as usual,

=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

=20

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.487 / Virus Database: 269.13.22/1013 - Release Date: =
17/09/2007
13:29


-------------------------------------------------------------------------=

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
HYPERLINK "http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/"
\nhttp://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Springframework-rcp-dev mailing list
HYPERLINK
"mailto:Spr...@li..."Springframework-rcp=
-de
v...@li...
HYPERLINK
"https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev"
\nhttps://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev=20

=20

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.487 / Virus Database: 269.13.22/1013 - Release Date: =
17/09/2007
13:29


No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: =
18/09/2007
11:53
=20

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

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

Hi Jan,

Thanks for your email. I've looked in more details at the javadoc of the =
AbstractApplicationEventMulticaster (the parent of =
SimpleApplicationEventMulticaster).

See =
http://www.koders.com/java/fidAA823A88FDC2F28AF66BA147B8A4E9CB9B81D98D.as=
px?s=3DgetApplicationListeners

I note the following:
 * Note that this class doesn't try to do anything clever to ensure =
thread
 * safety if listeners are added or removed at runtime. A technique such =
as
 * Copy-on-Write (Lea:137) could be used to ensure this, but the =
assumption in
 * the basic version of the class is that listeners will be added at =
application
 * configuration time and not added or removed as the application runs.

And further:
 * A custom collection class must be specified to allow for thread-safe
 * runtime registration of listeners. A good candidate for this is Doug =
Lea's
 * <code>java.util.concurrent.CopyOnWriteArraySet</code> or its non-JDK =
predecessor,
 * <code>EDU.oswego.cs.dl.util.concurrent.CopyOnWriteArraySet</code>

And it seems to be possible to have that collection class used in Spring =
RC by simply configuring it like this (for java 5):

<bean id=3D"applicationEventMulticaster" =
class=3D"org.springframework.context.event.SimpleApplicationEventMulticas=
ter">
    <property name=3D"collectionClass" =
value=3D"java.util.concurrent.CopyOnWriteArraySet"/>
</bean>

We had this ConcurrentModification issue from time to time, so we're =
going to have a go with the javadoc suggestion and I will report here =
later on if this does not fix the issue.

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.


-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of Jan Hoskens
Sent: 11 September 2007 07:47
To: spr...@li...
Subject: Re: [Springframework-rcp-dev] concurrent modif in the =
multicaster

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.=20

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 *,
>=20
> =20
>=20
> First of all, many thanks for considering the Readony interceptor!
> That is super to have an official implementation.
>=20
> =20
>=20
> I have just experienced the following problem a couple of times:
>=20
> =20
>=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=
castEvent(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=
.java: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=
actRemoteDao.java:89)
>=20
> =20
>=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
> =20
>=20
> Is there any reason why the
> SimpleApplicationEventMulticaster.multicastEvent is not synchronized?
> Should it be?
>=20
> Should the synchronization be done via the
> AbstractApplicationContext.publishEvent?
>=20
> =20
>=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=E2=80=A6
>=20
> =20
>=20
> These 2 classes are in spring-context=E2=80=A6
>=20
> =20
>=20
> The BusinessEventConsumer line 207 is like this:
>=20
>         if(shouldTriggerScreenRefresh(event)) {
>=20
>             SwingUtilities.invokeLater(new Runnable() {
>=20
>                 public void run() {
>=20
>=20
> =
Application.instance().getApplicationContext().publishEvent(newClientAppE=
vent(event));
>=20
>                 }
>=20
>             });
>=20
>         }
>=20
> =20
>=20
> Suggestions welcomed=E2=80=A6
>=20
> =20
>=20
> Thanks
>=20
> =20
>=20
> Benoit.
>=20
> =20
>=20
> =20
>=20
> =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
> =20
>=20
>=20
>=20
> 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
>=20
>=20
> =
-------------------------------------------------------------------------=

> 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

-------------------------------------------------------------------------=

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Springframework-rcp-dev mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

No virus found in this incoming message.
Checked by AVG Free Edition.=20
Version: 7.5.485 / Virus Database: 269.13.14/999 - Release Date: =
10/09/2007 17:43
=20

No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: =
18/09/2007 11:53
=20

[Springframework-rcp-dev] [Spring-JIRA] Created: (RCP-489) start Application / showPage() should be called on EDT

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

start Application / showPage() should be called on EDT
------------------------------------------------------

                 Key: RCP-489
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-489
             Project: Spring Framework Rich Client Project
          Issue Type: Improvement
          Components: Application Framework
            Reporter: Christian Heilmann
            Priority: Minor


The ApplicationLauncher should start the Application on the EDT or the showPage()-Method should be called the first time on the EDT.

On Views it is often the case that in onFocusGained() you make a asynchronous remote-call to get the data to set in the model in the view.

So it is a good thing, to put some Assert.isTrue(SwingUtilities.isisEventDispatchThread()) in your Views, to check, that the model or gui-components are never changed outside the EDT.

But now the check in Views is the first-time not possible, because the Lifecycle-Methods of the Views are called the first time, when the Application is starting, outside the EDT.


-- 
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] Advice on JavaHelp

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

Benoit,

to have context sensitive help in a view you can follow this method:

1. create your help html files
2. create entries in your <xxxxxx>.jhm file
3. in your view.createControl() method: get a reference to your helpset,
create a helpbroker, and enable help on individual components in your view.
4. to have a help button in your view: create a button with a help icon,
then call HelpBroker.enableHelpOnButton()


Some spring-rich specific class wrapping HelpBroker should still be created=
,
so the helpset and broker can be reused by the views and the
JavaHelpFormComponentInterceptorFactory.
If you'd like to, you can create this class, and contribute it to the
project ;-)


hope this helps,

Peter

On 9/18/07, Benoit Xhenseval <bx...@ob...> wrote:
>
>  Hi *,
>
>
>
> I'd like to benefit from our experience here. Have you developed some
> JavaHelp?
>
> If so, which tool did you find easiest to keep a "manual" as well as a
> javahelp export?
>
>
>
> How did you integrate it in a SpringRC application? I have used the
> HelpContentCommand:
>
> org.springframework.richclient.command.support.HelpContentsCommand
>
>
>
> This is useful, however, has anyone done some Context-sensitive help? Is
> there any support in Spring RC for it? An "F1" key?
>
> Like the ability to specify a help path for a view or a field?  We have
> the .label, .caption, .icon, .image fields etc  it would be great to add =
a
> .helpPath or something similar with an overlay=85
>
>
>
> Any suggestion, comment, experience, code would be welcomed!
>
>
>
> Many thanks, as usual,
>
>
>
> Benoit.
>
>
>
> -------------------------------
>
> IMPORTANT NOTICE This communication contains information that is
> considered confidential and may also be privileged . It is for the exclus=
ive
> 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.487 / Virus Database: 269.13.22/1013 - Release Date:
> 17/09/2007 13:29
>
> -------------------------------------------------------------------------
> 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
>
>

Re: [Springframework-rcp-dev] Advice on JavaHelp

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

Benoit,

some code/pointers to get you started:

Context sensitive help in forms:
- the JavaHelpFormComponentInterceptorFactory has to be defined in your list
of form component interceptors, and the helpSetPath property has to point to
your helpset location.
- make sure your FormModel has an id, otherwise only the property name will
be used
- create entries in your <xxxxxx>.jhm files (one for each form property):
                  <mapID target="<formModelId>.<property>" url="path to html
help file"/> <!-- path to html file can contain named anchor, so you can
bundle all information about one form in one html file, divided in sections
using named anchors-->
- when you open your form, press F1 when in a form component, the help wil
open and jump to the correct html file
- JavaHelpFormComponentInterceptorFactory will be committed to svn, when I
have time ;-), but still needs some cleanup (error handling, ...)

The method above uses <formModelId>.<property> as helpkey. A future version
could first check for a helpKey entry in a properties file, and fall back to
the <formModelId>.<property> behaviour.

Hope this helps,

Peter


On 9/18/07, Benoit Xhenseval <bx...@ob...> wrote:
>
>  Hi *,
>
>
>
> I'd like to benefit from our experience here. Have you developed some
> JavaHelp?
>
> If so, which tool did you find easiest to keep a "manual" as well as a
> javahelp export?
>
>
>
> How did you integrate it in a SpringRC application? I have used the
> HelpContentCommand:
>
> org.springframework.richclient.command.support.HelpContentsCommand
>
>
>
> This is useful, however, has anyone done some Context-sensitive help? Is
> there any support in Spring RC for it? An "F1" key?
>
> Like the ability to specify a help path for a view or a field?  We have
> the .label, .caption, .icon, .image fields etc  it would be great to add a
> .helpPath or something similar with an overlay…
>
>
>
> Any suggestion, comment, experience, code would be welcomed!
>
>
>
> Many thanks, as usual,
>
>
>
> 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.487 / Virus Database: 269.13.22/1013 - Release Date:
> 17/09/2007 13:29
>
> -------------------------------------------------------------------------
> 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] Advice on JavaHelp

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

Hi *,

=20

I=92d like to benefit from our experience here. Have you developed some
JavaHelp?

If so, which tool did you find easiest to keep a =93manual=94 as well as =
a
javahelp export?

=20

How did you integrate it in a SpringRC application? I have used the
HelpContentCommand:

org.springframework.richclient.command.support.HelpContentsCommand

=20

This is useful, however, has anyone done some Context-sensitive help? Is
there any support in Spring RC for it? An =93F1=94 key?

Like the ability to specify a help path for a view or a field?  We have =
the
.label, .caption, .icon, .image fields etc  it would be great to add a
.helpPath or something similar with an overlay=85

=20

Any suggestion, comment, experience, code would be welcomed!

=20

Many thanks, as usual,

=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.487 / Virus Database: 269.13.22/1013 - Release Date: =
17/09/2007
13:29
=20