Issue 77441 - OpenOffice++ (extensions, svtools)
Summary: OpenOffice++ (extensions, svtools)
Status: CLOSED FIXED
Alias: None
Product: utilities
Classification: Unclassified
Component: code (show other issues)
Version: 680
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.3
Assignee: carsten.driesner
QA Contact: Unknown
URL:
Keywords:
Depends on:
Blocks: 73468
  Show dependency tree
 
Reported: 2007-05-17 00:35 UTC by Daniel Darabos
Modified: 2007-09-11 19:46 UTC (History)
3 users (show)

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

Attachments
Patches for extensions (1.18 KB, text/plain)
2007-05-17 00:35 UTC, Daniel Darabos 		no flags Details
Patches for svtools (5.00 KB, text/plain)
2007-05-17 00:36 UTC, Daniel Darabos 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Daniel Darabos 2007-05-17 00:35:33 UTC 
Patches for the extensions and svtools components will be attached in a minute.
Please see Issue #73468 for what it is about!
Comment 1 Daniel Darabos 2007-05-17 00:35:54 UTC 
Created attachment 45163 [details]
Patches for extensions
Comment 2 Daniel Darabos 2007-05-17 00:36:17 UTC 
Created attachment 45164 [details]
Patches for svtools
Comment 3 carsten.driesner 2007-05-21 15:51:29 UTC 
cd->cyhawk: Thanks for your patches. Please give me some time to check them.
Comment 4 clippka 2007-06-07 09:30:14 UTC 
I have no objections on the patch for the unoimap.cxx file.

CL->cyhawk: Can you explain why you changed the default to use IMAP_OBJ_POLYGON
instead of IMAP_OBJ_RECTANGLE for unknown imap object types?
Comment 5 carsten.driesner 2007-06-08 15:57:34 UTC 
cd->fs: Could you please check the changes within extensions. You are the main
developer of this code. Thanks.
Comment 6 Frank Schönheit 2007-06-11 10:07:46 UTC 
fs->cyhawk: I'm not sure about the motivation of the patch in
extensions/source/propctrlr/propertyhandler.hxx.
I guess it's about m_aMutex (not) being the very first member, which might be
desirable in case it's used as reference to the ctor of other members. Is this
true? If so, I'd prefer deriving PropertyHandler from ::cppu::BaseMutex, which
would reach the same goal in a more robust way.
Comment 7 carsten.driesner 2007-06-11 14:12:10 UTC 
cd->cyhawk: We have some comments about your changes. Please try to answer them.
I have accepted all changes that are not controversial. I am going to use this
issue to commit them. Without a comment from your side all other changes won't
be committed.
Comment 8 carsten.driesner 2007-06-18 07:35:08 UTC 
cd: No answer from patch submitter. Therefore controversial parts of the patch
omitted.
Comment 9 carsten.driesner 2007-06-21 10:22:05 UTC 
cd: Verified.
Comment 10 carsten.driesner 2007-07-25 08:45:42 UTC 
cd: Verified on master.
Comment 11 Daniel Darabos 2007-09-11 16:20:16 UTC 
Sorry, I don't know why I didn't notice your questions regarding this patch. I
have now checked propertyhandler.cxx and indeed m_aPropertyListeners (declared
after m_aMutex in propertyhandler.hxx) gets m_aMutex as a parameter to its
constructor during initialization. Would you like me to submit a new patch
deriving PropertyHandler from BaseMutex?
Comment 12 Frank Schönheit 2007-09-11 19:46:46 UTC 
would be great, thanks.