9 Replies Latest reply on Oct 5, 2006 8:18 AM by GeorgeWS

    communicate to the wrapper

    GeorgeWS Level 1
      I have been trying this for weeks.
      I want to have test.html?SupplierID=3

      So in the wrapper I add <param name="flashVars" value="SupplierID" /> and in the EMBED I add flashVars="SupplierID=3"

      when I go in the browser to test.HTML?SupplierID=3 The application does not get the variable. If I go to test.SWF?SupplierID=3 The application gets the variable in the Application.application.parameters.SupplierID but does not send it over to my CFC.
      Any advice would be great
      Thanks
      George
        • 1. Re: communicate to the wrapper
          Peter Farland Level 3
          Could you use the flash.external.ExternalInterface API to talk to JavaScript to get this info for you?

          http://livedocs.macromedia.com/flex/2/langref/flash/external/ExternalInterface.html
          • 2. Re: communicate to the wrapper
            GeorgeWS Level 1
            Thanks,
            But that not what I want. I actually have know idea about wht the link you sent is talking about. This should be WAY easier than configuring and all that. I just want:

            URL
            test.cfm?SupplierID=3

            TEST.CFM
            has the wrapper where I changed the AC_FL_RunContent - flashVars to have SupplierID=#SupplierID# and I added the flashVars to the Object and Embed tags.

            In the TEST.MXML
            I have a remote Object with:
            <mx:arguments>
            <supplierid>
            (Application.application.parameters.SupplierID)
            </supplierid>
            </mx:arguments>

            I was thinking that this would send the SupplierID of 3 to the TEST.CFC

            TEST.CFC
            Im using the <cfparam name=SupplierID default ""> Just like I always would in Cold Fusion.

            What could be wrong? The TEST.CFC never gets the variable SupplierID

            Thanks
            George
            • 3. Re: communicate to the wrapper
              inlineblue Level 1
              Maybe you just mistyped it, but you should using curly braces {} and not parens () around Application.application.parameters.SupplierID.

              In any case, can you confirm that Application.application.parameters.SupplierID actually has the correct value? Use an Alert box to make sure.
              • 4. Re: communicate to the wrapper
                GeorgeWS Level 1
                Thanks, but is was a miss type for my sample. I have the curly brackets in my app. I have a button that passes the Application.application.parameters.SupplierID to a different CFM page that output to data to EXCEL so I know the variable is there and working. I can not believe how hard this is. to just pass the URL variable over to the CFC. In ColdFusion Flash forms it was sooooo easy. What happened? ANY HELP WOULD BE GREAT SINCE I HAVE BEEN WORKING ON THIS SIMPLE SMALL PART FOR WEEKS. I have run through many many samples that are cluttered withother non usefull stuff. even the Hello World sample is clutered with junk and doesnt even show how to send variable back and forth only get.

                HELP!!!!!!!!!!!!!
                • 5. Re: communicate to the wrapper
                  mike_morearty Level 1
                  I played around with this, and I don't know for sure, but here is what I *think* is happening: It seems that for some reason, the data binding to {Application.application.parameters.SupplierID} is never being executed, so the argument to the RemoteObject is remaining as null.

                  In my test case, I was able to work around the problem: First assign Application.application.parameters.SupplierID to some *other* bindable variable, and then assign *that* variable into the argument of the RemoteObject.

                  Here is the bindable variable, 'supplierid':

                  <mx:Script>
                  <![CDATA[
                  [Bindable]
                  private var supplierid:String;
                  ]]>
                  </mx:Script>

                  It is initialized when the app sends the 'creationComplete" event:

                  <mx:Application xmlns:mx=" http://www.adobe.com/2006/mxml"
                  creationComplete="supplierid=parameters.SupplierID">

                  The 'supplierid' argument is bound to that 'supplierid' bindable variable:

                  <mx:arguments>
                  <supplierid>
                  {supplierid}
                  </supplierid>
                  </mx:arguments>

                  To me this seems like a bug, although I may be wrong, there may be some explanation of why this is the correct behavior; but if nothing else it's certainly a usability issue. I will log it as a bug.

                  By the way, to narrow down the problem, I used the debugger. I set a breakpoint on the line that was going to invoke a method of my remote object; then, in the debugger's variables view, I looked at application.parameters to see if they came through correctly there (they did), and also looked at myRemoteObject.myMethod.arguments to see if they came through correctly there (they did not -- the supplierid was null). So I figured okay, the problem is on the Flex side, and it did get as far as application.arguments, so then I started experimenting.

                  Hope this helps, let me know if this workaround works.

                  -Mike
                  • 6. Re: communicate to the wrapper
                    mike_morearty Level 1
                    On further thought, I think it's pretty clear why that is happening: the data-binding expression was evaluated and assigned into the RemoteObject before the application.parameters variable was initialized. In fact, that's why my first attempt at fixing it with a separate bindable variable didn't work: when I assigned directly to the variable when it was created, with "[Bindable] private var supplierid = Application.application.parameters.SupplierID", I got null, because my private variable was being initialized before application.parameters got initialized. That's why I instead had to defer initialization until the creationComplete event came in.

                    That's the kind of thing I meant when I said I'm not entirely sure this is a bug, even though it "feels" like it should work. Order-of-initialization things are tricky, there's always *some* order which is going to be wrong. I think changing Application.parameters to be [Bindable] would fix it, but actually I'm not even sure if that's feasible, because it is the individual *members* of Application.parameters, such as SupplierID, that we are actually binding to; and those are dynamic members, so I don't think they can be bindable.

                    Anyway, just rambling now, but perhaps this helps shed a little more light on the problem...
                    • 7. Re: communicate to the wrapper
                      GeorgeWS Level 1
                      Thanks alot for your help. I tryed all day with no luck. The only way I can get this to work is to send the variable to the SWF not the CFM. The bummer is that I cant use the wrapper. That means I cant really use the app because I cant tell the 2000 people that use the application to download the Flash 9. This is a MAJOR WRENCH, I cant build anything else unless this gets resolved because all of my apps need either a supplierID or employeeID etc.

                      Thanks for looking

                      George
                      • 8. Re: communicate to the wrapper
                        mike_morearty Level 1
                        Hmm. There must be a way to fix this. There are many ways to communicate between a swf and its html.

                        I'm wondering if you accidentally modified the wrapper in the wrong place. After all, the default wrapper has *three* places where it loads a swf: the first is loading playerProductInstall.swf if the user doesn't have the correct version of flash; the second is the javascript way of loading the swf; and the third is the non-script way of loading it. So, this is the change:

                        if ( hasProductInstall && !hasRequestedVersion ) {
                        // ignore this call to AC_FL_RunContent()
                        } else if (hasRequestedVersion) {
                        ...
                        AC_FL_RunContent(
                        ...
                        "flashvars",'historyUrl=history.htm%3F&lconid=' + lc_id + '&supplierid=ID_GOES_HERE',
                        ... );
                        }
                        </script>
                        <noscript>
                        <object ...>
                        <param name="flashvars" value="supplierid=ID_GOES_HERE">
                        <embed ... flashvars="supplierid=ID_GOES_HERE" ... >
                        </object>
                        </noscript>

                        Also, did you look in the debugger at all the members of application.parameters? I'm just wondering if it somehow got in there in the wrong place due to a typo or something, e.g. leaving out the "&" separating that flashvar from the others.

                        If you can't get any of that to work, there are other ways to pass data back and forth between the HTML wrapper and the swf:

                        - Easiest: You can use the FABridge library.
                        - Second-best: You can use the flash.external.ExternalInterface class.
                        - Old school: You can use the flash.system.fscommand() function.
                        • 9. Re: communicate to the wrapper
                          GeorgeWS Level 1
                          Mike,
                          thanks for trying so hard. I have been at this for weeks (it seems) I have the wrapper correct. All 3 spots are modified just as you show.I dont know a thing about FABridge. I did read about the flash.external.ExternalInterface that seemed to have lots of setup and configuring, and im sure pretty sure i could never make it work with out clear samples. The pages that explain how to use this kind of stuff is way to complicated and the samples full of extra garbage that who knows whats going on. This is very frustrating. I will look again at the flash.external.ExternalInterface, im disiplointed that this is so hard this is the 3rd thing I have been caught up on to build one simple application its been about a month. So much for rapid development. Thanks for looking. Some answers are better than non.

                          George