Hi Jonathan,
> New patch attached.
thanks, will have a more detailed look later, some quick comments for now
> Major changes include the addition of "native" ODF support (i.e.
> a //form:radio/@form:group-name attribute to store the group name),
great
> and
> the GroupName property is imported from OLE controls (the
> svx/source/msfilter/msocximex.cxx change).
great as well
>> - The DIALOG_VISIBLE flag in formmetadata.cxx suggests this property
>> should also be visible also in the Dialog Editor - which isn't
>> necessary since the "normal" controls as used in the Basic/UNO dialogs
>> do not support this new property
>
> Where is this visible in the dialog editor? For that matter, is the
> dialog editor what appears when you click (in Calc) Tools -> Macros ->
> Organize Dialogs -> [ select dialog ] -> Edit?
>
> If so, where would I find GroupName, as I couldn't find it when
> DIALOG_VISIBLE was set.
Actually, it isn't visible because the controls used in UNO dialogs do
not support the property :). You added the property to form controls,
which are an extension of "normal" toolkit controls, the latter being
used in the UNO dialogs.
So, the DIALOG_VISIBLE was simply superfluous, as it told "display this
property for UNO dialogs, if it is actually there". Sounds weird,
probably :), but some of the properties which exist in the core should
not be displayed for either forms or dialogs, thus those *_VISIBLE flags.
>> - please adhere to the style used in the files you modify. In
>> particular, please do
>> if ( foo )
>> {
>> ...
>> instead of
>> if ( foo ) {
>> ...
>> This helps ensuring a consistent look of the file, and thus better
>> readability
>
> I didn't see any occurrences with `if',
OGroupManager::propertyChange, for instance :)
>> - you need to add HID_PROP_GROUP_NAME to extensions/util/hidother.src,
>> else our automation QA will complain later
>
> Done, though after making this change nothing was rebuilt. Odd.
That's correct. The file is delivered only, and in instsetoo_native, all
those files are assembled to one large file named hid.lst, which is used
by our automation QA.
> [TABs]
> So which is better: dogmatic consistency with the "spaces not tabs"
> guideline, or being consistent with the surrounding code? I opted for
> the latter; should I go for the former?
Well, yes ... historically, TABs were not expanded. Today's guidelines
say they should be expanded to 4 spaces, but there has never been a
concentrated action to change existing code. Thus, consistency in fact
is hard to find here.
Be it, I don't have a really stringent opinion here. Do it as it fits
your habits best.
Thanks & 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]
