 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Joann Chuang - [03/03/08 04:42 PM - edited ]
This is not a regression. We don't respect padding when we use absolute positioning. According to Jason, this is due to no longer using scaleGrid values for our border metrics. This bug occurs because the Panel has a custom skin and the skin has border metrics of 0 all the way around.
The workaround for this code would be to make mx:Canvas the first child of Panel and set the Panel layout to vertical.
<mx:Panel layout="vertical" width="400" height="300" title="Works wrong"> <mx:Canvas> <mx:Box width="50" height="50" backgroundColor="red"/> </mx:Canvas> </mx:Panel> This happens always using "Flex Component Kit for flash", when you change the panel skin and also without changing it, the content overlap the titlebar.
I wondering that if it is not fixed why it is released with the other component(Flex Component Kit for flash" ) ??? It is critical because it breaks all the beauty of being able to skin the application using the flash. The panel, titleWindows and Alerts are the heart of every big application. Hope it will be fixed as soon as possible Thanks This is actually a regression. It worked in Flex 2.0.1 and doesn't in Flex 3
Agreed with taha -- this completely broke all our panels (pop-ups) in our app since we were using a custom Illustrator skin. In fact, if you go through Adobe's tutorials on custom-skinning components via Illustrator, panels are broken.
These had been working fine up through beta3; it was only the release that broke this so it is definitely a regression. Hello,
I have been struggling with this issue as well, ever since I purchased and installed Builder 3 with the Final SDK. It broke all of my custom skins, and doesn't work with any of the skins available at www.scalenine.com (everything was fine in Beta 3) Will this be changed or should we just add a Canvas to every Panel instance in our applications? This is not ideal since the Canvas size/position cannot dynamically change when loading up different custom skins. Thanks, Warren Confirmed in FB 3 release yesterday. I had to back out of using a panel and just used a background image.
Why did this behavior change from Beta 3 to the Final Release?
That is ridiculous!! Why even have a public beta program if you are pulling stunts like this.... Using panels in Flex 3 is a disaster! What ever you have done please change it back!
Throughout all the bug reports your response seems to be "use top padding for a work around" well I am telling you it doesn't fix a thing. When using a custom border skin padding has no effect, well at least on the skin, and because other classes like the title window and alert all extend this class my App looks like crap. Not good enough Just wanted to say: beta3 was definitely better!
This will be fixed/changed on new release? or not?
What solutions are proposed? I´m not an expert but think I found a fix for this.
frameworks\projects\framework\src\mx\containers\Panel.as must to be changed in the viewMetrics() method. Line: 973- if (FlexVersion.compatibilityVersion < FlexVersion.VERSION_3_0) 974- { Replace by: if ((FlexVersion.compatibilityVersion < FlexVersion.VERSION_3_0) || (getQualifiedClassName(border) != "mx.skins.halo::PanelSkin") || (getStyle("borderStyle") != "default") ) { this fix, enable of course, this change need to be patched on the SDK.. So if some developer can check this maybe we can use our old skins with the next flex 3 SDK releases Any progress on this on the Adobe side of things? We are attempting to migrate a fairly large application from flex 2 to flex 3 and have a large number of absolutely positioned flash skinned panels. The only option that seems viable at the moment is to manually adjust all of the controls to be in the correct locations. Unfortunately, that means that when this does get patched later, we'll have to manually reposition everything again. Any recommended workaround for this particular scenario or eta on resolution?
This was enhancement behavior initially added to Flex 3 Beta 3, but something we pulled out due to risk and disruption for the actual Flex 3 release. We're looking to re-evaluate adding this behavior back in for a dot release of Flex 3. For now, your best bet will be to use the various workarounds suggested in the notes above, primarily using absolute layout and positioning child controls with the padding styles.
Deepa,
This has been blogged to death, I know, but, evidently it bears repeating... Skinning and panels worked consistently from 2 to 2.01 to beta 3. The release of 3.0 brings a missing "enhancement" that breaks all of our applications.... I'm sure you can appreciate how it's a little tough for us all to buy the notion that something that has worked consistently for all this time, suddenly is classified as an "enhancement" that was pulled out due to "risk" and possible "disruption" of Flex 3. What risk exactly were you trying to avoid? Because in avoiding this "risk" you've broken virtually every skinned application currently in production worldwide. What disruption were you trying to avoid? What could be more disruptive than virtually every app in existence needing recoding to accommodate the release of Flex 3? I've already done as instructed and revamped our production applications to work around this, but for Adobe to claim that standard behavior in all the releases to date, including the 3rd Beta of R3.0 was simply an "enhancement" that none of us should've relied upon being released, is a little disingenuous. And for you to then claim the "enhancement" (defined as standard behavior up until now) will be released as part of a 3.X release, only makes us all look forward to recoding our applications AGAIN once the "enhancement" is reintroduced. I apologize if I seem overly critical on this issue, but you really need to consider the position Adobe has put guys on the street trying to push Flex when you force us to have to sell to our client an upgrade to Flex 3 requiring 40 hours of development to make what used to work fine look sort of OK for now and then another 40 hours once the 3.x release comes that will reintroduce what you somehow consistently attempt to classify as an enhancement. You can argue with us all you want that you pulled a risky enhancement -- but the truth from the customers perspective is something that worked for months suddenly doesn't when they pay good money to upgrade. Do you mind if I have them contact you for the explanation as to how that isn't a bug? PS -- if you're going to try to sell this as something under than a bug, then this Issue Type should probably be categorized as something other than an open bug. Thanks for the reply Deepa - Would you mind clarifying your suggestion a bit? You suggested "using absolute layout and positioning child controls with the padding styles" but earlier in the post, Joann pointed out that "We don't respect padding when we use absolute positioning." Our testing with padding seemes to indicate that Joann's assessment was correct and that our padding styles were being completely ignored. Could you provide an example that might explain your suggestion a little better? Thanks!
Here is a skin class I quickly wrote up that will use the borderMetrics of the image to determine its own borderMetrics. Optionally, you can also override the borderMetrics by specifying the contentLeft / contentRight / contentTop / contentBottom styles.
Feel free to use the skin class, but understand that it is not production quality and has not been thoroughly tested. I've also attached an example application that shows how to use the class. I've uploaded an example (panelWorkaround.mxml) that show how to wrap the Panel children in a Canvas to place the children in the proper location.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
B
Panel contents overlap when using borderSkin style and layout=absolute
Rejected
