[svn:fx-trunk] 11286: Small fix to List multiple selection commit.

Revision: 11286
Author:   [email protected]
Date:     2009-10-29 16:59:07 -0700 (Thu, 29 Oct 2009)
Log Message:
Small fix to List multiple selection commit.
Problem: Dispatching programatically mouse_down event to the item renderer would not put it in the selection.
Reason: commitSelection() was getting called twice, once through ListBase.commitProperties() and a second time through List:commitProperties()
Fix: Clear the multipleSelectionChanged flag inside commitSelection() to prevent it from being called twice.
QE notes: None.
Doc notes: None
Bugs: None
Reviewer: Glenn
Tests run: checkintests, mustella (List)
Is noteworthy for integration: No
Modified Paths:
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/List.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

Similar Messages

  • [svn:fx-trunk] 5212: Small fixes in Toolkit.getSwcDependencyOrder().

    Revision: 5212
    Author: [email protected]
    Date: 2009-03-09 13:09:05 -0700 (Mon, 09 Mar 2009)
    Log Message:
    Small fixes in Toolkit.getSwcDependencyOrder().
    1. Handle null ?\226?\128?\152File[]?\226?\128?\153 argument passed to getSwcDependencyOrder.
    2. Modify toVirtualFiles() to strip out any nulls in the File[] array .
    QE Notes: None
    Doc Notes: None
    Bugs: SDK-19703
    Reviewer: Peter
    tests: checkintests
    Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-19703
    Modified Paths:
    flex/sdk/trunk/modules/compiler/src/java/flex2/tools/oem/Toolkit.java

    This bug figures out also when creating a custom spark ComboBox, then trying to programatically update the userProposedSelectedIndex property. The proposed selected index is selected, but does not apply the same skin as when mouse is on rollover or item is selected due to up and down keys.
    The issue seems like updating the status of the item renderer to rollover or selected to get the same skin applied.
    Please could you attach DropDow nList.as that you edited ?
    Thank you so much.

  • List Multiple Selection to MySQL

    How do I take multiple selections from the List box in a form
    in Dreamweaver 8 and post to MySQL?
    I tried using implode as recommended here:
    http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=12&catid=263&threadid =1112556&highlight_key=y&keyword1=multiple
    This worked unless the user did not select any items in the
    list. Then I received a bad arguement error message.
    I then tried just using POST without the implode and [] on
    the end of the select name, but this put the word "Array" in the
    column/row in the database instead of the data.
    I then tried the POST with the [] on the select name and []
    in the SQL statement: GetSQLValueString($_POST['appliances[]'],
    "text"), Dreamweaver would not let me associate this under Insert
    Record in the Server Behaviors section - so Null is put in the
    database.
    I need to be able to post multiple items selected from a list
    box to MySQL, but allow the user not to select anything from the
    list box without receiving an error.

    dulcey1 wrote:
    > How do I take multiple selections from the List box in a
    form in Dreamweaver 8
    > and post to MySQL?
    Multiple select lists produce an array if anything is chosen,
    but do not
    appear in the $_POST array if nothing is chosen. Since the
    name of your
    multiple select list is appliances, you must put square
    brackets after
    the name in the form (name="appliances[]").
    To prevent errors, check whether $_POST['appliances'] exists.
    If it
    does, extract the values with implode(). If it doesn't,
    create an value
    to indicate that nothing was selected.
    $appliances = (isset($_POST['appliances'])) ? implode(',',
    $_POST['appliances']) : 'None';
    David Powers, Adobe Community Expert
    Author, "Foundation PHP for Dreamweaver 8" (friends of ED)
    Author, "PHP Solutions" (friends of ED)
    http://foundationphp.com/

  • Data list multiple selection not working?

    I set up a data list and checked the 'allow multiple selection' option in the component properties. However, the list still only allowed one selection at a time (clicking on a different item would deselect the other one). Am I missing something or is this just a bug? I'm using Beta 2. In general, I'm really enjoying playing with it and I'm looking forward to the full version.
    Thanks!
    Alicia

    Oh, of course. Thanks. I guess I'm really trying to use the data list in a non-traditional way. I want a series of items that can individually (and independently) be toggled on and off. I actually tried to do this by making a data list with a toggle button as the repeating item. It generally worked, but I got some weird behavior with items outside the clipping area.

  • [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:fx-trunk] 5040: Small SWC dependency fixes.

    Revision: 5040
    Author: [email protected]
    Date: 2009-02-23 08:56:10 -0800 (Mon, 23 Feb 2009)
    Log Message:
    Small SWC dependency fixes.
    QE Notes: None
    Doc Notes: None
    Bugs: None
    Reviewer: Peter
    tests: checkintests
    Modified Paths:
    flex/sdk/trunk/modules/compiler/src/java/flex2/configuration_en.properties
    flex/sdk/trunk/modules/compiler/src/java/flex2/tools/SwcDependencies.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:fx-trunk] 10925: Redo the implementation of dragging & selection being handled upon mouseDown in List .

    Revision: 10925
    Author:   [email protected]
    Date:     2009-10-07 18:52:06 -0700 (Wed, 07 Oct 2009)
    Log Message:
    Redo the implementation of dragging & selection being handled upon mouseDown in List. Evtim will fix up the behavior such that in a multi-select action, mousing down in a selected item will drag the selected set while mousing down in a non-selected item will select that item anew.
    QA: Yes, but don't include in those 3 tests till Evtim checks in, hopefully tomorrow
    Doc: No
    Checkintests: Pass
    Other tests: List tests pass, List D&D tests pass with 3 exclusions.
    Noteworthy for Integration: No
    Modified Paths:
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/DropDownList.as
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/List.as

  • [svn:fx-trunk] 16375: SparkDownloadProgressBar fixes.

    Revision: 16375
    Revision: 16375
    Author:   [email protected]
    Date:     2010-06-01 07:55:16 -0700 (Tue, 01 Jun 2010)
    Log Message:
    SparkDownloadProgressBar fixes.
    SparkDownloadProgressBar:
    Reset _startTime in initProgressHandler() so the elapsedTime check  in showDisplayForInit() is relative to when init started, not the start of the download. This keeps the download progress bar from popping up just before the application loads.
    DownloadProgressBar:
    If an rsl size is zero then provide an average rsl size so we initially have a rough estimate of how much we have to download. Until an rsl actually starts to load its size will be zero. So initially the total download size is just the application size. Then as the rsls start to load the total download size continues to increase but the progress bar is already at 100%. Providing an rsl estimate gives the progress bar something to move forward to. For small applications the progress bar didn?\226?\128?\153t used to show up even when the 700 ms threshold had elapsed.
    QE notes: None.
    Doc notes: None.
    Bugs:
    Reviewer: Glenn
    Tests run: checkintests, Mustella DownloadProgressBar
    Is noteworthy for integration: No
    Modified Paths:
        flex/sdk/trunk/frameworks/projects/framework/src/mx/preloaders/Preloader.as
        flex/sdk/trunk/frameworks/projects/framework/src/mx/preloaders/SparkDownloadProgressBar.a s

  • [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:fx-trunk] 7916: Last of the List PARB changes - selectedItems is now a Vector of Objects and selectedIndices is a Vector of Numbers .

    Revision: 7916
    Author:   [email protected]
    Date:     2009-06-17 09:04:51 -0700 (Wed, 17 Jun 2009)
    Log Message:
    Last of the List PARB changes - selectedItems is now a Vector of Objects and selectedIndices is a Vector of Numbers.
    Also, put alphabetized spark-manifest correctly after my last checkin.
    QA: Yes
    Doc: Yes
    Checkintests: Pass
    Modified Paths:
        flex/sdk/trunk/frameworks/projects/flex4/src/spark/components/List.as
        flex/sdk/trunk/frameworks/spark-manifest.xml

    Gordon, it looks like its been a while since you made this post.  Not sure how valid it is now...   I am particularly interested in the LigatureLevel.NONE value.  It seems that it is no longer supported.
    How do I turn of ligatures in the font rendering?
    My flex project involves trying to match the font rendering of Apache's Batik rendering of SVG and ligatures have been turned off in that codebase.  Is there any way (even roundabout) to turn ligatures off in flash?
    Thanks,
    Om

  • [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

Maybe you are looking for