Here is my vote - Keep the current functionality as it works and best effort to support percentages is very convenient.
The only case that seems to be missing - and it was not obvious till I read your post - when you have scrollPolicy=off on the application container and you expect inner containers understand that - thus limiting themselves to the visible area. It might make sense to have it as a special case of framework level as most of dynamic screens will be created without knowledge of application screen scrolling policy and have to be delegated sizing information. Thank you, Anatole ----- Original Message ----- From: Alex Harui To: [email protected] Sent: Tuesday, October 10, 2006 7:52 PM Subject: RE: [flexcomponents] topLevelSystemManager.getObjectsUnderPoint() :: Scroll Bog Many more hours were spent debating whether this was the right approach. And this thread has renewed the debate. The issue was a big problem before Flex Builder. You'd be hand-coding your tree of MXML containers and tweaking percentage sizes and content. You might make a button label a bit longer and it would cause its container to get scrollbars which would push on the next container and it would sprout scrollbars and suddenly, all you could see were scrollbars. Or, you'd be running the app and resize it a bit and the same thing would happen, scrollbars everywhere. It is probably still a problem if you use nested MXML containers, but less so if you use absolute positioning in FB. So, we opted to make the minHeight/Width of containers with % height/width be the measured height/width of the content which eliminated scrollbar proliferation and caused this annoyance as a side effect. Informal poll: should we change this behavior in a future release? -Alex From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Anatole Tartakovsky Sent: Tuesday, October 10, 2006 4:35 PM To: [email protected] Subject: Re: [flexcomponents] topLevelSystemManager.getObjectsUnderPoint() :: Scroll Bog Alex, Thank you so much for getting this information out. It was an instant cure for a problem that we spent quite a few of hours trying to figure out. It proved to be very sensitive piece of code - causing random side effects on different resolutions / hardware platforms. It seems that setting containers minWidth/minHeight on framework level to small > 0 value could of alleviate a lot of issues. Sincerely, Anatole ----- Original Message ----- From: Alex Harui To: [email protected] Sent: Tuesday, October 10, 2006 6:03 PM Subject: RE: [flexcomponents] topLevelSystemManager.getObjectsUnderPoint() :: Scroll Bog OK, glad that helped. If you do blog about, you might also mention that another motivation for this behavior is to try to limit the number of scrollbars that show up because scrollbars are ugly and hard to work with. In HTML, with flow layouts and all, you can pretty much set percentages and things will re-flow to fit by making the page longer (and you get one scrollbar for the whole page). In Flex, there is no flow so if we didn't make content size more important than percentage size, often you'd end up with scrollbars on all of your subcontainers. The way it is actually coded eliminates all the scrollbars except for the top-level one on the app. Which is why it was confusing when you wanted the scrollbar in a subcontainer. -Alex From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Schmalle Sent: Tuesday, October 10, 2006 2:32 PM To: [email protected] Subject: Re: [flexcomponents] topLevelSystemManager.getObjectsUnderPoint() :: Scroll Bog Well Alex, If I could give you a hug I would. Thanks. That solves the problem. You know I was thinking along the same lines except backwards. I was messing with the maxHeight - width and saw that 'confusing issue'. As far as the examples, I don't want to waste anyones time especially yours, that is why I just plain and simpled it in the last email. This solves all of my problems. I really don't like saying bugs either because half the time it isn't and this time it was one of those 'principle' bugs of not understanding an algorithm. Anyway, this clears up my issues, I was just dreading abstracting an example of this because just as your time is short I am against the wall also. I think this is something that should be documented better. I know of a couple people that have run into this and think it's a bug. I will blog about it, just to disseminate a little info. Thanks so much! Mike On 10/10/06, Alex Harui <[EMAIL PROTECTED]> wrote: Don't get me wrong. I'm not saying it is your code in this case, but just a good practice that will net you the fastest turnaround time on your issues. We're much more likely to cut and paste some code and see how it runs than to take the time to conjure up an app, and many times when I suggest a workaround based on my conjuring, it turns out that there's some other consideration that I didn't know about, so then I have to go through it again. However, I did conjure an app for problem #2. You are running into unexpected-expected behavior. It is expected by us, but unexpected by you, and therefore not a bug, but certainly confusing and annoying. It turns out there are situations in the Flex containers where, when a container has a percentage size, we still want to know the preferred size of the contents of the container, because if we don't honor the preferred size, it could essentially collapse down to nothing. Therefore, when you have percentage size, the minimum size is set to the measured size. Thus, percentages don't really work in a top-down fashion like it does in HTML. It sort of does, but the min size is always honored and because min size gets set to measured size, the contents of the container matter more than the percentage calculation. And so the answer is to set min size explicity. You can pretty much pick a random number like 100 or even less. So try adding to the tag: <core:WorkSpaceApplication id="mainApp" width="100%" height="100%" minWidth="100" minHeight="100" > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Schmalle Sent: Tuesday, October 10, 2006 11:08 AM To: [email protected] Subject: Re: [flexcomponents] topLevelSystemManager.getObjectsUnderPoint() :: Scroll Bog ok, Well, I'll try to get that together. All I want to do is use a base container as a root, have that container be able to be set at 100% height so it uses it's own vertical scrollbar. (I don't want the Application's vertical scrollbar) If I could get the above problem fixed, I don't even care about the getObjectsUnderPoint() issue. As I said, the systemManager problem only shows up with the Application container scrolling. I had just happened to find it because I was just willy nilly testing some things. My #1 goal is to have a base container use it's scrollbar with 100% height. <mx:Application verticalScrollPolicy="off" horizontalScrollPolicy="off"> <core:WorkSpaceApplication id="mainApp" width="100%" height="100%"> ... my dnd framework components go here. ... if any of the measurements INSIDE this container surpass 'mainApp's' vertical or horizontal bounds I want THIS container to delegate scrolling </core:WorkSpaceApplication> </mx:Application> With bug#1 (sm.getObj..) Thats not my framework either becasue I have just subclassed container and have solid background colors. I could not see anything that would make the system manager behave the way it is behaving when the actuall Application is scrolling. With bug#2 that is not my framework and the code I provided proves that. Thanks for your time Alex, Mike PS that is as simplified as I can explain it. Really if I could get the scrollbar issue fixed, I am good to go with the dragproxy. On 10/10/06, Alex Harui <[EMAIL PROTECTED]> wrote: It would help if you could make simplified examples. First, it proves that there aren't any side-effects from your framework, and it lets us see the direction you want to go in, such as how you want to implement your dragproxy. Then we can better propose workarounds. Same for the other problem. From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Schmalle Sent: Tuesday, October 10, 2006 9:48 AM To: [email protected] Subject: Re: [flexcomponents] topLevelSystemManager.getObjectsUnderPoint() :: Scroll Bog Hi Alex, Yeah and I found another bug which I think you guys know of, but it is killing me. First bug; I can't post the real code because it's part of a huge framework, I will try to explain so you can get the visual idea here. Imagine that each child of the VBox's can be dragged. The parent pane1 and pane2 can be dropped into. If you click a header from the left pane's children and start a drag operation with the drag manager, this starts the drag and shows the drag proxy image. Next, drag over to the right OVER pane2, this wil fire a dragEnter event on pane2, all is well. Now If your screen lets you see the Application's v scrollbar, you would then scroll the v scroll bar to the mxaVerticalPosition. Repeat the same procedure, click on pane1's child, say tasklist 4, then drag OVER to pane2(right), there is no dragEnter being fired at this point. If you keep dragging up pane2 until you reach the 'original' bounds of the actual Application(stage height & width), a dragEnter event will fire. I copied the DragManager and DragProxy classes to enable myself to do traces. It seems as the the calculation in the mouseMove() method of the DragProxy class is not taking into account if the 'topLevelSystemManager' has a ScrollRect going on. I understand that it is the Application that is scrolling and not the systemManager but this seems to be where the error is happening and it is not picking up the right display object list. The other bug that I know a lot of people are running into is; minimize your window containing this example and resize it, you will see that the horizontal scrollbar is present throughout the whole resizing if you minimize it enough as to get the vertical scroll bar. I have debugged this and it seems to be that somewhere in the container, the veiwMetrics are not getting set right to account for the vertical scrollbar. Matt said he filed a bug for this. Notice that the mainApp has it's height set to 100%, this should mean that instead of getting the applications scrollbar, we should get the mainApp VBox scrollbar because the Application will size the VBox to 100% height of the Application, then delegating the scrolling to the VBox. This is a nasty bug. There are a lot of things I am trying to do with custom components that this is messing with. Do you guys have a workaround for this maybe? In my dnd framework it is a subclass of Container, if you did have a workaround, I could implement it in the class that subclasses Container. Other than that any component I make is giving me that extra 16 pixels that isn't accounted for. Let me know if you have any questions. Thanks, Mike Quasi Code ---------------------------------------------------------------------------------------------------------------------- <?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx=" http://www.adobe.com/2006/mxml"; layout="vertical"> <mx:HBox id="mainApp" width="100%" height="100%" paddingBottom="5" paddingLeft="5" paddingRight="5" paddingTop="5"> <mx:VBox id="pane1" width="250"> <mx:VBox label="TaskList One" width="100%"> <mx:List width="100%" /> </mx:VBox> <mx:VBox label="TaskList Two" width="100%"> <mx:DateChooser width="100%" height="400"/> </mx:VBox> <mx:VBox label="TaskList Three" width="100%"> <mx:List id="list" width="100%" height="100%"> <mx:Object label="POLICIES AND PROCEDURES"/> <mx:Object label="PRESIDENT"/> <mx:Object label="ACHIEVEMENT AWARD"/> <mx:Object label="TRAINING CENTER"/> <mx:Object label="TEST DOC CENTER"/> <mx:Object label="POLICIES AND PROCEDURES"/> <mx:Object label="PRESIDENT"/> <mx:Object label="ACHIEVEMENT AWARD"/> <mx:Object label="TRAINING CENTER"/> <mx:Object label="TEST DOC CENTER"/> <mx:Object label="POLICIES AND PROCEDURES"/> <mx:Object label="PRESIDENT"/> <mx:Object label="ACHIEVEMENT AWARD"/> <mx:Object label="TRAINING CENTER"/> <mx:Object label="TEST DOC CENTER"/> <mx:Object label="POLICIES AND PROCEDURES"/> <mx:Object label="PRESIDENT"/> <mx:Object label="ACHIEVEMENT AWARD"/> <mx:Object label="TRAINING CENTER"/> <mx:Object label="TEST DOC CENTER"/> <mx:Object label="POLICIES AND PROCEDURES"/> <mx:Object label="PRESIDENT"/> <mx:Object label="ACHIEVEMENT AWARD"/> <mx:Object label="TRAINING CENTER"/> <mx:Object label="TEST DOC CENTER"/> <mx:Object label="POLICIES AND PROCEDURES"/> <mx:Object label="PRESIDENT"/> <mx:Object label="ACHIEVEMENT AWARD"/> <mx:Object label="TRAINING CENTER"/> <mx:Object label="TEST DOC CENTER"/> </mx:List> </mx:VBox> <mx:VBox label="TaskList Four" width="100%"> <mx:List width="100%" /> </mx:VBox> </mx:VBox> <mx:Canvas id="table" width="100%" height="100%"> </mx:Canvas> <mx:VBox id="pane2" width="250"> <mx:VBox label="TaskList One" width="100%"> <mx:List width="100%" /> </mx:VBox> <mx:VBox label="TaskList Two" width="100%"> <mx:DateChooser width="100%" height="400"/> </mx:VBox> <mx:VBox label="TaskList Four" width="100%"> <mx:List width="100%" /> </mx:VBox> </mx:VBox> </mx:HBox> </mx:Application> On 10/10/06, Alex Harui <[EMAIL PROTECTED] > wrote: Can you post the code? Thanks, -Alex From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Schmalle Sent: Tuesday, October 10, 2006 5:06 AM To: [email protected] Subject: [flexcomponents] topLevelSystemManager.getObjectsUnderPoint() :: Scroll Bog Hi, I have found an interesting bug and please if you told me it wasn't I would be ecstatic. Through about 4 hours of testing something I had no idea what was going on, I think I widled the stick down. Example: Say you create 2 draggable containers, one on the left side and one on the right side with say a Canvas in the middle. For this bug to show, you have to have these containers in the Application container. It seems as though when DragProxy is calling the topLevelSystemManager which is obviously the Application's systemManager in this case, when the containers extend outside of the Application's vertical boundary create v scrollbars the method does not return the correct list(just mouseCatcher). So, when the root application had drag containers in it, and it is scrolled, the method only picks up the client container relative to the scroll position(in the bounds of the original screen coords). This doesn't make sense to me because doesn't the root system manager stay in place when the Application is scrolling? Now, If I wrap the dnd containers in a VBox(container) the problem goes away but, That means that I have to 'force' the VBox's scrollbars instead of using the application's. Really, this makes the DragProxy class useless for me as it stands because it is not an option telling clients they have to go out of their way. I am experimenting with a different technique for my dnd. I would love to hear from adobe on the 'principle' of the topLevelSystemManager and why scrolling the application would mess up the getObjectsUnderPoint() of the topLevelSystemManager. Peace, Mike -- What goes up, does come down. -- What goes up, does come down. -- What goes up, does come down. -- What goes up, does come down. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcomponents/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcomponents/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
