Hey Ken yes, i expect that way would work, although using "width" and "height" properties to set the fallback dimensions would cause trouble for the getter / setter option in the view object, because they already exist. plus i'm not keen to have properties set in the view that override properties set (or not) in the clipping object, because that would no doubt lead to confusion for newcomers - as which are you supposed to use?
maybe the solution is to simply have a catch-all default for clipping, that is returned if nothing else exists (no stage, no clipping properties set manually). this could be 800x600 or some such common dimension. If you wanted to adjust this, you could still modify the clipping max/min properties without adding the view to the stage. how does that sound? Rob On Sat, Oct 31, 2009 at 9:56 PM, Ken Railey <[email protected]> wrote: > So I don't really feel all that strongly that the current behavior is > incorrect, and it is fairly easy to workaround by adding to the stage > invisibly as suggested. > > That being said, it was a bit inconvenient in my current project so I worked > around it by just passing in an optional width and height as constructor > parameters to the View, and falling back to the stage dimensions if they are > not provided. > > I also had to muck around in the clipping class so that the screen method > would fall back to the passed in dimension parameters if the stage was > unavailable, but overall it was pretty straightforward. It doesn't seem > like this breaks backwards compatibility in any obvious way, so that is one > potential solution. > > -Ken > > > On Sat, Oct 31, 2009 at 2:48 PM, Rob Bateman <[email protected]> wrote: >> >> Hey Makc >> >> I'm asking for suggestions on how we could modify the framework to >> allow this functionality in future, rather than dismissing it. If you >> have something you wish to suggest, please speak up! >> >> Rob >> >> >> >> On Sat, Oct 31, 2009 at 10:18 AM, Makc <[email protected]> wrote: >> > ths reminds me an old argument between Rob and someone from >> > papervision regarding untyped objects use. essentially same arguments >> > on both sides: "not a good way to go" - "it works, and we like the way >> > it works" >> > >> >> >> >> -- >> Rob Bateman >> Flash Development & Consultancy >> >> [email protected] >> www.infiniteturtles.co.uk >> www.away3d.com > > -- Rob Bateman Flash Development & Consultancy [email protected] www.infiniteturtles.co.uk www.away3d.com
