[jira] [Commented] (FLEX-33350) CallOutButton for Web (desktop / not AIR)

2013-03-25 Thread Maxime Cowez (JIRA)

[ 
https://issues.apache.org/jira/browse/FLEX-33350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13613025#comment-13613025
 ] 

Maxime Cowez commented on FLEX-33350:
-

No companies involved. You have my blessing ;)

 CallOutButton for Web (desktop / not AIR)
 -

 Key: FLEX-33350
 URL: https://issues.apache.org/jira/browse/FLEX-33350
 Project: Apache Flex
  Issue Type: New Feature
  Components: .Unspecified - Framework
Affects Versions: Apache Flex 4.9.0
Reporter: Marcus Fritze
Assignee: Cyrill Zadra
 Fix For: Apache Flex 4.10.0

 Attachments: CallOutButton.fxpl, CallOutButtonTest.fxp, 
 CallOutButtonTest.zip, CallOutButton.zip


 based on the code provided by Maxime Cowez 
 https://github.com/RIAstar/CallOutFx and the original CallOutButton (AIR 
 version), I developed a CallOutButton for Web (desktop).
 Attachments:
 - CallOutButton (library project)
 - CallOutButtonTest (example project)
 Sorry, I am not a contributor and therefore I have no access to whiteboard 
 for uploading an example. Maybe, if someone (a contributor) think this would 
 be a nice component for Apache Flex, you can use it and upload it.
 Feedback is welcome!
 (Warning: there is a lot of commented-out source-code in the Callout.as)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (FLEX-33413) HTML wrapper ANT task fails to write playerProductInstall.swf to disk

2013-02-26 Thread Maxime Cowez (JIRA)
Maxime Cowez created FLEX-33413:
---

 Summary: HTML wrapper ANT task fails to write 
playerProductInstall.swf to disk
 Key: FLEX-33413
 URL: https://issues.apache.org/jira/browse/FLEX-33413
 Project: Apache Flex
  Issue Type: Bug
  Components: Ant Tasks
Affects Versions: Apache Flex 4.9.0
 Environment: windows 7 (32-bit), Java 7 (32-bit)
Reporter: Maxime Cowez
Priority: Minor


When running the html-wrapper ANT task with no specific arguments, the task 
writes the following output:

[ant:html-wrapper] Error outputting resource: playerProductInstall.swf
[ant:html-wrapper] java.io.IOException: Stream closed

The result of the task is that all files have correctly been generated except 
for 'playerProductInstall.swf', which is there, but has no content (0 Kb).

This seems to be a regression bug. I have run the same task on the same project 
against Adobe Flex 4.6, which works as expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (FLEX-33404) Compile error with Apache Flex 4.9 and not Adobe 4.1

2013-02-19 Thread Maxime Cowez (JIRA)

[ 
https://issues.apache.org/jira/browse/FLEX-33404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581169#comment-13581169
 ] 

Maxime Cowez commented on FLEX-33404:
-

When I compile your test case with 4.9 the compiler gives me a clear message of 
what's wrong with the code:
The skin part type 'spark.components:TabBar' must be assignable to '*'.

So you just replace that '*' with 'Object' and it'll compile just fine.
That said, I would tend to be more specific when defning the types of 
SkinParts: if you have absolutely no idea what kind of visual component your 
skinpart will be, the most generic interface is IVisualElement.

 Compile error with Apache Flex 4.9 and not Adobe 4.1
 

 Key: FLEX-33404
 URL: https://issues.apache.org/jira/browse/FLEX-33404
 Project: Apache Flex
  Issue Type: Bug
  Components: Skinning
Affects Versions: Apache Flex 4.9.0
 Environment: WinXP 32bit
Reporter: tom chiverton
 Attachments: src.zip, test skin.fxp


 I'm trying to build a project that is fine with the Adobe 4.1A SDK using the 
 Apache 4.9 SDK, but we have a Skin that says
 fx:Metadata
 [HostComponent(com.ev.global.view.components.Dashboard)]
 /fx:Metadata
 Adding CDATA inside the Metadata doesn't appear to change things. 
 Attached is a reproducible test case - this compiles out of the box with the 
 Adobe 4.1 compiler, but throws an error with the Apache 4.9 release.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Resolved] (FLEX-33311) Nullpointer in ConstraintLayout when executing Transition on content

