emyHamed / ff-activex-host

Automatically exported from code.google.com/p/ff-activex-host
0 stars 0 forks source link

Arrays aren't handled in the plugin #8

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

Arrays which are returned from functions in the ActiveX control can't be 
used. Also parameters which are arrays can't be parsed in the event 
handler.

What version of the product are you using? On what operating system?

r33. XP SP3.

Please provide any additional information below.

The discussion took place in the group.
http://groups.google.com/group/ff-activex-host/browse_thread/
thread/43fd8119eef7f9a7

Original issue reported on code.google.com by mamun.th...@gmail.com on 5 Nov 2009 at 12:54

GoogleCodeExporter commented 8 years ago
Scope of this fix is much greater than I originally anticipated. It will have 
to wait
a bit longer.

Original comment by leeor.ah...@gmail.com on 12 Nov 2009 at 2:48

GoogleCodeExporter commented 8 years ago
Arrays can now be passed from ActiveX controls to JS, but not the other way 
around.

The returned arrays behave almost identically to JS arrays - they are 
essentially JS
objects. You can assign more elements and even functions to these arrays. Since 
they
behave like object you can also treat them as 'dictionaries' - indexing members 
as
strings and accessing them as properties of the object.

Notice that the default 'length' property is not handled identically to a 
standard JS
array, and it is advisable to to assign any values to it, just read it.

Original comment by leeor.ah...@gmail.com on 7 Dec 2009 at 5:10

GoogleCodeExporter commented 8 years ago
The attached patch intends to allow JavaScript to pass arrays to ActiveX 
controls.

Original comment by esiro...@gmail.com on 2 Mar 2010 at 6:44

Attachments:

GoogleCodeExporter commented 8 years ago
My patch didn't handle object reference cycles.  Here's something that does.

Forgive the spacing.

        {
            NPIdentifier *identifiers = NULL;
            uint32_t identifierCount = 0;
            NPObject *object = NPVARIANT_TO_OBJECT(*npvar);

            if (NPNFuncs.enumerate(instance, object, &identifiers, 
&identifierCount))
            {
                CComSafeArray<VARIANT> variants;

                for (uint32_t index = 0; index < identifierCount; 
++index)
                {
                    NPVariant npVariant;

                    if (NPNFuncs.getproperty(instance, object, 
identifiers[index], &npVariant))
                    {
                        if (npVariant.type != 
NPVariantType_Object)
                        {
                            CComVariant variant;

                            NPVar2Variant(&npVariant, 
&variant, instance);
                            variants.Add(variant);
                        }

NPNFuncs.releasevariantvalue(&npVariant);
                    }
                }

                NPNFuncs.memfree(identifiers);
                *reinterpret_cast<CComVariant*>(var) = variants;
            }
        }

Original comment by esiro...@gmail.com on 12 Mar 2010 at 8:18

GoogleCodeExporter commented 8 years ago
Any reason why you prefer not to handle NPVariantType_Object type objects 
recursively?

Thanks for the code, I hope to test it soon and add it to the project.

Original comment by leeor.ah...@gmail.com on 14 Mar 2010 at 12:01