5 Replies Latest reply on Jun 29, 2014 1:37 PM by Amy Blankenship

    FLEX debugger not hitting breakpoints, because Flash sometimes embeds source file paths with wrong letter case?

    James22s22 Level 1

      I was trying to figure out why breakpoints were working fine for source files in some locations but not others.  FlashDevelop's debugger (which I believe is actually the FLEXSDK debugger) was successfully connecting, tracing output, and hitting breakpoints in SOME files, but not others.


      I downloaded SWFInvestigator from Adobe Labs and checked the embedded debug paths for various source files to see what was going on.


      I discovered that files in which no breakpoints could be hit had their paths embedded in all lowercase (e.g. "c:\users\username\desktop\source\myproject" instead of "C:\Users\username\Desktop\source\MyProject").


      So I have two questions:


      First, is this a Flex debugger issue, or a FlashDevelop plugin issue? Letter case shouldn't matter or interfere with matching file paths in Windows.


      Second, what could possibly influence the letter case of embedded paths in a SWF output by Flash Professional (CS6), such that they are sometimes all lowercase and other times maintain the same case from the file system?  And why would that affect a debuggers ability to hit breakpoints in Windows 7?  I am compiling in multiple ways. Sometimes clicking Publish within Flash. Sometimes the file being published is not even open in Flash, and my JSFL script file is passed to Flash.exe containing embedded file paths to open the document. Usually, everything seems to work fine, no matter where I publish from, regardless of whether the FLA file is open or not. I'm honestly starting to believe that it depends on how the FLA was last opened in Flash Professional, as though it saves some sort of last access path internally and uses that to embed debug information.

        • 1. Re: FLEX debugger not hitting breakpoints, because Flash sometimes embeds source file paths with wrong letter case?
          Amy Blankenship Level 4

          In Flash, look in the AS Source Path tab and make sure the cases are correct. It helps to use relative paths where possible, as that cuts down the possibility of issues. sourcePath.PNG


          I am not sure why Flex is more case sensitive than the OS it runs on, but I've experienced other issues related to this, such as Flash Builder's code hinting not working in the "Shared" directory when Flash thinks the path is "shared."


          Also, you'll probably have set up source paths to these in your IDE. You may want to check those as well.

          1 person found this helpful
          • 2. Re: FLEX debugger not hitting breakpoints, because Flash sometimes embeds source file paths with wrong letter case?
            James22s22 Level 1

            I don't think it's the source path in my case, because it's simply the dot ".", although I did check that because it would most likely influence the embedded paths.
            In the library path, I use relative paths exclusively, since all my individual project folders exist in the same "source" folder.

            Here's how I arrived at the conclusion that something more complex or "stateful" must be occuring:

            I publish my files with a one-click application, which does the following

            • updates version timestamps (static constants) in specific files via regex match
            • fills in a JSFL template with the FLA filename and writes the JSFL file to disk, then passes the JSFL file path to flash.exe for publication
            • the JSFL then runs a command, which signals the main application via cross-process communication that the script has finished publishing


            That all makes it easy for me to update and publish multiple projects and deploy them, with a single click.  Here is the JSFL template I created, which has been drastically simplified since the days where it used to search to see if the file was open in Flash, select the document, and call publish.  Now it just uses the publishDocument method to silently publish files without opening them.


            var filepath = "FLAFILEPATH"; //template parameter: the URI (beginning with "file:///") of the FLA file to publish

            fl.publishDocument( filepath, "PUBLISHPROFILENAME" );



            The C# app replaces the strings in all caps with the actual values.  The COMPLETECOMMAND is actually populated with the application's own executable path, along with a "complete" switch, which lauches a 2nd instance, which handles the complete switch by broadcasting a signal over an interprocess channel and then terminates.  The main instance captures the signal, triggers a wait handle, and continues with publishing the next file.  Here is the core code for it:


            private string fillTemplate( string fla_directory, string fla_filename, string publish_profile_name )


                string fileuri = "file:///" + Path.Combine( fla_directory, fla_filename ).Replace( '\\','/' );

                return EmbeddedResources.OpenAndPublish //JSFL template file embedded as string resource

                    .Replace( "FLAFILEPATH", HttpUtility.JavaScriptStringEncode( fileuri ) )

                    .Replace("COMPLETECOMMAND", HttpUtility.JavaScriptStringEncode( "\"" + Application.ExecutablePath + "\"" + " -publishcomplete" )) //call self with -publishcomplete switch to signal main instance's publishCompleteSignal

                    .Replace("PUBLISHPROFILENAME", HttpUtility.JavaScriptStringEncode( publish_profile_name ) );



            private static readonly string FLASH_PATH = @"C:\Program Files (x86)\Adobe\Adobe Flash CS6\Flash.exe";

            public void publish( string fla_directory, string fla_filename, string publish_profile_name )



                string template = fillTemplate( fla_directory, fla_filename, publish_profile_name );

                string curdir = Environment.CurrentDirectory;

                string tempJSFLfilepath = Path.Combine( curdir, "temp_script.jsfl" );

                File.WriteAllText( tempJSFLfilepath, template );

                Process p = Process.Start( FLASH_PATH, tempJSFLfilepath );

                Program.publishCompleteSignal.WaitOne( 30000 ); //timeout after 30 seconds



            Here's where it gets interesting.  The FLAFILEPATH has ALWAYS been passed in as all lower case, yet this publication method has worked 99% of the time for hundreds of publish operations every day.  This applies to both the publication of the first SWC, which is referenced by the second published SWF (both were being published with lowercase paths), yet the paths for the main SWF were remaining in lowercase, while those in the referenced SWC were maintaining the correct case from the file system.


            So there may be any number of things going on here.  SWCs may be published differently than SWFs, such that SWCs always have the correct letter case for debug source files, regardless of how the source FLA project was opened.  Ensuring the path passed to publishDocument uses the right case definitely fixes the problem, but it doesn't explain why it usually worked, despite having always been passing a lowercase string.  The only variable I can think of in all of this is Windows itself or Flash, such as whether the document was open in Flash at the time the silent JSLF publishDocument command ran, and how that FLA was last opened (via shortcut, via "recent documents" in Flash, via recent documents in Windows.  It has to be something, even if it's something as obscure as how the folder path was last accessed in windows, although I strongly suspect it's just how (in terms of path case) the FLA was last opened in Flash.


            In any case, I'm happy that passing the right case to JSLF's publishDocument command fixes the problem, so I'm not going to spend any more time trying to figure out how opening the FLA in various ways could affect the embedded debug paths.  The only thing that should be done is to address how paths with the wrong case are handled when they do get embedded that way for whatever reason.  Perhaps the flex debugger should be updated to use case-insensitive matches in case-insensitive file systems, unless, perhaps, this is a FlashDevelop debugger issue after all.

            • 3. Re: FLEX debugger not hitting breakpoints, because Flash sometimes embeds source file paths with wrong letter case?
              Amy Blankenship Level 4

              Might be worth your time to just set up your projects in Flash builder and use "build all."

              • 4. Re: FLEX debugger not hitting breakpoints, because Flash sometimes embeds source file paths with wrong letter case?
                James22s22 Level 1

                I doubt it.  Flash builder probably won't update version timestamp constants in specific files, it unlikely has a checkbox next to each project in the main interface which I can simply check or uncheck to publish in debug mode, and I seriously doubt it would deploy specific files to my web server (with optional per-file timestamped backup) << literally all of this with one click.

                • 5. Re: FLEX debugger not hitting breakpoints, because Flash sometimes embeds source file paths with wrong letter case?
                  Amy Blankenship Level 4

                  It actually is able to keep up with what it's compiled recently and what it hasn't. It also has a "Build selected projects" hidden away under Project>Clean for when you throw off the native functionality by compiling in Flash or by updating a resource that doesn't write to an *.as file.