Hi Jonathan, >> So, if you want to implement a GroupName, that's welcome. I could >> provide you with all necessary pointers, if you wish. > > Please do so.
Okay, this might get longer, since I do not know what knowledge you already have. Let's see. In general, form controls are extensions of generic UNO controls, as defined in the css.awt module. The latter are implemented in module toolkit, the former in module forms. One decision to make is which controls we want to extend - the basic ones, or only the form controls. In the first case, also the Basic dialogs would benefit from it, in the latter, only documents with form controls. There's good arguments for both solutions, though. I suggest, for the moment, to start with the form controls only, since this is where it's needed ATM, and moving the implementation later on should be possible. First, you need to merely add the property to the radio button model. To be able to use existing mechanisms in the forms module, you should declare a PROPERTY_GROUP_NAME and PROPERTY_ID_GROUP_NAME. As a general note, let an arbitrary other PROPERTY_[ID_]FOO (and "grep") guide you where to add and use the new property. In short, source/inc/frm_strings.hxx and source/inc/property.hrc are for the new defines. To actually implement the property, you need to, in forms/source/RadioButton.cxx: - extend ORadioButtonModel::describeFixedProperties to declare the presence of the property. - add a new member to the ORadioButtonModel class, taking the group name - overload setFastPropertyValue_NoBroadcast, convertFastPropertyValue, getFastPropertyValue, to handle setting/getting the group name property. See the same methods in e.g. the OBoundControlModel for typical implementations. (And while we are at this place: be warned, some of the code you encounter is *really* old :) This together should give you a new property, which you can set and get at runtime, but which doesn't have any functionality, yet. Second, you need to respect this property when defining the tab groups at runtime. The tabbing order (and thus the definition of radio button groups) is managed in the OGroupManager class in forms/source/component/GroupManager.cxx. There's one group manager instance for every logical form, and it manages the controls which are children of this logical forms. It does so by being a listener at the form (listening for element insertion and removal), and by being a listener at the single elements (aka control models, here it listens for the "Name" and "TabIndex" properties). You need to tweak the group manager implementations (OGroupManager and dependent classes) to respect not only "Name" and "TabIndex" when deciding which controls belong into one group, but also the new "GroupName" property. The entry point for this change would be OGroupManager::InsertElement. We need to define how the new property interacts with the old implementations. That is, if an old document is loaded, users expect the "grouping by name" to continue working, else their documents would be simply broken. So, I suggest that GroupName should be taken into account to determine which group a control model belongs to *only* when it is not empty. When it's empty, then the "Name" property should, as before, be taken as group indicator. If you have all this done right, then the new property should start working. Third, you need to bring the new property to the UI. extensions/source/propctrlr is where the property browser is implemented. I suggest let an existing property inspire you: the most simple property you can find there is "Tag". Just grep the propctrlr folder for "TAG", "PROPERTY_TAG", "PROPERTY_ID_TAG", copy what you find, and adjust it to refer to the GroupName property. Note: the order in formmetadata.cxx controls the order in which the properties appear in the UI, so choose wisely. Two small changes, related to the help ID of the new property in the property browser, need to be made in extensions/inc/extensio.hrc and extensions/util/hidother.src. Again, grep for HID_PROP_TAG here, and "steal" from it. Forth, you need to bring the property to the file format. There is a mechanism which stores (nearly) *any* properties found at a form control model in some generic form, but normally, we'd want to have properties reflected in attributes of XML elements. That is, we would want the new property to be stored as, say <form:radio-button ... "form:group-name='group'"> ... For the moment, I won't go into detail here - as said, the property will be persistent without a dedicated implementation. However, I encourage you to also look into xmloff/source/forms, and consider implementing such a dedicated attribute. More details if/when you decide to start with this. There's at least one test which you should definitely run after you implemented the new property. For this, start OOO with "-accept=socket,host=localhost,port=8100;urp", to accept incoming connections to the UNO API. Then, in forms/qa/integration/forms, do a "dmake", followed by "dmake run_RadioButtons". This will run the integration test "integration.forms.RadioButtons", which connects to OOo, and verifies radio buttons still work as expected, especially with respect to grouping. If this test fails in any aspect, most probably your implementation is still flawed. If the test doesn't fail, this doesn't mean you implementation is correct, however :) I encourage you to add new sub tests to the integration.forms.RadioButton class, which verify the new property works as expected, and in particular how it interacts with the old behaviour. E.g., add 4 radio buttons, two with the same group name, two without group name, and let the test verify this behaves as expected. Okay, I hope this helps to get you started. For any questions, please don't hesitate to ask here. If you plan to contribute the code back (I strongly hope you do!), then I'm the person who will apply the final nitpick^Wreview to your changes. Thus, feel free to, at any time, show me what you have so far :) Have fun! 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]
