Detect debug or release build from AS3?

Hi, is it possible to detect the build type (debug or
release) of an ActionScript Project using AS3 code?
I use a FPS counter, but it would be nice if it would only
show up in the debug build.
Thanks a lot in advance!

var isDebug:Booleab = (new Error().getStackTrace().search(/:[0-9]+]$/m) > -1);
Here are the sources that I found this answer...
http://www.tekool.net/blog/2009/06/27/identifying-a-debug-or-release-swf-file-at-runtime/
http://michaelvandaniker.com/blog/2008/11/25/how-to-check-debug-swf/
Here's yet another take on solving this issue by using the compiler argument: "-define=CONFIG::debug,true"
Personally I prefer the above solution.
http://edsyrett.wordpress.com/2008/09/22/using-conditional-compilation-to-detect-debug-mod e/

Similar Messages

  • What is the primary difference between Debug and Release build?

    I'm coming from the world of VS, where there's a clear distinction between a Release and Debug builds. In Xcode I can't seem to see how two are different and how would I benefit from, say, a Debug build. Can someone explain this for me?

    The differences between the Xcode debug and release builds are similar to the differences you'll find on any other system, though the Xcode interface might not present them as obviously. Basically, a debug build preserves all kinds of information that was developed during compilation but is no longer necessary at runtime. The presence or absence of this information (e.g. symbol tables and mappings which provide the original name of each source code variable and the source code line number corresponding to each instruction), becomes increasingly obvious as you use gdb and other debugging tools.
    We normally would never want to release a debug version (in the iOS case, of course, it would never be accepted) because the binary is usually much larger and the performance will probably be compromised as well. For example, a typical debug build will have many perfomance optimizations turned off because these can make debugging more difficult. It's also common to enable "assert" statements in a debug version. These will bring the program down rather than giving the user any options or attempting recovery.
    For more info specific to Xcode, see [Build Configurations|http://developer.apple.com/library/ios/documentation/DeveloperTo ols/Conceptual/XcodeBuildSystem/400-BuildConfigurations/build_configs.html#//appleref/doc/uid/TP40002692-SW7] in the +Xcode Build System Guide+. To get into lower level details, refer to the gcc docs, maybe starting with [3.9 Options for Debugging Your Program or GCC|http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html]. You might also want to take a look at your Target Build Options for the Debug configuration (Project->Set Active SDK->Use Base SDK and Project->Edit Active Target->Build). There's a one-to-one mapping between many of these settings and the gcc options.
    \- Ray
    p.s.: Didn't mean to repeat Xnav's points. As usual, I was still editing long after he posted! To clarify one difference: Selecting the Edit Active Target menu item gets you to the same place as double clicking on the icon for the active target in the Targets group of the Groups & Files tree. - R
    Message was edited by: RayNewbie

  • Debug vs release build on win32, DB_RECOVER vs DB_RECOVER_FATAL

    I'm seeing some surprising behavior during recovery, using Berkeley Db 4.8.24.
    Our application is a long-lived process wrapping a set of berkeley db databases. In general, on startup the application calls DB_ENV::open() with DB_RECOVER and DB_REGISTER. The intention is, essentially, "recover your state prior to termination", and then use bdb for persisting state.
    After a recent crash, our process failed to start with "PANIC: fatal region error detected; run recovery". Now, there are a couple of interesting problems:
    1) The db had been created using a release build of our code and of bdb. If I attempt to restart from a debug build, __env_struct_sig() returns a different value. Because of this, env_region::__env_attach enters this conditional block:
    __db_errx(env, "Build signature doesn't match environment");
    ret = DB_VERSION_MISMATCH;
    goto err;
    Afterwards, the database is successfully recovered! On the release build, that block is not entered, so the function goes down to:
    if (renv->panic && !F_ISSET(dbenv, DB_ENV_NOPANIC)) {
    ret = __env_panic_msg(env);
    goto err;
    The error message is printed, and the db is not recovered. The question is: how can an "accidental" error (mismatching signatures) result in successful recovery, whereas "normal" behavior (running with the same build signature) result in a recovery failure?
    2) If I call open() with DB_RECOVER_FATAL, everything appears to work fine. I've read:
    http://www.oracle.com/technology/documentation/berkeley-db/db/programmer_reference/transapp_recovery.html
    and
    http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/C/envopen.html#envopen_DB_RECOVER_FATAL
    and
    http://www.oracle.com/technology/documentation/berkeley-db/db/ref/program/errorret.html#DB_RUNRECOVERY
    But I think the documentation is unclear: when wouldn't I do DB_RECOVER_FATAL? What's the advantage of DB_RECOVER over DB_RECOVER_FATAL? Is it safe to try DB_RECOVER, and on failure try DB_RECOVER_FATAL?
    Thanks

    Thanks for your replies, Sandra.
    So if I understand things correctly, it's always safe to perform catastrophic recovery, but it could take longer than non-catastrophic? Will _FATAL ever cause the application to lose data?
    I'm not sure I understand the notion of checking whether recovery is required -- I have been thinking of recovery as the process of getting data back from the .db and log files. If you don't do recovery, you don't get your data back, so it's always required, right?
    Assuming we can get data back without performing recovery in some cases, is it reasonable to do this:
    1) Try open() with DB_REGISTER | DB_FAILCHECK
    2) If 1) fails, try DB_REGISTER | DB_RECOVER
    3) If 2) fails, try DB_RECOVER_FATAL
    Regarding the cause of failure: the release / debug build was one issue that intersected with our recovery processes, but in general, release / debug build experiments aside, recovery has proven inconsistent for us. When our servers (i.e. the hosts) undergo routine restarts, recovery is generally solid. When the process dies unexpectedly during the day, it fails to recover (apparently without a specific cause) around one in five times (my guess).
    We can't reliably reproduce the failure to recover, but in one instance we observed that recovery failed; after removing all files aside from the *.db files and the transaction logs, recovery succeeded. Is it prudent to remove these files (e.g. __db.00*, __db.register) as a matter of routine on/before startup?
    Thanks again!

  • Enabling "view source" on a debug (non-release) build

    Hi All,
    Is there a way I can enable the "view source" context menu option for my Flex app when it is built in debug mode?  I know I can export a release build and enable it from there, but I want that option to be on for my debug modes as well.  That allows other any developer in our organization to simply right click on an app running in our development environment and see the source that the app was built with.
      -Josh

    Thanks for your replies, Sandra.
    So if I understand things correctly, it's always safe to perform catastrophic recovery, but it could take longer than non-catastrophic? Will _FATAL ever cause the application to lose data?
    I'm not sure I understand the notion of checking whether recovery is required -- I have been thinking of recovery as the process of getting data back from the .db and log files. If you don't do recovery, you don't get your data back, so it's always required, right?
    Assuming we can get data back without performing recovery in some cases, is it reasonable to do this:
    1) Try open() with DB_REGISTER | DB_FAILCHECK
    2) If 1) fails, try DB_REGISTER | DB_RECOVER
    3) If 2) fails, try DB_RECOVER_FATAL
    Regarding the cause of failure: the release / debug build was one issue that intersected with our recovery processes, but in general, release / debug build experiments aside, recovery has proven inconsistent for us. When our servers (i.e. the hosts) undergo routine restarts, recovery is generally solid. When the process dies unexpectedly during the day, it fails to recover (apparently without a specific cause) around one in five times (my guess).
    We can't reliably reproduce the failure to recover, but in one instance we observed that recovery failed; after removing all files aside from the *.db files and the transaction logs, recovery succeeded. Is it prudent to remove these files (e.g. __db.00*, __db.register) as a matter of routine on/before startup?
    Thanks again!

  • Export release build from WAMP-2-LAMP questions

    Having some difficulties with exporting a release build to move onto a linux host. Looking for a better solution that will ease moving the code (build) to Prod env/version.
    Other than the Flash Builder breaking when I start changing the server and path values that reflect the linux paths - I'm unable to export a release with the errors.Is it a build-time thing that it needs all this config - or is it in the release (post-build) that I do all my config edits?
    Am I going about this the right way ? - or is there an easier way to export a release with the server settings as a config file - or a way I can just have one version in FB rather than trying to hack a production release to linux from windows?
    Using the PHP services generated by FB - a folder called .model has the service config file for all the services - XYZ.fml
    ie
        <annotation name="ServiceConfig">
          <item name="PHP_RELATIVE_LOCATION">XYZ/services/HactionService.php</item>
          <item name="PHP_SERVER_ROOT">C:\Program Files\Zend\Apache2\htdocs</item>
          <item name="DEFAULT_ENTITY_PACKAGE">valueObjects</item>
          <item name="PHP_SERVICES_FOLDER">C:\Program Files\Zend\Apache2\htdocs\XYZ\bin-debug\services</item>
          <item name="PHP_LOCATION">C:\Program Files\Zend\Apache2\htdocs\XYZ\services\HactionService.php</item>
          <item name="LINKED_FILE">HactionService.php</item>
          <item name="PHP_SERVER_ROOT_URL">http://localhost/</item>
          <item name="ABSOLUTE_ENDPOINT">http://localhost/XYZ/bin-debug/gateway.php</item>
          <item name="PHP_CLASS_NAME">HactionService</item>
        </annotation>
    noticed the amf_config.ini file and that has linux paths for Zend - and I think that's ok - but the paths are reverse for on and not the other.
    webroot =C:/Program Files/Zend/Apache2/htdocs
    zend_path = C:\apache\PHPFrameworks\ZendFramework
    Details - Win7, FB Beta 2, WAMP
    martin

    Hi Martin,
       Below are the steps to do an export release build and deploy the same on to any required target server (in your case MAMP)
    Export release build of the project with the existing server settings:
    1. Do export release build of the project.
    2. zip the bin-release folder contents into say <xyz>.zip
    3. upload xyz.zip to the target server and unzip its contents to /wwwroot/<xyz>/
    Additional configurations and installations:
    1. Zend installation: Your current local webroot would have a folder called ZendFramework, zip it and upload it to your server.
       Unzip the framework in your web root. If Zend Framework is installed in a location other than webroot, then you would have to update the amf_config.ini file. The amf-config.ini file will be found in the <xyz> folder
      -    Uncomment and modify zend_path variable to the absolute path of the Zend framework directory.
      -    Set amf.production to true.
      -    Update webroot with the absolute path to the web root on the server
    2.  Ensure that any of the php services used by the application is already deployed on the server.
         Ensure that the same directory structure is maintained for the services deployed.
    Hope it helps.
    Regards,
       Latha

  • WD Java Remote Debug problem: Release Process from debugging

    Hi Community,
    when I used to debug Web Dynpro Java from the SAP Developer Studio (eclipse) to a remote host (Portal AS NW Java), it works fine for the first run. After disconnecting the remote debug session (server0), I changed the coding and try to debug again with the effect that the old coding is still used from the server process (server0) even though the parameter "Create and Deploy archive" is set (enabled) in the debug configuration. Furthermore the funktionality of "Relase process from debugging" option in the J2EE Engine dosn't react / work.
    I think that the debug session is still running and the Developer Studio is not able to send any "Kill" statement to the server process for ending this session.
    I tried following:
    A. Rebuild Project and Deploy the archive on the "normal" way
    B. Reopen the Developer Studio itself
    C. Start the Project in debugmode again and chose the option "Terminate All"
    ...all without any success.
    The only way is to restart the whole server process server0 again with the same trouble after the first debug.
    Did any of you have a clue or experience to clear or kill the debugsession from the process so that next debugsessions can be started, please reply.
    Thanks
    Used Basic Manuell
    http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/849170e3-0601-0010-d59e-ddfce735fac5

    So, I'm having the same issue, but it's like I'm chasing down a port. The first time I got these error messages
    Connecting to the database DEV.
    Executing PL/SQL: ALTER SESSION SET PLSQL_DEBUG=TRUE
    Executing PL/SQL: CALL DBMS_DEBUG_JDWP.CONNECT_TCP( '555.12.18.288', '5950' )
    ORA-30683: failure establishing connection to debugger
    ORA-12535: TNS:operation timed out
    ORA-06512: at "SYS.DBMS_DEBUG_JDWP", line 68
    ORA-06512: at line 1
    Process exited.
    Disconnecting from the database DEV.Our network staff found a bunch of other denials in the firewall logs
    /5185
    /5200
    /5236
    /5815
    /5950 Now that they've those allowed, I tried to start debug again, and this time I got
    Connecting to the database DEV.
    Executing PL/SQL: ALTER SESSION SET PLSQL_DEBUG=TRUE
    Executing PL/SQL: CALL DBMS_DEBUG_JDWP.CONNECT_TCP('555.12.18.288', '6266' )
    ORA-30683: failure establishing connection to debugger
    ORA-12535: TNS:operation timed out
    ORA-06512: at "SYS.DBMS_DEBUG_JDWP", line 68
    ORA-06512: at line 1
    Process exited.
    Disconnecting from the database DEV.What gives? Do I just keep trying until I get all of the ports allowed?
    Thanks,
    ---=Chuck

  • I have a production mobile Flex app that uses RemoteObject calls for all data access, and it's working well, except for a new remote call I just added that only fails when running with a release build.  The same call works fine when running on the device

    I have a production mobile Flex app that uses RemoteObject calls for all data access, and it's working well, except for a new remote call I just added that only fails when running with a release build. The same call works fine when running on the device (iPhone) using debug build. When running with a release build, the result handler is never called (nor is the fault handler called). Viewing the BlazeDS logs in debug mode, the call is received and send back with data. I've narrowed it down to what seems to be a data size issue.
    I have targeted one specific data call that returns in the String value a string length of 44kb, which fails in the release build (result or fault handler never called), but the result handler is called as expected in debug build. When I do not populate the String value (in server side Java code) on the object (just set it empty string), the result handler is then called, and the object is returned (release build).
    The custom object being returned in the call is a very a simple object, with getters/setters for simple types boolean, int, String, and one org.23c.dom.Document type. This same object type is used on other other RemoteObject calls (different data) and works fine (release and debug builds). I originally was returning as a Document, but, just to make sure this wasn't the problem, changed the value to be returned to a String, just to rule out XML/Dom issues in serialization.
    I don't understand 1) why the release build vs. debug build behavior is different for a RemoteObject call, 2) why the calls work in debug build when sending over a somewhat large (but, not unreasonable) amount of data in a String object, but not in release build.
    I have't tried to find out exactly where the failure point in size is, but, not sure that's even relevant, since 44kb isn't an unreasonable size to expect.
    By turning on the Debug mode in BlazeDS, I can see the object and it's attributes being serialized and everything looks good there. The calls are received and processed appropriately in BlazeDS for both debug and release build testing.
    Anyone have an idea on other things to try to debug/resolve this?
    Platform testing is BlazeDS 4, Flashbuilder 4.7, Websphere 8 server, iPhone (iOS 7.1.2). Tried using multiple Flex SDK's 4.12 to the latest 4.13, with no change in behavior.
    Thanks!

    After a week's worth of debugging, I found the issue.
    The Java type returned from the call was defined as ArrayList.  Changing it to List resolved the problem.
    I'm not sure why ArrayList isn't a valid return type, I've been looking at the Adobe docs, and still can't see why this isn't valid.  And, why it works in Debug mode and not in Release build is even stranger.  Maybe someone can shed some light on the logic here to me.

  • Export Release Build on Flash Builder 4 Beta 2

    Hi Everyone,
    I have a Flex 4 project that is organized as a main app project with several related projects that are linked in, along with several libraries that get included (I use granite dataservice and tweener, among others). The project runs fine when I do a normal build, I have deployed the resulting swf independently on a web server and its working fine.
    Now, whenever I try to do 'Export release build' from the Project menu, the resulting release build doesnt run at all, and it crashes with weird errors, like for example, it first crashes because of a null reference in the partAdded method in one of the components I created, when I removed that component completely it crashed because of a type coercion error on one of the data service objects, and this goes on with all sorts of errors that never existed in the normal 'debug' version not built with the export option.
    So I have two questions:
    Does anyone have any clue what might be wrong? I would have posted examples but it looks to me like an application-wide anomaly, maybe because of it not loading the libraries or the resources correctly? I tried both build path options or merging sdk libraries into the code or using runtime libraries, didnt work, not sure if it is related.
    What exactly does 'Export release build' add for me? is the release build faster than the normal one?
    Thanks a lot.

    Hi,
    A release build optimises the compile,(no debugging code etc). The swf will be a little quicker and a lot smaller. If you are getting null pointers and data service issues maybe something in your create order is a bit out. If you have an idea of what the offending component may be see if you can set its creation policy. This would be my first thought the other could possibly be some sort of local versus network issue on the release build.
    David.

  • Compiling differently for debug and release

    I want to produce slightly different .class files for my debug and release compilations. For debug, methods like toString() should return rich information which should not be present in the release version. In fact, I want most of my debug specific code to not be included in the final release to keep ti's file size down.
    I realise I can do this by creating something like
    public interface MyGlobals {
        static final boolean DEBUG = false;
    }and implementing this on any class that needs to do debug specific work. However, I'm in a bit of a chicken and egg scenerio. This file needs to exist during development time so that every class that needs it can implement it - however, this would prevent me from dynamically changing it based on whether I'm doing a debug or release build. On the other hand, if the file is generated automatically at compile time, all the classes that need to refer to it will need to refer to a non-existant source file, which will cause problems in my NetBeans IDE.
    Is there a way around this? It would be nice if there was some sort of a configuration file you could specify to to alter how the code is generated. Something similar to C++ #ifdef.

    I realise I can do this by creating something like
    public interface MyGlobals {
    static final boolean DEBUG = false;
    /code]You should be careful about this, by the way, rember that this kind of constant value gets compiled in to classes that reference it, and java doesn't always pick up the need to recompile when the source of MyGlobals changes.
    On the other hand, if you don't declare it final then the compiler can't optimise out code that you want it to exclude for you.

  • Flex Builder 4 Export Release Build fails on OSX

    Flex Builder 4, SDK 4.1.0.16076
    When I choose Project->Export Release Build, or Export Release Build from the Export context menu, nothing happens on teh interface, but I see the following error in the log. Any thoughts on solution or workaround?
    Thanks
    D
    !ENTRY org.eclipse.ui 4 0 2011-05-25 14:54:44.886
    !MESSAGE Unhandled event loop exception
    !STACK 0
    java.lang.NullPointerException
    at com.adobe.flexbuilder.exportimport.releaseversion.ui.ExportReleaseVersionProjectAndLocati onPage.getDefaultOutputFolderPath(ExportReleaseVersionProjectAndLocationPage.java:312)
    at com.adobe.flexbuilder.exportimport.releaseversion.ui.ExportReleaseVersionProjectAndLocati onPage.createLocationControls(ExportReleaseVersionProjectAndLocationPage.java:297)
    at com.adobe.flexbuilder.exportimport.releaseversion.ui.ExportReleaseVersionProjectAndLocati onPage.createControl(ExportReleaseVersionProjectAndLocationPage.java:501)
    at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:170)
    at com.adobe.flexbuilder.exportimport.releaseversion.ui.ExportReleaseVersionWizard.createPag eControls(ExportReleaseVersionWizard.java:310)
    at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:734)
    at org.eclipse.jface.wizard.WizardDialog.createContents(WizardDialog.java:606)
    at org.eclipse.jface.window.Window.create(Window.java:431)
    at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1089)
    at com.adobe.flexbuilder.exportimport.releaseversion.ExportReleaseVersionAction$1.run(Export ReleaseVersionAction.java:93)
    at com.adobe.flexbuilder.exportimport.releaseversion.ExportReleaseVersionAction.run(ExportRe leaseVersionAction.java:103)
    at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:251)
    at org.eclipse.ui.internal.WWinPluginAction.runWithEvent(WWinPluginAction.java:229)
    at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionI tem.java:584)
    at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
    at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java :411)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1669)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1693)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1678)
    at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1421)
    at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3657)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3240)
    at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
    at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
    at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
    at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
    at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLau ncher.java:110)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.jav a:79)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1408)

    looks like this is same as http://bugs.adobe.com/jira/browse/FB-29046 -- export works if turn Application Server in Properties to None/Other rather than J2EE... that bug report was closed as unreproducible. Looks like its still out there in the wild...

  • Different environments created for Debug and Release libraries

    Environments created in Debug mode cannot be read by software compiled in release mode. The same is true for the reverse.
    Both libraries compiled with VS.NET 2005 (C++). The environment created in Debug mode is slightly different than the library created in the Release mode. I would assume that this is a bug?
    __db.001 - no change
    __db.002 - DIFFERENT
    __db.003 - no change
    __db.004 - no change
    __db.005 - DIFFERENT
    __db.006 - no change
    Aeronautical.dbxml - no change
    log.0000000001 - no change
    The environments are created using the following flags:
    // Flags required when opening the XmlDB Environment
    m_environmentFlags =      DB_CREATE |     // If the environment does not exist, create it.
                             DB_INIT_LOCK |     // Initialize the locking subsystem
                             DB_INIT_LOG |     // Initialize the logging subsystem
                             DB_INIT_MPOOL |     // Initialize the cache
                             DB_INIT_TXN |     // Initialize transactions
                             DB_THREAD;          // Ensure Environment is
                                                 // free-threaded
    The database contains a single XML document.
    An attempt to open() fails with the following error message:
    DbEnv::open: No such file or directory

    Hey Ron,
    Thanks for answering so quickly. Having release and debug builds able to manipulate the same environments is a requirement of convenience. Our project builds both release and debug versions of our software and distributes both versions to the development team daily. The team is encouraged and expected to run both debug and release builds to test their contributions and because the system opens the database (which is distributed with the build) upon startup, one of the two will always fail to load. That leaves us with two obvious solutions/workarounds. The first being to distribute the build with 2 environments and ensure that the build chooses the correct environment based on whether it is debug or release. The second is to rebuild the debug library without the --enable-diagnostic switch.
    We have no immediate need to enable the diagnostic information (that I am aware of...in fact I don't even know what types of checks are put in that would be helpful).
    Do you have an alternative solution that others have used as a work around for this?

  • Mac-App release build error-rectify this Problem

    i generate release build from air file to mac version,i attach valid p12certificate releated to mac version,but i get this error,how do i rectify this problem or how to export air file to mac App Version.

    I'm currently hitting the same problem. I first noticed an issue when I would make a minor change. I'd first test on the AIR simulator to verify that the change works. Then when I export for release, I noticed that the change was not reflected in my iOS build on the device. I deleted the bin-release-temp directory, and then started to receive the error. I've occaissionally been able to get a swf to generate, but it's been sporadic at best and I haven't been able to reproduce the swf generation in reliably. I'm currently running on OSX 10.8.2 with Flash Builder 4.7 Premium (from the creative clould). I've updated to AIR 3.5 from the gaming suite. Any thoughts?
    Thanks very much for any help that can be given.
    Josh

  • Customizing shortcut created by Export Release Build

    Hi,
       I've created an air application that requires a command-line argument - the path to a properties file.  I'd like to set the shortcut created by the Air application installer to point to a default location for this file.  I'm creating the installer by doing Export -> Release Build from the Flex Development Eclipse IDE.  Is there some setting (perhaps in the -app.xml file) that would let me specify a default value?
    Thanks!

    Hi,
    that is not customizable in that way. You're using IDE provided UI for ADT that could be also executed via command line and has limited (closed) list of arguments/options:
    http://help.adobe.com/en_US/air/build/WS789ea67d3e73a8b22388411123785d839c-8000.html
    What about adding that file into application package? If it needs to be passed as path each time application is run you could ship it with application then. Or provide application routine that would compute that path to that file at runtime once application is started.
    thanks,
    regards,
    Peter

  • Issues exist in release build that don't exist in debug build

    I've been working on a Flex 4.1 project and have recently noticed an issue that does not exist in the debug build.  Then when you export a release build and run it the issue appears.  This is the only change that's made that breaks it.  To me this seems to be a bug in the player, SDK, or compiler that I might need to post, but I figured I'd submit it here in case I'm missing something.
    Basically it seems to be an issue with objects in an ArrayCollection being instantiated as the correct class type before being added.
    When in debug mode, if you set a breakpoint to view the objects in the ArrayCollection you will see them appropriately as their Strongly Typed class.  However, when the release mode build is run it will throw an RTE on that same line indicating that the ArrayCollection members are ObjectProxy and they can't be cast into their Strongly Typed class.
    Here's the RTE that happens and right now I just need to know if I'm missing something, or if this looks like a bug, and to which bugbase it should be posted (Flash Player, Flex SDK, Flex Compiler, etc.)
    TypeError: Error #1034: Type Coercion failed: cannot convert mx.utils::ObjectProxy@28250141 to
    <confidential package path>.PlayerPageSummary.
        at <confidential package path>.service::InitializeStorefrontServiceResponseCommand/execute()
        at org.robotlegs.base::CommandMap/execute()
        at org.robotlegs.base::CommandMap/routeEventToCommand()
        at MethodInfo-1674()
        at flash.events::EventDispatcher/dispatchEventFunction()
        at flash.events::EventDispatcher/dispatchEvent()
        at <confidential package path>::<confidential acronym>ModuleActor/dispatchLocal()
        at <confidential package path>.live::InitializeStorefrontService/result()
        at mx.rpc::AsyncToken/http://www.adobe.com/2006/flex/mx/internal::applyResult()
        at mx.rpc.events::ResultEvent/http://www.adobe.com/2006/flex/mx/internal::callTokenResponders()
        at mx.rpc::AbstractOperation/http://www.adobe.com/2006/flex/mx/internal::dispatchRpcEvent()
        at mx.rpc::AbstractInvoker/http://www.adobe.com/2006/flex/mx/internal::resultHandler()
        at mx.rpc::Responder/result()
        at mx.rpc::AsyncRequest/acknowledge()
        at DirectHTTPMessageResponder/completeHandler()
        at flash.events::EventDispatcher/dispatchEventFunction()
        at flash.events::EventDispatcher/dispatchEvent()
        at flash.net::URLLoader/onComplete()

    Alex,
    Thanks for your help and here's an update on this from me.  We did try out your suggestion to see if "PlayerPageSummary can be retrieved via getClassAlias".  I'm not the one that did the testing, but my teammate who did, said that the class being registered was not the issue.
    While he was working on that I further investigated our ANT builder and configuration to see what might have been different between ANT building non-debug SWF and Flash Builder building non-debug SWF.  Turns out that my teammate had added some [ArrayElementType] metadata that I was not aware of.  Once I realized that, I added it as metadata to be kept in my flex-config.xml which ended up solving the debug vs. release mode issues.
    Afterwards, I double-checked the livedocs and also did some Googling.  From the above it appears that debug SWF keep all metadata without you needing to explicitly tell it to. On the other hand, outside of a handful of metadata tag such as [Bindable] release builds neeed to be told what to keep.
    Does this sound right?
    Also, do you know off the top of your head if this is documented by Adobe anywhere and what the link is?  I had a real tough time finding anything mentioning how debug SWF retain all metadata.
    Thanks again for your help!

  • File.openWithDefaultApplication()  to open directory not working from release build

    Hi,
    I'm trying to use the File.openWithDefaultApplication() method to open a directory location.  I'm running on Windows 7 Professional 64-bit, but have also tested on Windows XP Professional 32-bit with the same result.
    The method works fine if I run the app from Flash Builder 4 (either run or debug), but when I try it from a release build it doesn't work.  I've exported the release build as a native installer, and I updated the <supportedProfiles> tag in the app's XML to only support "extendedDesktop".  That hasn't changed the behavior, however.
    Here's an example of how I'm calling the method:
            var thedir:File = File.applicationStorageDirectory;
            thedir = thedir.resolvePath("the_directory");
            if (!thedir.exists)
              thedir.createDirectory();
            thedir.openWithDefaultApplication();
    Any idea what's going on?
    As an aside, if I try to open individual files in the release build, it works fine.  So far only opening a directory is a problem.  And, I verified the directory exists before trying to open it.
    Thanks for any insight you can offer...
    Best,
    Chris

    Hi Chris,
    Instead of using openWithDefaultApplication(), try using native process and calling "explorer" on windows, and "open" on mac, then pass the folder path as an argument.  Something like this windows example:
    private function openWindowsFolder():void
         var explorer:File = new File("C:\\Windows\\explorer.exe");
         if (explorer.exists)
              var nativeProcessStartupInfo:NativeProcessStartupInfo = new NativeProcessStartupInfo();
              nativeProcessStartupInfo.executable = explorer;
              var args:Vector.<String> = new Vector.<String>();
              args.push("C:\\Windows");
              nativeProcessStartupInfo.arguments = args;
              process = new NativeProcess();
              process.start(nativeProcessStartupInfo);
    Hope this helps,
    Chris

Maybe you are looking for

  • My ipad mini does not find my Nokia bh-111 Bluetooth headset, yet all other devices do and pair without issue

    I use my bh-111 with my windows phone, my laptop and my wife's android jellybean phone without issue but the ipad mini will not find it, any ideas?

  • HT3492 mini displayport to vga adapter not working under windows 7

    i've read the article above. How can this firmware affect operation under Windows 7 OS? I have a dual boot system and tested several mini dp-vga adapter, all of them seem to either stop working after a while or doesnt work at all. i have a macbook pr

  • PDF file cannot be viewed from OA Framework page.

    Hi all, I have developed an OA Framework page which shall present an XMLP report in pdf within the browser. When I click on my menu item which opens the oa page, the Open file.. diaglog appears. When I open or save the file (and thereafter opening if

  • Aperture as a Video Manager

    I realize Aperture was designed primarily to archive photos, but how well does it too with videos. I have thousand of video clips. Since I am very familiar with Aperture and just upgraded to Aperture 3, it would be nice if I could use it too manage a

  • Call Labview8 VI from TestExec5.1

    Hello, I need to call some Labview8 VI from TestExec5.1 (Agilent). It works fine with Labview 7.1, but exactly the same code with Labview 8.0 give me back an error with 2 error messages: "The file C:\Program Files\National Instruments\Labview 8.0\Fil