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]com> 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]com> 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]com > 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.
