[svn:fx-trunk] 5030: Quick fix to GraphicElement

Revision: 5030
Author: [email protected]
Date: 2009-02-20 16:58:01 -0800 (Fri, 20 Feb 2009)
Log Message:
Quick fix to GraphicElement
QE Notes: None
Doc Notes:
Bugs: None
Reviewer: Ryan
tests: None
Modified Paths:
flex/sdk/trunk/frameworks/projects/flex4/src/mx/graphics/baseClasses/GraphicElement.as

Similar Messages

  • [svn:fx-trunk] 11223: * Quick fix for some mxmlcunit failures.

    Revision: 11223
    Author:   [email protected]
    Date:     2009-10-28 07:12:00 -0700 (Wed, 28 Oct 2009)
    Log Message:
    Quick fix for some mxmlcunit failures.
    QE notes:
    Doc notes:
    Bugs: SDK-23865
    Reviewer: Gaurav
    Tests run: checkintests
    Is noteworthy for integration: No
    Code-level description of changes:
    Added null destination check to completeTwoWayBindings().
    Ticket Links:
        http://bugs.adobe.com/jira/browse/SDK-23865
    Modified Paths:
        flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/rep/MxmlDocument.java

  • [svn:fx-trunk] 14462: Quick fix to ensure total byte counts are accurate for -size-report.

    Revision: 14462
    Revision: 14462
    Author:   [email protected]
    Date:     2010-02-26 14:11:20 -0800 (Fri, 26 Feb 2010)
    Log Message:
    Quick fix to ensure total byte counts are accurate for -size-report.
    QE notes: None
    Doc notes: None
    Bugs: SDK-25600
    Reviewer: Paul
    Tests run: Checkin
    Is noteworthy for integration: No
    Ticket Links:
        http://bugs.adobe.com/jira/browse/SDK-25600
    Modified Paths:
        flex/sdk/trunk/modules/swfutils/src/java/flash/swf/tools/SizeReport.java

    If this is textual input (as in a CSV file), you wouldn't use a DataInputStream or DataOutputStream. Use FileReader and FileWriter objects instead.
    Actually, unless this is a homework assignment that tells you to write it yourself, you should just use a library that can parse and format CSV files and just use that.
    My battle plan is to count the number of rows and commas. I would then use these counts in my subsequent loops. Why? What is the purpose of those counts?
    Personally, I'd suggest that you start by writing a method that does the changes you need on a single line of input. (The changes you describe sound like they can all happen on a per-line basis.) Write lots of unit tests to try out various inputs and that you get the correct outputs, given the changes you say you need on a given line.
    When you're done with that and have it working perfectly, then you can write the code to read a file, loop through it, call the method that fixes a single line, and then output that line.

  • [svn:fx-trunk] 7605: VideoPlayer fixes:

    Revision: 7605
    Author:   [email protected]
    Date:     2009-06-07 12:40:59 -0700 (Sun, 07 Jun 2009)
    Log Message:
    VideoPlayer fixes:
    -Going in to fullScreen mode, push the videoplayer on to the application directly as a child.  Otherwise there?\226?\128?\153s no way to guarentee the right coordinates to use when setting the fullScreenRect as I noticed they may change later on.
    - Fix up fullScreen mode to deal with not having access to topLevelRoot()
    - Hide the popup when the ?\226?\128?\1563 second no user-interaction?\226?\128?\157 occurs in fullscreen mode.
    - Remove playheadTime setter from VideoElement...it wasn?\226?\128?\153t supposed to be on there.  They should use seek() instead.  VideoPlayer is correct here.
    - When switching skins, we keep track of the video element?\226?\128?\153s state (where it was in the playback and whether it was playing)
    - In VideoElement, sometimes the underlying object would send out a STOP state change handler after calling play() due to its asynchronous nature.  We call setPlaying() when someone calls play() or pause() or stop() so that the controls update to what the user is trying to do, but when a stop occurs because of end of video, we still need to setPlaying(false).  Also, in this case, when we get a Play stateChange, we should call setPlaying(true).
    - Make sure we call videoPlayer.stop() when swapping video element?\226?\128?\153s or when swapping the underlyign video player object
    QE Notes: -
    Doc Notes: -
    Bugs:SDK-21508, SDK-21616, SDK-21255
    Reviewer: Alex
    tests: checkintest
    Ticket Links:
        http://bugs.adobe.com/jira/browse/SDK-21508
        http://bugs.adobe.com/jira/browse/SDK-21616
        http://bugs.adobe.com/jira/browse/SDK-21255
    Modified Paths:
        flex/sdk/trunk/frameworks/projects/flex4/src/spark/components/VideoPlayer.as
        flex/sdk/trunk/frameworks/projects/flex4/src/spark/primitives/VideoElement.as

  • [svn:bz-trunk] 18926: bug fix BLZ-570 Double linked list with lot of objects result in BlazeDS Error deserializing error  : StackOverflowError

    Revision: 18926
    Revision: 18926
    Author:   [email protected]
    Date:     2010-12-01 14:07:19 -0800 (Wed, 01 Dec 2010)
    Log Message:
    bug fix BLZ-570 Double linked list with lot of objects result in BlazeDS Error deserializing error : StackOverflowError
    We put hard limit to the max object nest level to prevent StackOverFlowError. the default max object nest level is 1024 and it can be configured in the endpoint/serialziation section in service-config.xml.
    This needs documentation.
    Checkintests pass
    Ticket Links:
        http://bugs.adobe.com/jira/browse/BLZ-570
    Modified Paths:
        blazeds/trunk/modules/common/src/flex/messaging/errors.properties
        blazeds/trunk/modules/core/src/flex/messaging/endpoints/AbstractEndpoint.java
        blazeds/trunk/modules/core/src/flex/messaging/io/SerializationContext.java
        blazeds/trunk/modules/core/src/flex/messaging/io/amf/Amf0Input.java
        blazeds/trunk/modules/core/src/flex/messaging/io/amf/Amf3Input.java
        blazeds/trunk/modules/core/src/flex/messaging/io/amf/AmfIO.java

  • [svn:bz-trunk] 21394: bug fix for watson 2887837 Not getting duplicate session detected error when same flex client id is used from two different HTTP sessions in CRX .

    Revision: 21394
    Revision: 21394
    Author:   [email protected]
    Date:     2011-06-16 12:34:13 -0700 (Thu, 16 Jun 2011)
    Log Message:
    bug fix for watson 2887837 Not getting duplicate session detected error when same flex client id is used from two different HTTP sessions in CRX.
    get the sessions id before we invalidate the duplicate session.
    Checkintests pass
    Modified Paths:
        blazeds/trunk/modules/core/src/flex/messaging/endpoints/BaseHTTPEndpoint.java

    For our profect I think this issue was caused as follows:
    Believing that remoting was full asynchronous we fired a 2 or 3 remote calls to the server at the same time ( within the same function ) - usually when the users goes to a new section of the app.
    This seemed to trigger the duplicate http session error since according to http://blogs.adobe.com/lin/2011/05/duplication-session-error.html  two remote calls arriving before a session is created will cause 2 sessions to be created.
    Our current solution ( too early to say it works ) is to daisy chain the multiple calls together .
    Also there seemed to be an issue where mobile apps that never quit ( thanks Apple! )  caused the error when activated after a few hours.
    I guess the session expires on the server and the error above occurs on activation.
    So the mobile apps now ping the server with a remote call when activated after sleeping for more than one hour.
    All duplicate http errors are silently caught and reported.
    Fingers crossed we won't get any more!

  • [svn:bz-trunk] 10631: Proper fix for BLZ-343 and LCDS-1153.

    Revision: 10631
    Author:   [email protected]
    Date:     2009-09-28 05:23:42 -0700 (Mon, 28 Sep 2009)
    Log Message:
    Proper fix for BLZ-343 and LCDS-1153.
    Refactored the common logic for AMF0 and AMF3 back into AbstractAmfInput. Resolving class aliases, creating and registering a property proxy and instantiating the appropriate class are now handled in the superclass. The resolved className and the proxy are 'returned' to the subclasses via a holder array created in the subclasses and sent as a parameter.
    blazeDS checkintests pass
    lcds-trunk checkintests pass with the new flex-messaging-core.jar
    lcds-trunk alltests-dataservice pass with the new flex-messaging-core.jar
    Ticket Links:
        http://bugs.adobe.com/jira/browse/BLZ-343
        http://bugs.adobe.com/jira/browse/LCDS-1153
    Modified Paths:
        blazeds/trunk/modules/core/src/flex/messaging/io/amf/AbstractAmfInput.java
        blazeds/trunk/modules/core/src/flex/messaging/io/amf/Amf0Input.java
        blazeds/trunk/modules/core/src/flex/messaging/io/amf/Amf3Input.java

  • [svn:bz-trunk] 19323: Revert fix for BLZ-578 (checkin 19214).

    Revision: 19323
    Revision: 19323
    Author:   [email protected]
    Date:     2010-12-13 12:10:28 -0800 (Mon, 13 Dec 2010)
    Log Message:
    Revert fix for BLZ-578 (checkin 19214). The BlazeDS/LCDS Spring integration code had a dependency on the thread local stuff that was removed as part of this bug fix. Revert the fix so we can move forward with lockdown testing. We can add this change back in when we resolve the dependency issue (tracked by Watson 2774331) if that's the appropriate thing to do. 
    Ticket Links:
        http://bugs.adobe.com/jira/browse/BLZ-578
    Modified Paths:
        blazeds/trunk/modules/core/src/flex/messaging/FlexContext.java
        blazeds/trunk/modules/core/src/flex/messaging/MessageBroker.java
        blazeds/trunk/modules/core/src/flex/messaging/MessageBrokerServlet.java
        blazeds/trunk/modules/core/src/flex/messaging/MessageException.java

  • [svn:bz-trunk] 21494: bug fix BLZ-581 Possible deadlock situation when sending message

    Revision: 21494
    Revision: 21494
    Author:   [email protected]
    Date:     2011-06-29 11:25:54 -0700 (Wed, 29 Jun 2011)
    Log Message:
    bug fix BLZ-581 Possible deadlock situation when sending message
    change the scope of lock EndpointPushNotifier.pushNeeded to be minimal (retrieving the messages from the message buffer), that way, we can avoid the connection write failure to occupy the lock forever.
    Checkintests pass
    Ticket Links:
        http://bugs.adobe.com/jira/browse/BLZ-581
    Modified Paths:
        blazeds/trunk/modules/core/src/flex/messaging/endpoints/BaseStreamingHTTPEndpoint.java

    Adobe has donated BlazeDS to the Apache Flex community, and the source code is hosted on the Apache Flex website in a GIT repository.
    http://flex.apache.org/dev-sourcecode.html

  • [svn:bz-trunk] 21209: bug fix BLZ-581 Possible deadlock situation when sending message

    Revision: 21209
    Revision: 21209
    Author:   [email protected]
    Date:     2011-05-04 18:26:18 -0700 (Wed, 04 May 2011)
    Log Message:
    bug fix BLZ-581 Possible deadlock situation when sending message
    change the scope of lock EndpointPushNotifier.pushNeeded to be minimal (retrieving the messages from the message buffer), that way, we can avoid the connection write failure to occupy the lock forever.
    Checkintests pass
    Ticket Links:
        http://bugs.adobe.com/jira/browse/BLZ-581
    Modified Paths:
        blazeds/trunk/modules/core/src/flex/messaging/endpoints/BaseStreamingHTTPEndpoint.java

    Adobe has donated BlazeDS to the Apache Flex community, and the source code is hosted on the Apache Flex website in a GIT repository.
    http://flex.apache.org/dev-sourcecode.html

  • [svn:bz-trunk] 18839: bug fix BLZ-575 Potential race condition in flex. management.runtime.messaging.endpoints.EndpointControl

    Revision: 18839
    Revision: 18839
    Author:   [email protected]
    Date:     2010-11-29 12:26:32 -0800 (Mon, 29 Nov 2010)
    Log Message:
    bug fix BLZ-575 Potential race condition in flex.management.runtime.messaging.endpoints.EndpointControl
    Change a few counters to Atomic numbers
    Probably solve some PMD bugs too (was complaining about new Integer() and new Long() API)
    Ticket Links:
        http://bugs.adobe.com/jira/browse/BLZ-575
    Modified Paths:
        blazeds/trunk/modules/core/src/flex/management/runtime/messaging/endpoints/EndpointContro l.java

  • [svn:fx-trunk] 10214: This fixes the problem that if two text components share the same textFlow there is an infinite loop involving updateDisplayList - damageHandler - invalidateDisplaylist - back to updateDisplayList.

    Revision: 10214
    Author:   [email protected]
    Date:     2009-09-13 07:33:58 -0700 (Sun, 13 Sep 2009)
    Log Message:
    This fixes the problem that if two text components share the same textFlow there is an infinite loop involving updateDisplayList -> damageHandler -> invalidateDisplaylist -> back to updateDisplayList.  The bug file was for TextArea which is RET but the same bug was in RichText as well.
    This example with a renderer exposed it because the typicalItem that is composed to figure out sizes and the actual first item in the list share the same textFlow.  It actually has nothing to do with useVirtualDisplay other than it was sharing a textFlow.
    It turns out that the TextFlowFactory dispatches damage events every time the textFlow is composed.  Unlike when the flowComposer is used, it always considers the flow damaged.  It was exacerbated by each of the two components having a damage handler for the same textFlow.
    The solution is to use the textFlow generation number.  In the damageHandler if the generation is the last known generation number, assume no changes, and return immediately from the damage handler.
    QE notes: There are 1 TextArea, 6 TextInput and 2 NumericStepper failuers, with or without my changes.  The common link seems to be DispatchKeyEvent.  Most were testing maxChar, displayAsPassword and restrict.  I tested these and they seem to be working correctly.
    Doc notes:
    Bugs: SDK-23002
    Reviewer: Gordon
    Tests run: checkintests, TextArea, TextInput and NumericStepper
    Is noteworthy for integration: no
    Ticket Links:
        http://bugs.adobe.com/jira/browse/SDK-23002
    Modified Paths:
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/RichEditableText.as
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/RichText.as
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/supportClasses/RichEditable TextContainerManager.as

    Revision: 10214
    Author:   [email protected]
    Date:     2009-09-13 07:33:58 -0700 (Sun, 13 Sep 2009)
    Log Message:
    This fixes the problem that if two text components share the same textFlow there is an infinite loop involving updateDisplayList -> damageHandler -> invalidateDisplaylist -> back to updateDisplayList.  The bug file was for TextArea which is RET but the same bug was in RichText as well.
    This example with a renderer exposed it because the typicalItem that is composed to figure out sizes and the actual first item in the list share the same textFlow.  It actually has nothing to do with useVirtualDisplay other than it was sharing a textFlow.
    It turns out that the TextFlowFactory dispatches damage events every time the textFlow is composed.  Unlike when the flowComposer is used, it always considers the flow damaged.  It was exacerbated by each of the two components having a damage handler for the same textFlow.
    The solution is to use the textFlow generation number.  In the damageHandler if the generation is the last known generation number, assume no changes, and return immediately from the damage handler.
    QE notes: There are 1 TextArea, 6 TextInput and 2 NumericStepper failuers, with or without my changes.  The common link seems to be DispatchKeyEvent.  Most were testing maxChar, displayAsPassword and restrict.  I tested these and they seem to be working correctly.
    Doc notes:
    Bugs: SDK-23002
    Reviewer: Gordon
    Tests run: checkintests, TextArea, TextInput and NumericStepper
    Is noteworthy for integration: no
    Ticket Links:
        http://bugs.adobe.com/jira/browse/SDK-23002
    Modified Paths:
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/RichEditableText.as
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/RichText.as
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/supportClasses/RichEditable TextContainerManager.as

  • [svn:bz-trunk] 19400: bug fix for watson 2774405 Authentication sync sample didn' t work in weblogic

    Revision: 19400
    Revision: 19400
    Author:   [email protected]
    Date:     2010-12-15 12:28:20 -0800 (Wed, 15 Dec 2010)
    Log Message:
    bug fix for watson 2774405 Authentication sync sample didn't work in weblogic
    We should check whether we can cast the user principal to our impl first, also weblogic.security.Security.getCurrentSubject() is used in case it is not our impl
    Modified Paths:
        blazeds/trunk/modules/opt/src/weblogic/flex/messaging/security/WeblogicLoginCommand.java

  • [svn:fx-trunk] 11642: Simple fix for non-integer translations by first multiplying to twips before casting to int .

    Revision: 11642
    Author:   [email protected]
    Date:     2009-11-10 19:40:31 -0800 (Tue, 10 Nov 2009)
    Log Message:
    Simple fix for non-integer translations by first multiplying to twips before casting to int.
    QE notes: Please test non-integer translations in FXG.
    Doc notes: N/A
    Bugs:
    SDK-24110 - Drawing of compiled FXG items is off by half a pixel
    Reviewer: Peter DeHaan
    Tests run: Checkintests, Bug test case
    Is noteworthy for integration: No
    Ticket Links:
        http://bugs.adobe.com/jira/browse/SDK-24110
    Modified Paths:
        flex/sdk/trunk/modules/fxgutils/src/java/com/adobe/internal/fxg/types/FXGMatrix.java

    i dont know why you are so mean i just asked which
    wrongs i had wrong
    anyway im done with thoseSo, the questions have 4 alternative answers. We tell you which questions you got wrong. This eleminates one of
    the alternatives, leaving 3 choices. Usually in most mutlichoice questions 1 choice is obviously incorrect,
    leaving 2 choices. One of those you have probably already discarded when you initially made your incorrect chocie
    thus leaving 1 alternative. Congratulations you just 100% on your test. I don't think so. Go read your book or notes or
    whatever you have because all the answers will be in there. The teacher will not ask you a question on a subject
    you have no prior knowledge of.

  • [svn:fx-trunk] 9947: Syntax fix for Border' s backgroundImageResizeMode Style metadata enumeration.

    Revision: 9947
    Author:   [email protected]
    Date:     2009-09-02 18:05:01 -0700 (Wed, 02 Sep 2009)
    Log Message:
    Syntax fix for Border's backgroundImageResizeMode Style metadata enumeration.
    Modified Paths:
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/Border.as

    You have used elements like header, footer, footer1 and nav without using the correct DOCTYPE declaration. Replace the first line of your code with
    <!doctype html>
    Also have a look here for other problems http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fhome.surewest.net%2Fstorytales%2F test%2Fforposting.html
    After the above has been fixed, please come back here to fix the remaining problem(s)
    Gramps

Maybe you are looking for