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.
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. __._,_.___![]()
SPONSORED LINKS
Software development tool Application development software Development software Development outsourcing software Embedded software development
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
__,_._,___
- [flexcomponents] topLevelSystemManager.getObjectsUnder... Michael Schmalle
- RE: [flexcomponents] topLevelSystemManager.getObj... Alex Harui
- Re: [flexcomponents] topLevelSystemManager.ge... Michael Schmalle
- Re: [flexcomponents] topLevelSystemManage... Michael Schmalle
- Re: [flexcomponents] topLevelSystemMa... Michael Schmalle
- Re: [flexcomponents] topLevelSystemManager.getObj... Anatole Tartakovsky
- RE: [flexcomponents] topLevelSystemManager.ge... Bjorn Schultheiss
- Re: [flexcomponents] topLevelSystemManager.ge... Michael Schmalle
Reply via email to
