Hi Jonathan, > Attached is the current version of RadioButton Group Name support.
thanks, I'll look into it in more detail later, for now, lemme just reply to some items in your mail. > As it happens, your hint about ORadioButtonModel::SetSiblingPropsTo() > solves the problems I had last time. That's great! > 1. The GroupName property has not yet been brought to the ODF file > format, and thus it currently relies on the default property support. Usually, I introduce a new attribute in such cases, even if this means that the documents will not conform to the ODF standard, yet. I think it is better having a not-yet-compliant-but-readable file format than a compliant-but-awkward file format. So, I suggest you add this new attribute (not sure if you need guidance through xmloff/source/forms ... it should be halfway understandable, though it's not the most modern code. But this time, it's indeed me and only me to blame :). Writing the small document which will propose the addition of this new attribute to an upcoming ODF version can be done later, the non-existence of this proposal must not hinder us from integrating the feature. > 2. GroupName hasn't yet been hooked into any import filters, so Excel > import won't start using GroupName yet. That's nothing I can talk about, you would need to direct this to our Excel filter developer - Daniel Rentz, IIRC. However, I am sure he would be most grateful for getting this feature, and will surely lend you a hand in implementing the import/export. If you happen to have the code in a CWS, then this would ease it - I am sure we can convince Daniel to write the import/export then. > 4. About those unit tests... :-) > > First of all, it helps to know that I need to run `dmake` within > qadevOOo before `dmake` in forms/qa/integration/forms will work. Uhm. I would have assumed this is built with a regular build ... but thinking about it, this might in fact not be the case with a vanilla build environment (remember we still have some slightly different environment in Hamburg, sadly). Sorry for not telling you, I simply didn't know. > Next, the tests work...inconsistently. Even against an *unmodified* > OpenOffice.org 2.4.0 installation (as provided by the .tar.gz on the > openoffice.org site), `dmake run_RadioButtons` fails the *first* time > it's run within checkThreeGroups -- somehow changing the selected > RadioButtons results in NO radio buttons being selected (bizarre!). > This results in one window remaining open after the test. > > Run `dmake run_RadioButtons` a second time (while the remaining window > from the first run is still open), and all tests work. Close the window > "left behind" by the failing run and it will fail in the same spot > again. This is a deeper analysis of the problem I did so far :) In fact I recently noticed this test fails, but didn't know its success depends on the previous doc window staying open. Indeed, very odd. I did not yet find the time to investigate this, but for the moment was happy the second run succeeds ... > Doubly odd is that occasionally I get a NullPointerException: > > java.lang.NullPointerException > LOG> at > integration.forms.RadioButtons.checkRadio(RadioButtons.java:329) > LOG> at > integration.forms.RadioButtons.checkCalcPageSwitch(RadioButtons.java:251) > LOG> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > LOG> at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > LOG> at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > LOG> at java.lang.reflect.Method.invoke(Method.java:585) > LOG> at complexlib.MethodThread.run(Unknown Source) > LOG> Finished null > ***** State for integration.forms.RadioButtons ****** > checkCalcPageSwitch - java.lang.NullPointerException > > Not sure what's going on there. Uh - never encountered this. Looking at the code, this means that the XAccessible(Value) for the of the radio button control could not be retrieved. Which is, ehm, quite impossible :-\ It would be interesting to know whether the return value of accessible.getAccessibleContext() is already null, or only the xValue. > Again, this happens against both an OpenOffice.org 2.4.0 install and > against a build with my changes, so I don't think this is due to me. Agreed - as said, I know the first problem, and the second doesn't sounds like your changes have any chance of causing it. >> - m_sGroupName must also be initialized in the "cloning" ctor of >> ORadioButtonModel > > Is this "cloning" ctor the ORadioButtonModel(const ORadioButtonModel* > _pOriginal, const Reference<XMultiServiceFactory>& _rxFactory ) Yes. Okay, more (perhaps) when I looked at your patch ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
