|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2001-06-07 16:22 UTC] pauls at dataworx dot com dot au
Firstly, my apologies for submitting this as a seperate bug report, it should be added to 11250, however I know my passsword & my email address doesn't seem to suffice as a user name...I get rejected. I downloaded the latest cvs & used the code in ext/com/conversion.c as a (little) starting point. Noted that the code required in php_pval_to_variant() is still 'TO DO' and that the code in php_variant_to_pval() for VT_ARRAY probably won't ever get called unless someone purposely designs a COM component that returns a VT_ARRAY with no type....unlikely...but in any case the existing code would break with arrays of type VT_ARRAY|VT_VARIANT which are very common with VB programmers (unfortuntely they write a lot of COM objects). I have written all of the code nesessary to handle typed and non-typed arrays as value/by ref arguements (the most common type of array arguement to VB COM objects) and to handle return arrays of by value/by reference types using the php snapshot version 4.0.4pl1 snapshot (I know there have been a lot of changes since then, but 4.0.4pl1 works for me and I don't have the time or expertise to pull different versions from cvs & try them). Also, in reading the bug reports before delving into this, I noted that someone needed to be able to accept variant fields of type VT_C (currency) from database requests... so I added (& tested) that while I was there. As I said, I'm definitely a cvs novice, so if you are interested in blending this code into the later releases (I would definately mess it up !), and receiving a little VB6 test COM dll & php calling code, let me know who to forward it to via email & I will be more than happy to oblige. Thank you for your your good work !!! Paul Shortis PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Thu Dec 26 16:01:31 2024 UTC |
Hello Harold, I was referring to the following code snippet in "conversion.c" from last weeks latest cvs download PHPAPI int php_variant_to_pval(VARIANT *var_arg, pval *pval_arg, int persistent, int codepage) { /* Changed the function to return a value for recursive error testing */ /* Existing calls will be unaffected by the change - so it */ /* seemed like the smallest impact on unfamiliar code */ int ret = SUCCESS; /* Add SafeArray support */ switch(var_arg->vt & ~VT_BYREF) { case VT_ARRAY: { As you know the variant type VT_ARRAY is always OR'd with the array element type even if it is VT_VARIANT so you will never get a case where var_arg->vt & ~VT_BYREF resolves simply to VT_ARRAY (it should always be VT_ARRAY|* where * is the element type. I suspect from your comments that you may be looking at different code to me. Also, while I see the rationale behind using the VARIANT class, it makes the syntax of passing array arguements to COM objects different to passing arrays to other functions and a lot more cumbersome when it can be implimented transparently. In any case I will email my changes (I haven't bothered with codepage suppoty) to phanto's email address (cos I don't have yours). Regards, Paul