1 person found this helpful
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.
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
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.
Might be worth your time to just set up your projects in Flash builder and use "build all."
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.
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.