Issue 121263 - XPropertyChangeListener does not get fired when changing properties
Summary: XPropertyChangeListener does not get fired when changing properties
Status: CONFIRMED
Alias: None
Product: App Dev
Classification: Unclassified
Component: api (show other issues)
Version: 3.4.1
Hardware: PC All
: P3 Major
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 121264 (view as issue list)
Depends on:
Blocks:
 
Reported: 2012-10-24 07:56 UTC by Jens Bornschein
Modified: 2012-10-24 22:38 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Jens Bornschein 2012-10-24 07:56:41 UTC
XPropertyChangeListener does not get fired when changing properties, e.g. of an XLayer. The web is full of threads for not using this listener because it doesn’t get fired at all, even on dispose. This could be linked to the bug 61522 which seems to be the same problem. The Events have to get fired on every changes made on the properties.


Sample code C#

    class DrawDocLayerManager : XPropertyChangeListener, XVetoableChangeListener, XPropertyStateChangeListener, XPropertySetInfoChangeListener, XPropertiesChangeListener 
    {       
        private readonly XNameAccess _layerManger;

        public DrawDocLayerManager(XLayerSupplier drwaDoc)
        {
            if (drwaDoc == null)
                throw new ArgumentNullException("drwaDoc", "The XLayerSupplier is null");

            _layerManger = drwaDoc.getLayerManager();
            XIndexAccess xIndexAccess = (XIndexAccess)_layerManger;

            //Add PropertychangeListener to all Layer
            for (int i = 0; i < xIndexAccess.getCount(); i++)
            {
                try
                {
                    XLayer xLayer = (XLayer)xIndexAccess.getByIndex(i).Value;

                    xLayer.addPropertyChangeListener("Name", this);
                    xLayer.addVetoableChangeListener("Name", this);
                    xLayer.addPropertyChangeListener("", this);
                    xLayer.addVetoableChangeListener("", this);

                    ((XPropertySet)xLayer).setPropertyValue("Name", new Any("foo"));

                }
                catch (System.Exception e)
                {
                    Console.WriteLine(e);
                }


            }


        }

        public void disposing(EventObject Source)
        {
             throw new NotImplementedException();
        }

        public void propertiesChange(PropertyChangeEvent[] aEvent)
        {
            throw new NotImplementedException();
        }

        public void propertySetInfoChange(PropertySetInfoChangeEvent evt)
        {
            throw new NotImplementedException();
        }

        public void propertyStateChange(PropertyStateChangeEvent aEvent)
        {
            throw new NotImplementedException();
        }

        public void vetoableChange(PropertyChangeEvent aEvent)
        {
            throw new NotImplementedException();
        }

        public void propertyChange(PropertyChangeEvent evt)
        {
            throw new NotImplementedException();
        }
    }
}
Comment 1 Ariel Constenla-Haile 2012-10-24 12:58:01 UTC
(In reply to comment #0)
> XPropertyChangeListener does not get fired when changing properties, e.g. of
> an XLayer. The web is full of threads for not using this listener because it
> doesn’t get fired at all, even on dispose. This could be linked to the bug
> 61522 which seems to be the same problem.

The bugs are unrelated, they are two different implementations.

The issue here is that the class SdLayer implements XLayer, inheriting com::sun::star::beans::XPropertySet

sd/source/ui/unoidl/unolayer.hxx
sd/source/ui/unoidl/unolayer.cxx

but the implementation is empty:
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/sd/source/ui/unoidl/unolayer.cxx?revision=1244544&view=markup#l317
Comment 2 Marcus 2012-10-24 22:38:07 UTC
*** Issue 121264 has been marked as a duplicate of this issue. ***