Re: [flexcomponents] topLevelSystemManager.getObjectsUnderPoint() :: Scroll Bog

[Michael Schmalle]

> when you have scrollPolicy=off on the application container and
you expect inner containers understand that - thus limiting themselves to
the visible area.

I was trying to do that intuitively(that is how my mind thought it should work). I think that is a great idea.

If you set the scrollPolicy to off, you are actually telling the container to put the children's percentage at the highest priority when measuring as if you set the minHeight to 100.

Besides, if say someone did set the scrollPolicy to off, and they wanted the content to clip, they wouldn't be using percentages anyway and Flex would measure correctly and clip the children based on their measuredWidth/Height.

I think in my vote this would be the MOST intuitive solution to this confusing issue.

Mike

On 10/10/06, Anatole Tartakovsky < [EMAIL PROTECTED]> wrote:

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: flexcomponents@yahoogroups.com

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: flexcomponents@yahoogroups.com [mailto: flexcomponents@yahoogroups.com]
On Behalf Of Anatole Tartakovsky
Sent: Tuesday, October 10, 2006 4:35 PM
To: flexcomponents@yahoogroups.com
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: flexcomponents@yahoogroups.com
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: flexcomponents@yahoogroups.com [mailto: flexcomponents@yahoogroups.com]
On Behalf Of Michael Schmalle
Sent: Tuesday, October 10, 2006 2:32 PM
To: flexcomponents@yahoogroups.com
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: flexcomponents@yahoogroups.com [mailto: flexcomponents@yahoogroups.com]
On Behalf Of Michael Schmalle
Sent: Tuesday, October 10, 2006 11:08 AM

To: flexcomponents@yahoogroups.com
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: flexcomponents@yahoogroups.com [mailto: flexcomponents@yahoogroups.com]
On Behalf Of Michael Schmalle
Sent: Tuesday, October 10, 2006 9:48 AM
To: flexcomponents@yahoogroups.com
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: flexcomponents@yahoogroups.com [mailto: flexcomponents@yahoogroups.com]
On Behalf Of Michael Schmalle
Sent: Tuesday, October 10, 2006 5:06 AM
To: flexcomponents@yahoogroups.com
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.

--
What goes up, does come down. __._,_.___

SPONSORED LINKS

Custom software development	Database development software	Embedded software development
Offshore software development	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

__,_._,___