Thanks alot for all the inputs. I will start working on this from tomorrow and will let you know the results. Thanks and Regards, Pavan
On Wed, Mar 23, 2011 at 12:26 AM, Chris Bartlett <[email protected]>wrote: > On 22 March 2011 19:55, Greg Brown <[email protected]> wrote: > >> 2. How can i create a generic container kind of environment that can hold >>> all the Frames that i can add at runtime and manage the window >>> events,especially considering that in general the containers in Pivot is not >>> designed to add Windows. >>> >> You would still just open Frames as normal, but would specify that your >> 'main display' Window is the parent, rather than the Display. >> >> >> Note that the "main display" should be the frame's *owner*, not parent. >> The Display is always a window's parent. However, it's owner always remains >> below it in the z-order. >> >> Oops. That is what I meant, good catch. > > >> Now that I think about it, one challenge with this solution is that >> maximized windows should not overlap the task bar. The easiest way to do >> this would be to provide a custom display skin that is aware of the presence >> of the task bar window. It is not currently possible to replace the display >> skin, though at the moment I can't remember the reason for that - it seems >> like it should be possible. >> > I quickly prototyped a custom Frame skin that handled the maximized > resizing because Display was final, and wondered if Display does really need > to be final. > > Applying a general caveat to Pivot classes whereby if a user extends them, > they are responsible for the changes seems fair to me. Users might be free > to extend Display but would be reminded that the class has not necessarily > been designed *for* extension, and therefore there are no guarantees. > > Chris >