2013-02-04 Thread Maxime Cowez (JIRA)

 [ 
https://issues.apache.org/jira/browse/FLEX-33311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxime Cowez resolved FLEX-33311.
-

   Resolution: Fixed
Fix Version/s: Apache Flex 4.9.0

Though no-one was assigned to this particular bug, apparently it has somehow 
been fixed in 4.9
I have no idea what the possibly related issue(s) might be.
(I can still reproduce it in 4.8, so this is not due to external conditions 
of my test application or anything.)

 Nullpointer in ConstraintLayout when executing Transition on content
 

 Key: FLEX-33311
 URL: https://issues.apache.org/jira/browse/FLEX-33311
 Project: Apache Flex
  Issue Type: Bug
  Components: Spark: Layout, Transitions
Affects Versions: Apache Flex 4.8 (parity release)
Reporter: Maxime Cowez
Priority: Trivial
 Fix For: Apache Flex 4.9.0

 Attachments: SpecifiableListWrapper.as, 
 SpecifiableListWrapperHorizontalSkin.mxml


 In some very specific cases `ConstraintLayout` will throw a nullpointer error 
 when a component inside it is playing a transition. I tried a few things and 
 found out that:  
  - `parseConstraints()` creates a new `rowBaselines` Vector (or empties it if 
 it exists)
  - some other process calls `clearConstraintCache()` in the middle of the 
 execution of `parseConstraints()`, setting `rowBaselines` back to `null`
  - `parseConstraints()` calls `parseElementConstraints()` which tries to 
 access elements in `rowBaselines` and throws a nullpointer error
 I know very little about how Effects and Transitions work, so the some other 
 process part is a bit of a mistery to me.
 Here is some code to reproduce the error consistently. My apologies for the 
 complexity, but I couldn't get a simpler example to trigger the error.
 s:Group width=100%
 s:layout
 s:ConstraintLayout
 s:constraintColumns
 s:ConstraintColumn id=sequenceCol/
 s:ConstraintColumn id=labelCol/
 s:ConstraintColumn id=contentCol width=100%/
 s:ConstraintColumn id=helpCol maxWidth=200/
 /s:constraintColumns
 s:constraintRows
 s:ConstraintRow id=row1 baseline=maxAscent:10 
 height=100%/
 /s:constraintRows
 /s:ConstraintLayout
 /s:layout
 s:Group left=contentCol:0 right=contentCol:1 baseline=row1:0 
 bottom=row1:10
 t:SpecifiableListWrapper width=100% 
 skinClass=SpecifiableListWrapperHorizontalSkin
 s:DropDownList dataProvider={dp}/
 /t:SpecifiableListWrapper
 /s:Group
 s:Group id=helpContentGroup left=helpCol:27 right=helpCol:10 
 bottom=row1:10 baseline=row1:0/
 /s:Group
 As you may notice, the constraint columns and rows are a copy of those used 
 in FormItemSkin. I left only the content columns necessary to trigger the 
 error (yup, remove the `helpContentGroup` and the error's gone). 
 SpecifiableListWrapper is a custom component which I will attach, along with 
 the specific skin that has the Transition that triggers the error.
 Workaround: subclass ConstraintLayout (or FormItemLayout), override 
 `measure()`, put a try/cacth block around it and use this custom layout.
 public class FormItemLayout extends spark.layouts.FormItemLayout {
 override public function measure():void {
 try {
 super.measure();
 }
 catch (e:Error) { }
 }
 }
 Not exactly pretty but it works without apparent side effects.
 Quick fix (but probably not the ideal solution): just test whether 
 `rowBaselines` exists before trying to access it 
 if (rowBaselines  rowBaselines[bIndex][1]) ...
 instead of 
 if (rowBaselines[bIndex][1]) ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (FLEX-33248) Spark GridItemEditor cannot edit nested properties

2013-01-22 Thread Maxime Cowez (JIRA)

[ 
https://issues.apache.org/jira/browse/FLEX-33248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559791#comment-13559791
 ] 

Maxime Cowez commented on FLEX-33248:
-

[~cframpton] I tried the patched GridItemEditor that came with v4.9.0, but it 
doesn't work for me.

The root of the problem comes from this line at the end of the 'save()' method:
dataGrid.dataProvider.itemUpdated(data, property, oldData, newData);

In my patch the value of  'data' was the main value object and the value of  
'property' was 'someProperty.nestedProperty' (following the example in the 
description of the bug).
In the changes you made to that patch, the value of 'data' became 
'someProperty' and the value of  'property' became 'nestedProperty'.

This causes the following issue:
Assuming the DataGrid's dataprovider is an ArrayCollection, when that call to 
'itemUpdated()' is made, the code execution will eventually pass through 
'ListCollectionView#addItemsToView()'. 
In this method we find the following line: if (filterFunction == null || 
filterFunction(item))
The problem occurs when 'filterFunction' is defined. Because 'item' is now 
'someProperty' and not the main value object, you'll get a Type Coercion error.
The code execution stops there, but I'm pretty sure that even without a 
'filterFunction' there will be other issues further down the road.

I hope I'm making myself sufficiently clear. I'll try to come up with test 
application.

BTW: what is the standard JIRA procedure here? I mean: who is supposed to close 
or reopen the issue? Do I do that, or does a committer decide what's the best 
action?

 Spark GridItemEditor cannot edit nested properties
 --

 Key: FLEX-33248
 URL: https://issues.apache.org/jira/browse/FLEX-33248
 Project: Apache Flex
  Issue Type: Bug
  Components: Spark: DataGrid
Affects Versions: Apache Flex 4.8 (parity release)
Reporter: Maxime Cowez
Assignee: Carol Frampton
Priority: Minor
 Fix For: Apache Flex Next

 Attachments: Company.as, Employee.as, FLEX33248.mxml, 
 GridItemEditor.as


 To reproduce:
 s:DataGrid editable=true
 s:columns
 s:ArrayList
 s:GridColumn dataField=someProperty.nestedProperty /
 /s:ArrayList
 /s:columns
 /s:DataGrid
 This will throw a no such property error when the user tries to edit a 
 cell, because GridItemEditor tries to access `_data[column.dataField]` in the 
 `data` setter.  
 I filed it as a bug and not as an improvement, because it is inconsistent 
 with `GridItemRenderer`'s behaviour, which does render the nested property 
 correctly.
 Note that the `save()` method is also affected: the item's property is 
 accessed in the same way there.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (FLEX-33248) Spark GridItemEditor cannot edit nested properties

2013-01-22 Thread Maxime Cowez (JIRA)

[ 
https://issues.apache.org/jira/browse/FLEX-33248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559820#comment-13559820
 ] 

Maxime Cowez commented on FLEX-33248:
-

I have updated my original test application to include a 'filterFunction' on 
the 'dataProvider'.
See 
https://github.com/RIAstar/ApacheFlexPatchDemo/blob/master/src/main/actionscript/net/riastar/patchfx/GridItemEditorDemo.mxml
And here's the diff: 
https://github.com/RIAstar/ApacheFlexPatchDemo/commit/5e73779aefa98f2af46ab06e3dff6af80d6d9a4a

When you compile this with Flex 4.9.0 and you edit the 'company.name' field, 
you'll get a Type Coercion error telling you that a Company can't be cast to an 
Employee.

 Spark GridItemEditor cannot edit nested properties
 --

 Key: FLEX-33248
 URL: https://issues.apache.org/jira/browse/FLEX-33248
 Project: Apache Flex
  Issue Type: Bug
  Components: Spark: DataGrid
Affects Versions: Apache Flex 4.8 (parity release)
Reporter: Maxime Cowez
Assignee: Carol Frampton
Priority: Minor
 Fix For: Apache Flex Next

 Attachments: Company.as, Employee.as, FLEX33248.mxml, 
 GridItemEditor.as


 To reproduce:
 s:DataGrid editable=true
 s:columns
 s:ArrayList
 s:GridColumn dataField=someProperty.nestedProperty /
 /s:ArrayList
 /s:columns
 /s:DataGrid
 This will throw a no such property error when the user tries to edit a 
 cell, because GridItemEditor tries to access `_data[column.dataField]` in the 
 `data` setter.  
 I filed it as a bug and not as an improvement, because it is inconsistent 
 with `GridItemRenderer`'s behaviour, which does render the nested property 
 correctly.
 Note that the `save()` method is also affected: the item's property is 
 accessed in the same way there.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (FLEX-33352) defaults.css from custom theme is no longer automatically sourced

2013-01-16 Thread Maxime Cowez (JIRA)
Maxime Cowez created FLEX-33352:
---

 Summary: defaults.css from custom theme is no longer automatically 
sourced
 Key: FLEX-33352
 URL: https://issues.apache.org/jira/browse/FLEX-33352
 Project: Apache Flex
  Issue Type: Bug
  Components: Themes
Affects Versions: Apache Flex 4.9.0
Reporter: Maxime Cowez
Priority: Minor


When applying a theme to an application (through the `-theme` compiler option), 
one previously did not have to explicitly source the `defaults.css` file from 
the theme. The style sheet would be applied automatically.

This is no longer the case since v4.9.0; it still works as expected with v4.8.0 
and earlier.

Workaround
explicitly source the css file in the main application:
fx:Style source=defaults.css/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira