I'd like to contribute it to the Flexlib project, if it is deemed worthy.
This control displays a button, which when clicked, will cause a panel to "unroll" beneath it like a windowshade being pulled down; or if the panel is already displayed it will be "rolled up" like a windowshade being rolled up. When multiple WindowShades are stacked in a VBox, the result will be similar to an mx.containers.Accordian container, except that multiple WindowShades can be opened simultaneously whereas an Accordian acts like a tab navigator, with only one panel visible at a time.
If you unzip the attached file in a clean working directory, everything should build; the library, the example app, the ASDoc, etc. It's all there, along with the proper license notices.
If this becomes part of Flexlib, there are a few more enhancements I'll make to it, but for right now it serves my own purposes as it is.
From: flexlib@googlegroups.com [mailto:flexlib@googlegroups.com] On Behalf Of Dave Glasser Sent: Saturday, December 29, 2007 4:59 PM To: flexlib@googlegroups.com Subject: [flexlib] Offered contribution: WindowShade control
Attached is the source for a component I wrote which I've found to be pretty useful. A sample can be seen here:
I'd like to contribute it to the Flexlib project, if it is deemed worthy.
This control displays a button, which when clicked, will cause a panel to "unroll" beneath it like a windowshade being pulled down; or if the panel is already displayed it will be "rolled up" like a windowshade being rolled up. When multiple WindowShades are stacked in a VBox, the result will be similar to an mx.containers.Accordian container, except that multiple WindowShades can be opened simultaneously whereas an Accordian acts like a tab navigator, with only one panel visible at a time.
If you unzip the attached file in a clean working directory, everything should build; the library, the example app, the ASDoc, etc. It's all there, along with the proper license notices.
If this becomes part of Flexlib, there are a few more enhancements I'll make to it, but for right now it serves my own purposes as it is.</div
I encounter a bug while implementing it using Flex 3 beta 3:
ArgumentError: Undefined state 'up'. at mx.core::UIComponent/getState()[E:\dev\flex_3_beta3\sdk\frameworks\projects \ framework\src\mx\core\UIComponent.as:7055] at mx.core::UIComponent/findCommonBaseState()[E:\dev\flex_3_beta3\sdk\framewor k s\projects\framework\src\mx\core\UIComponent.as:7075] at mx.core::UIComponent/commitCurrentState()[E:\dev\flex_3_beta3\sdk\framework s \projects\framework\src\mx\core\UIComponent.as:6974] at mx.core::UIComponent/setCurrentState()[E:\dev\flex_3_beta3\sdk\frameworks\p r ojects\framework\src\mx\core\UIComponent.as:6938] at mx.core::UIComponent/set currentState()[E:\dev\flex_3_beta3\sdk\frameworks\projects\framework\src\mx \ core\UIComponent.as:4250] at mx.controls::Button/http://www.adobe.com/2006/flex/mx/internal::viewIconForP hase()[E:\dev\flex_3_beta3\sdk\frameworks\projects\framework\src\mx\control s \Button.as:1972] at mx.controls::Button/http://www.adobe.com/2006/flex/mx/internal::viewIcon()[E :\dev\flex_3_beta3\sdk\frameworks\projects\framework\src\mx\controls\Button . as:1871] at mx.controls::Button/commitProperties()[E:\dev\flex_3_beta3\sdk\frameworks\p r ojects\framework\src\mx\controls\Button.as:1356] at mx.core::UIComponent/validateProperties()[E:\dev\flex_3_beta3\sdk\framework s \projects\framework\src\mx\core\UIComponent.as:5660] at mx.managers::LayoutManager/validateProperties()[E:\dev\flex_3_beta3\sdk\fra m eworks\projects\framework\src\mx\managers\LayoutManager.as:517] at mx.managers::LayoutManager/doPhasedInstantiation()[E:\dev\flex_3_beta3\sdk\ f rameworks\projects\framework\src\mx\managers\LayoutManager.as:637] at Function/http://adobe.com/AS3/2006/builtin::apply() at mx.core::UIComponent/callLaterDispatcher2()[E:\dev\flex_3_beta3\sdk\framewo r ks\projects\framework\src\mx\core\UIComponent.as:8450] at mx.core::UIComponent/callLaterDispatcher()[E:\dev\flex_3_beta3\sdk\framewor k s\projects\framework\src\mx\core\UIComponent.as:8393]
From: flexlib@googlegroups.com [mailto:flexlib@googlegroups.com] On Behalf Of Dave Glasser Sent: Saturday, December 29, 2007 4:59 PM To: flexlib@googlegroups.com Subject: [flexlib] Offered contribution: WindowShade control
Attached is the source for a component I wrote which I've found to be pretty useful. A sample can be seen here:
I'd like to contribute it to the Flexlib project, if it is deemed worthy.
This control displays a button, which when clicked, will cause a panel to "unroll" beneath it like a windowshade being pulled down; or if the panel is already displayed it will be "rolled up" like a windowshade being rolled up. When multiple WindowShades are stacked in a VBox, the result will be similar to an mx.containers.Accordian container, except that multiple WindowShades can be opened simultaneously whereas an Accordian acts like a tab navigator, with only one panel visible at a time.
If you unzip the attached file in a clean working directory, everything should build; the library, the example app, the ASDoc, etc. It's all there, along with the proper license notices.
If this becomes part of Flexlib, there are a few more enhancements I'll make to it, but for right now it serves my own purposes as it is.</div
Hi, could I get a response on this from the project owners?
Dave Glasser <dglas...@pobox.com> wrote: Attached is the source for a component I wrote which I've found to be pretty useful. A sample can be seen here:
I'd like to contribute it to the Flexlib project, if it is deemed worthy.
This control displays a button, which when clicked, will cause a panel to "unroll" beneath it like a windowshade being pulled down; or if the panel is already displayed it will be "rolled up" like a windowshade being rolled up. When multiple WindowShades are stacked in a VBox, the result will be similar to an mx.containers.Accordian container, except that multiple WindowShades can be opened simultaneously whereas an Accordian acts like a tab navigator, with only one panel visible at a time.
If you unzip the attached file in a clean working directory, everything should build; the library, the example app, the ASDoc, etc. It's all there, along with the proper license notices.
If this becomes part of Flexlib, there are a few more enhancements I'll make to it, but for right now it serves my own purposes as it is.
I guess all of them are sort of busy. BTW, have you got the msg regarding the error of the WindowShade component in Flex 3?
From: flexlib@googlegroups.com [mailto:flexlib@googlegroups.com] On Behalf Of Dave Glasser Sent: Thursday, January 03, 2008 11:14 AM To: flexlib@googlegroups.com Subject: [flexlib] Re: Offered contribution: WindowShade control
Hi, could I get a response on this from the project owners?
I'd like to contribute it to the Flexlib project, if it is deemed worthy.
This control displays a button, which when clicked, will cause a panel to "unroll" beneath it like a windowshade being pulled down; or if the panel is already displayed it will be "rolled up" like a windowshade being rolled up. When multiple WindowShades are stacked in a VBox, the result will be similar to an mx.containers.Accordian container, except that multiple WindowShades can be opened simultaneously whereas an Accordian acts like a tab navigator, with only one panel visible at a time.
If you unzip the attached file in a clean working directory, everything should build; the library, the example app, the ASDoc, etc. It's all there, along with the proper license notices.
If this becomes part of Flexlib, there are a few more enhancements I'll make to it, but for right now it serves my own purposes as it is.</DIV
I've actually been focusing on FlexLib a bit over the past few weeks, and last night I committed a whole bunch of bugfixes (I'll be posting an announcement about what was fixed soon).
Dave, I took a look at the WindowShade component. Overall it's a nice component. This is basically what Peter Ent called his "Stack" component ( http://weblogs.macromedia.com/pent/archives/2007/04/the_stack_compo.cfm). One question I have is did you think about adding in the other direction to allow the buttons to be vertical instead of horizontal? FlexLib include a vertical version of the accordion, and it would be nice if we had the same ability for this type of component. The main thing though is that this component seems like it should really be a container, like Accordion. Your sample show that you wrap each child in a WindowShade component, as opposed to having a single container that you place children in. I'd prefer to see a component like this as a proper container (which also means it would support differed instantiation of child components). I'm wondering if the "right" way to do this is to extend the Accordion that we have in FlexLib already and add the ability to have multiple items open at once (and also all items closed). That might be more work, but the benefit is that you would have a proper container component, and since the accordion in FlexLib does both horizontal and vertical layout we would get those out of the box.
If anyone on this list wants to chime in, fell free. Am I over-analyzing it and should I just say fuck it and drop in the component as is? I'd like to see a component that is basically an Accordion with multiple open children, I just think the right way to do that is to extend Accordion and make it support that (heh, if anyone wants to do that be my guest).
> I'd like to contribute it to the Flexlib project, if it is deemed worthy.
> This control displays a button, which when clicked, will cause a panel to > "unroll" beneath > it like a windowshade being pulled down; or if the panel is already > displayed it will be "rolled up" like a windowshade being rolled up. When > multiple WindowShades are stacked in a VBox, the result will be similar to > an mx.containers.Accordian container, except that multiple WindowShades > can be opened simultaneously whereas an Accordian acts like a tab navigator, > with only one panel visible at a time.
> If you unzip the attached file in a clean working directory, everything > should build; the library, the example app, the ASDoc, etc. It's all there, > along with the proper license notices.
> If this becomes part of Flexlib, there are a few more enhancements I'll > make to it, but for right now it serves my own purposes as it is.</DIV
Yes I did, and that's why I asked for a response. I want to know if Flexlib is going to be the home for the WindowShade control before I clutter up the Flexlib list with support emails for it. But, since I'm on the subject, does your code work under Flex 2?
Tianzhen Lin <tang...@usa.net> wrote: I guess all of them are sort of busy. BTW, have you got the msg regarding the error of the WindowShade component in Flex 3?
From: flexlib@googlegroups.com [mailto:flexlib@googlegroups.com] On Behalf Of Dave Glasser Sent: Thursday, January 03, 2008 11:14 AM To: flexlib@googlegroups.com Subject: [flexlib] Re: Offered contribution: WindowShade control
Hi, could I get a response on this from the project owners?
I'd like to contribute it to the Flexlib project, if it is deemed worthy.
This control displays a button, which when clicked, will cause a panel to "unroll" beneath it like a windowshade being pulled down; or if the panel is already displayed it will be "rolled up" like a windowshade being rolled up. When multiple WindowShades are stacked in a VBox, the result will be similar to an mx.containers.Accordian container, except that multiple WindowShades can be opened simultaneously whereas an Accordian acts like a tab navigator, with only one panel visible at a time.
If you unzip the attached file in a clean working directory, everything should build; the library, the example app, the ASDoc, etc. It's all there, along with the proper license notices.
If this becomes part of Flexlib, there are a few more enhancements I'll make to it, but for right now it serves my own purposes as it is.</DIV
Well, majority of my code is developed for Flex 3 due to the heavy usage of AdvancedDataGrid component. Nice to see your code, I like it way better than SuperPanel which is based on a heavier Panel base class.
From: flexlib@googlegroups.com [mailto:flexlib@googlegroups.com] On Behalf Of Dave Glasser Sent: Thursday, January 03, 2008 1:11 PM To: flexlib@googlegroups.com Subject: [flexlib] Re: Offered contribution: WindowShade control
Yes I did, and that's why I asked for a response. I want to know if Flexlib is going to be the home for the WindowShade control before I clutter up the Flexlib list with support emails for it. But, since I'm on the subject, does your code work under Flex 2?
I guess all of them are sort of busy. BTW, have you got the msg regarding the error of the WindowShade component in Flex 3?
From: flexlib@googlegroups.com [mailto:flexlib@googlegroups.com] On Behalf Of Dave Glasser Sent: Thursday, January 03, 2008 11:14 AM To: flexlib@googlegroups.com Subject: [flexlib] Re: Offered contribution: WindowShade control
Hi, could I get a response on this from the project owners?
I'd like to contribute it to the Flexlib project, if it is deemed worthy.
This control displays a button, which when clicked, will cause a panel to "unroll" beneath it like a windowshade being pulled down; or if the panel is already displayed it will be "rolled up" like a windowshade being rolled up. When multiple WindowShades are stacked in a VBox, the result will be similar to an mx.containers.Accordian container, except that multiple WindowShades can be opened simultaneously whereas an Accordian acts like a tab navigator, with only one panel visible at a time.
If you unzip the attached file in a clean working directory, everything should build; the library, the example app, the ASDoc, etc. It's all there, along with the proper license notices.
If this becomes part of Flexlib, there are a few more enhancements I'll make to it, but for right now it serves my own purposes as it is.</DIV
<d...@dougmccune.com> wrote: >I'm listening :) but yeah, a bit busy.
>I've actually been focusing on FlexLib a bit over the past few weeks, and >last night I committed a whole bunch of bugfixes (I'll be posting an >announcement about what was fixed soon).
You're correct, and had my searches for such a component turned that up, I probably would have used his instead of writing my own. Too bad for me he didn't use the word "windowshade" on that page!
>One question I have is did you think about adding in the other direction to >allow the buttons to be vertical instead of horizontal? FlexLib include a >vertical version of the accordion, and it would be nice if we had the same >ability for this type of component.
I thought about it, but since I didn't need it for my own purposes, I didn't add that functionality. It wouldn't be hard to do, however.
>The main thing though is that this >component seems like it should really be a container, like Accordion. Your >sample show that you wrap each child in a WindowShade component, as opposed >to having a single container that you place children in. I'd prefer to see a >component like this as a proper container (which also means it would support >differed instantiation of child components).
I can see how one might instinctively think that, but the WindowShade is not a container, in the literal (i.e. a subclass of Container) or philosophical sense (i.e something that's intended to contain and manage multiple child objects). It's just a composite object that decorates a container. With a lot of extra work, (and probably extra bugs) one could make it a container, designed for managing multiple children, replicating the styles and layout capabilities that already exist in the various Container subclasses, but that would diminish the two qualities I like best about it -- it's simple, and it works.
>I'm wondering if the "right" >way to do this is to extend the Accordion that we have in FlexLib already >and add the ability to have multiple items open at once (and also all items >closed). That might be more work, but the benefit is that you would have a >proper container component, and since the accordion in FlexLib does both >horizontal and vertical layout we would get those out of the box.
I doubt if that's the right approach, since the Accordian is based on the same functional model as ViewStack and TabNavigator -- multiple child containers, all the same size, with only one visible at a time. (selectedChild, selectedIndex, etc.) I think it would be like trying to turn an apple into an orange, and there would be many obstacles to struggle against. If I wanted a Container class similar to accordian but with zero or many open children, I would write something that does pretty much what my sample app does, which is stack multiple WindowShades in a VBox. It would use the label property of its child containers for the button labels, like Accordian, TabNavigator, etc., and the addChild function would only accept Containers. But I would still keep the WindowShade control as a full-fledged component in its own right, for code that doesn't need multiple stacked WindowShades, or that might want to stack non-WindowShade items in between them.
>If anyone on this list wants to chime in, fell free. Am I over-analyzing it >and should I just say fuck it and drop in the component as is? I'd like to >see a component that is basically an Accordion with multiple open children, >I just think the right way to do that is to extend Accordion and make it >support that (heh, if anyone wants to do that be my guest).
Well, I think you should just say fuck it and drop it in, but that's entirely up to you. It doesn't really matter to me. I won't be offended or upset if you say no. I wrote the WindowShade because I needed that functionality and couldn't find it anywhere, and I offered it to Flexlib because I thought, and I still think, that others could get some use out of it. But from one OSS developer to another, however, I think you're making a mistake if you reject it simply because it doesn't seem like the "right" way (i.e. it doesn't subclass Accordion) or it's not a "proper container", because it will probably be a long time before someone comes along and develops that, if ever. You'd be letting the "perfect" (arguably) keep out the good. If you make the WindowShade part of Flexlib I'll definitely maintain it, and probably enhance it as time permits. But I'm not going to rewrite it just to get my name on the list of Flexlib contributors. I've polished it up a bit and fixed a bug or two since I emailed that zip file, but for my own needs, it's going to stay pretty much as it is.
>> I'd like to contribute it to the Flexlib project, if it is deemed worthy.
>> This control displays a button, which when clicked, will cause a panel to >> "unroll" beneath >> it like a windowshade being pulled down; or if the panel is already >> displayed it will be "rolled up" like a windowshade being rolled up. When >> multiple WindowShades are stacked in a VBox, the result will be similar to >> an mx.containers.Accordian container, except that multiple WindowShades >> can be opened simultaneously whereas an Accordian acts like a tab navigator, >> with only one panel visible at a time.
>> If you unzip the attached file in a clean working directory, everything >> should build; the library, the example app, the ASDoc, etc. It's all there, >> along with the proper license notices.
>> If this becomes part of Flexlib, there are a few more enhancements I'll >> make to it, but for right now it serves my own purposes as it is.</DIV
WindowShade seem to work better for me because it is not based on fix height. Out of the box, Peter Ent's control is still behaving like an accordion where children's total height remain as a fix number.
David, I would hope you would consider adding a class metadata [DefaultProperty("child")], so it would be convenient to add control under it.
WindowShade is a good nice as it is something used in Mac prior to OS X.
-----Original Message----- From: flexlib@googlegroups.com [mailto:flexlib@googlegroups.com] On Behalf
Of Dave Glasser Sent: Thursday, January 03, 2008 2:28 PM To: flexlib@googlegroups.com Subject: [flexlib] Re: Offered contribution: WindowShade control
On Thu, 03 Jan 2008 10:09:32 -0800, "Doug McCune" <d...@dougmccune.com> wrote:
>I'm listening :) but yeah, a bit busy.
>I've actually been focusing on FlexLib a bit over the past few weeks, and >last night I committed a whole bunch of bugfixes (I'll be posting an >announcement about what was fixed soon).
You're correct, and had my searches for such a component turned that up, I probably would have used his instead of writing my own. Too bad for me he didn't use the word "windowshade" on that page!
>One question I have is did you think about adding in the other direction to >allow the buttons to be vertical instead of horizontal? FlexLib include a >vertical version of the accordion, and it would be nice if we had the same >ability for this type of component.
I thought about it, but since I didn't need it for my own purposes, I didn't add that functionality. It wouldn't be hard to do, however.
>The main thing though is that this >component seems like it should really be a container, like Accordion. Your >sample show that you wrap each child in a WindowShade component, as opposed >to having a single container that you place children in. I'd prefer to see a >component like this as a proper container (which also means it would support >differed instantiation of child components).
I can see how one might instinctively think that, but the WindowShade is not a container, in the literal (i.e. a subclass of Container) or philosophical sense (i.e something that's intended to contain and manage multiple child objects). It's just a composite object that decorates a container. With a lot of extra work, (and probably extra bugs) one could make it a container, designed for managing multiple children, replicating the styles and layout capabilities that already exist in the various Container subclasses, but that would diminish the two qualities I like best about it -- it's simple, and it works.
>I'm wondering if the "right" >way to do this is to extend the Accordion that we have in FlexLib already >and add the ability to have multiple items open at once (and also all items >closed). That might be more work, but the benefit is that you would have a >proper container component, and since the accordion in FlexLib does both >horizontal and vertical layout we would get those out of the box.
I doubt if that's the right approach, since the Accordian is based on the same functional model as ViewStack and TabNavigator -- multiple child containers, all the same size, with only one visible at a time. (selectedChild, selectedIndex, etc.) I think it would be like trying to turn an apple into an orange, and there would be many obstacles to struggle against. If I wanted a Container class similar to accordian but with zero or many open children, I would write something that does pretty much what my sample app does, which is stack multiple WindowShades in a VBox. It would use the label property of its child containers for the button labels, like Accordian, TabNavigator, etc., and the addChild function would only accept Containers. But I would still keep the WindowShade control as a full-fledged component in its own right, for code that doesn't need multiple stacked WindowShades, or that might want to stack non-WindowShade items in between them.
>If anyone on this list wants to chime in, fell free. Am I over-analyzing it >and should I just say fuck it and drop in the component as is? I'd like to >see a component that is basically an Accordion with multiple open children, >I just think the right way to do that is to extend Accordion and make it >support that (heh, if anyone wants to do that be my guest).
Well, I think you should just say fuck it and drop it in, but that's
