2 Replies Latest reply on Oct 8, 2015 5:19 AM by yakumoklesk

    ComputeSum native extension sample bad results

    yakumoklesk

      Hi, I just landed in the world of native extensions of Flash, and tried to use the sample.dll extension for computeSum example.

       

      I build the 64 version of the dll with VisualStudio 2010. It executes, and can be debugged, but the second argument to the function, no matter its value, is always converted to native long 0(zero). When the value is traced in the .jsfl script it gives the correct value, but in the native part is converted to zero and so the returned value of the sum is incorrect.

       

      I know it is only a sample, and that this may not occur to my own native library for other purposes, but I need to know if there is an internal bug in the flash native API in order to not have more headaches than needed when debugging my code.

       

      Thanks in advance,

       

      David.

        • 1. Re: ComputeSum native extension sample bad results
          sinious Most Valuable Participant

          While this isn't a definitive answer, I've found the return values in my library code (mostly Android so Java for me) simply needed to be handled using the correct methods for the type of data.

           

          I found this to be a very useful (and fairly recently updated) great resource explaining the entire native extension process from AS<-interface->Native in a language neutral (or perhaps C-under-the-hood) way:

          http://help.adobe.com/en_US/air/extensions/air_extensions.pdf

          • 2. Re: ComputeSum native extension sample bad results
            yakumoklesk Level 1

            Somehow, it seems that the passed number arguments just occupies twice in the argv, so the offset of the first argument is 0, but the offset of the second argument is not 1, but instead 2.

             

             

            Has somebody any explanation about this? Is there any compiler parameter that i should change to get the correct pointer size? At the moment I am using a macro for accessing the arguments that just multiplies by 2 to get the "real" offset.

             

             

            Any idea would be much appreciated. At the moment I suppose that I can continue with this workaround.

             

             

            David.