Issue 108891 - [From Symphony]Range.CopyFromRecordset with instant adLockReadOnly can't work
[From Symphony]Range.CopyFromRecordset with instant adLockReadOnly can't work
Status: CONFIRMED
Product: App Dev
Classification: Unclassified
Component: vba
OOo 3.3 or older
All All
: P3 trivial
: ---
Assigned To: Chen Peng
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-03 07:24 UTC by lihuiibm
Modified: 2013-02-24 20:56 UTC (History)
1 user (show)

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


Attachments
Fix for this issue (11.63 KB, patch)
2010-02-03 07:25 UTC, lihuiibm
no flags Details | Diff
Because new file(api-to-idl.pl) has the windows crlf(s), but the old api-to-idl.pl does not have windows crlf(s), so the diff file has some mistake. I am very sorry for my negligence, please use the new patch. (954 bytes, text/plain)
2010-02-28 09:14 UTC, lihuiibm
no flags Details
Sample file for this issue (66.50 KB, text/plain)
2010-03-01 10:26 UTC, lihuiibm
no flags Details
Test data file for this issue. (20.50 KB, text/plain)
2010-03-01 10:27 UTC, lihuiibm
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description lihuiibm 2010-02-03 07:24:45 UTC
1. Root Cause:
Duplicate define in api files in oovbaapi .So the const values of ado was flush.
2. Resolution:
Add the moudle name before idl
Comment 1 lihuiibm 2010-02-03 07:25:15 UTC
Created attachment 67571 [details]
Fix for this issue
Comment 2 noel.power 2010-02-26 10:21:48 UTC
can you regenerate the patch, its impossible to see the difference, also maybe
can you explain in more detail. 
you mention changing the names space, can you give some example before & after
the patch ( some test code macro also would help demonstrate what you mean )
Comment 3 lihuiibm 2010-02-28 09:14:37 UTC
Created attachment 68063 [details]
Because new file(api-to-idl.pl) has the windows crlf(s), but the old api-to-idl.pl does not have windows crlf(s), so the diff file has some mistake. I am very sorry for my negligence, please use the new patch.
Comment 4 noel.power 2010-03-01 09:38:08 UTC
>I am very sorry for my negligence, please use the new patch.
well I don't think it is that serious/big a problem ( just makes the patch
impossible to read :-) ), so its just the name of the idl file is changed? I
don't see how that would fix a namespace clash. Please can you give a simple
example demonstrating the problem, this would be very useful ( doesn't need to
be a test document, just something ( even a couple of lines of macro code in the
issue ) to illustrate the problem) 
Comment 5 lihuiibm 2010-03-01 10:26:35 UTC
Created attachment 68075 [details]
Sample file for this issue
Comment 6 lihuiibm 2010-03-01 10:27:06 UTC
Created attachment 68076 [details]
Test data file for this issue.
Comment 7 lihuiibm 2010-03-01 10:33:53 UTC
Noel, this is not a namespace issue, because some idls generated by ADO have the
same name with some idls generated by DAO. Such as LockTypeEnum.idl, ADO has
this enum(LockTypeEnum), DAO also has this enum, so file LockTypeEnum.idl of DAO
will override file LockTypeEnum.idl of ADO, so the constant in LockTypeEnum.idl
of ADO can't be registered. 
Comment 8 lihuiibm 2010-03-01 11:41:29 UTC
Noel, this is not a namespace issue, because some idls generated by ADO have the
same name with some idls generated by DAO. Such as LockTypeEnum.idl, ADO has
this enum(LockTypeEnum), DAO also has this enum, so file LockTypeEnum.idl of DAO
will override file LockTypeEnum.idl of ADO, so the constant in LockTypeEnum.idl
of ADO can't be registered. 
Comment 9 noel.power 2010-03-01 15:11:52 UTC
I really didn't want a test document ( and sample test data ) to help me
understand the error ( I didn't want you to go to that much trouble ) such test
documents are *great* for regression testing but are too complex to demonstrate
what is in fact quite a simple problem. Luckily I understood the problem from
your statement 

"this is not a namespace issue, because some idls generated by ADO have the same
name with some idls generated by DAO. Such as LockTypeEnum.idl, ADO has
this enum(LockTypeEnum), DAO also has this enum, so file LockTypeEnum.idl of DAO
will override file LockTypeEnum.idl of ADO"

and didn't need to look at the test document

the explanation above tells me nearly exactly what is going on which is that 2
LockTypeEnum.idl files are produced ( each containing different content and
namespace ) where one *file* is overwritten by the other.

Regarding the patch, know that I know what is going it this seems very sensible.
My only thought/comment is that perhaps we should be separating all modules (
excel, ado, dao, word, etc ) each into separate directories not just dao & ado.
( but perhaps this is something something to think about doing in another step )
Comment 10 noel.power 2010-03-09 13:04:38 UTC
please take over and commit and upstream this patch