So flexmdi has been out for a while. People are moving already moving towards an even more Active Desktop and so I though I’d throw together a quick multiple desktop document interface. Easy for you to say. This is just a rough example and none of the code has been imported into flexmdi. And there are definitely some problems with it. I’ve taken a couple approaches at this, and really am only showing this to generate ideas / help / support at to what exactly people are looking for.
I’m using a modified version of Ely’s Display Shelf. ( thanks ). Also, I’m taking snap shots of the screens and there is problems rendering the desktops that haven’t been created. I’ve tried displaying the actual scaled instances, ( wasn’t pretty ). I’ve also tried Doug’s FlowContainer which I will probably attempt again in the future because it seems to fit.
Important : When viewing the desktop picker use your arrow keys ( Left and Right ) to navigate. Hit Enter to select the screen.
Here’s a first pass. demo
Here’s another approach by the Replicants. Thought’s and suggestions welcome.
Just to let everyone know, we compiled the flexmdi lib with moxie ( actually I did it, so you can send hate mail my way ) so it’s throwing erros with flex 2.01. This will be fixed shortly and we’re going to compile it with flex 2.01 till 3 is released.
So this is just a proof of concept that I threw together. It’s a rough implementation of the taskbar concept. This functionality is something we’ve talked about implementing although no word on a time frame yet. But if someone can grab the concept and incorporate it into the library be sure to send it our way and we’ll give credit where credit is due. What needs to be done is seamless implementation into the flexmdi library that doesn’t require all the hoops I'll now jump through for you. Not that there are alot of hoops, it’s actually quite simple.
I didn’t touch anything in the flexmdi library to create this btw. In a nutshell the logic goes as follows.
1. when a window is minimized we want to remove it from the screen and add it to the taskbar after any effect has played.
2. when a taskbar item is clicked we want to remove it from the taskbar and add it back to the screen.
To do this I'm simply capturing the window minimize event, setting visible to false, then creating a taskbar item which i then add to an array collection bound to the dataProvider of a horizontal list.
When the task bar item is clicked, I'd simply setting visible to true, then broadcasting the MDIWindow restore event.
We’re going to be working on this more in the future, so any requests and/or help is greatly appreciated. And yes I know the buttons don’t show up on restore, but since our launch of the flexmdi library we’ve got a considerable amount of requests for this to be implemented by default. So I thought I’d throw this out there for now while we work on incorporating it.
you can get the flexmdi framework at http://code.google.com/p/flexmdi/
Happy Ctrl+B
Currently the flexmdi MDIWindow class does not have a way to completely override the default buttons and behaviours in one fell swoop. This should be changing by the release of flexmdi 2 which is scheduled for Adobe MAX 2007 in Chicago.
For most developers adding one or two different buttons is all that will be needed. And this is done quite simply.
You will need to to:
1. create your own Window class that extends MDIWindow
2. override protected function createChildren()
3. create your button and add any listeners you want on it
4. add it to the button contols by calling the addControl(btn,index) of the MDIWindow class.
An example can be found here :
The flexmdi framework provides extensibility to customize the effects on your windows. To implement your own custom effects you will use the following two classes:
flexmdi.effects.IMDIEffectsDescriptor which is the interface used to describe the contract between MDIManager and the effects it applies on windows in relation to events that take place such as minimize(), maximize(), tile() and cascase().
flexmdi.effects.MDIEffectsDescriptorBase is a base class that is defined that you can extend so that you only have to implement the effects for the MDI events you want to without having to implement the entire interface.
As the name implies effects are implemented as descriptor classes, which allows you to describe the effects you wish to take place when a certain event takes place. For example the FlexMDI framework broadcasts a minimize event which takes place when a window is minimized. To implement an effect on minimize you would use the getWindowMinimizeEffect() which can be implemented like:
public function getWindowMinimizeEffect(window:MDIWindow, manager:MDIManager, moveTo:Point = null):Effect
{
var parallel:Parallel = new Parallel(window);
// add effects to parallel here
return parallel;
}
Look to the interface to provide information on what kind of data is getting passed from the manager. Not all scenarios are the same and in fact the effects are broken down into two groups. Window Effects which get passed a window instance and relevant information such as where you need to move the window and Group Effects which get passed an array of GroupEffectItems that hold a window instance and resize and move to data. The difference is that a window effect gets applied to one window like minimize() or close() as where a group effect gets applied to all windows as is the case when you tile() or cascade().
Our goal was to have the manager do the math and the effects to make things look pretty. We've tried to make it as extensible as possible and we have covered a lot of scenarios. Ben Clinkinbeard wrote a good article about how to override default behavior that can be found here which will allow you to do things as stop effects before being played so you can implement custom business logic.
We're just getting started posting examples so if you're unsure about how to implement something be sure to let us know so we can make things more clear and easy for developers to use.
An example of the flex mdi explorer can be found here .
The flexmdi framework can be found at http://flexmdi.googlecode.com/
The flexmdi MDIManager is at the heart of managing the mdi windows. It's responsible for adding, removing, tiling, cascading, whipping, selecting, announcing, berating, belittling, restoring and the all-in-all keeper of the watchtower so to speak. Apart from a little math, it doesn't do much besides route windows through the appropriate processes. But when looking to extend functionality of the flexmdi framework it should be in the back of your mind. Knowing how to use it will open a lot of possibilities up.
Events and Scope
Always look to the manager when you want to manage all windows at once, or set global or instance level handlers. If you wanted all your windows to display a confirmation box upon close you could set this once on the manager. If you wanted to set default positions for your windows when added or apply an effect to certain types of events such as minimize or restore you could set this on the manager. The manager is also responsible for applying group events. A group event takes place at the manager level and applies to all windows such as cascade and tile. The manager is also the place to intercept window events to change default behavior. You can apply a context menu for the container on the manager as well.
Infinite Managers For The Price of One
The managers is the master of context. As a convenience it has a global application manager that can be accessed with MDIManager.global which uses the Application.application as it's container and adds windows via the PopUpManager so graciously provided by the flex framework. But the manager can also be confined to manage windows in any type of container. As an example, if you were to create a viewstack you could have a manager for each parent level container in the view stack which would allow you to hide,show,maximize,restore,tile,cascade, etc.., windows at the viewstack level and allow your users to switch back and forth for some free stylin' window management. To create a local instance of the manager you just need a to have a container for it to manage:
public var manager:MDIManager = new MDIManager(myContainer);
From this point any windows you add to manager will be managed within the confines of myContainer. You can also pass an effectsLib class to the manager as well. (more on that in a later post).
Summary
Personally I think of the manager as the name describes as the man in charge of the action. Managing windows on a more global or container level allows you to only write the code for the special short bus windows when you have to. Less code to write is good. As always look in the docs to find the details.
and example of flexmdi can be seen here .
you can find the flexmdi framework at http://flexmdi.googlecode.com/
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 |
Recent Comments