Re: [6831staff] If PS3 didn't work...

[Michael Bernstein]

Good question.  You'll need to fix enough bugs in PS3 for the PS4 functionality to work and be testable.  If you're worried about whether it will be testable, show it to one of us in class on Friday.
- Michael

Hello,

A large part of this pset relies on our PS3 code working fine.  If it doesn't, then a) how much would be deducted for improper PS3 code, and b) would it be possible to get a working copy?

[Ted Tomlinson]

Are we allowed to use a sprite for the first part of the problem set for the checker as we are moving it? The sprite is still drawn with the graphics component in the spirit of the stroke model, but it is a child of the stage. Or do we have to do all of our drawing only on the checkerboard graphics component?

[Rob Miller]

No, a sprite is effectively a component with event-handling capability built-in.  Part of the point of Problem 1, StrokeCheckerboard, is to learn how to write the input-handling code when you're drawing things yourself, not representing them as components.

[Ted Tomlinson]

Ok. 

For the third part of the problem set since we can have different selections on each view, what do we do if the user clicks "remove checker" or "make king" on the stroke view, but it has a different selection than the pixel view and the two view are sharing the same model? I presume that we are supposed to update the model when we change the view, but this could mean that when the model is shared, a change according to the selection unique to one view will change the component on the other view even though it isn't selected. Is that okay behavior? I'm not sure if I've described the situation well, but it basically comes down to the inconsistency of selection being unique to the view and generating changes in a model that is not unique to the view.

[Angela N Chang]

Someone from the course staff should probably answer this question to be safe, but they way I see it, the two boards just need to share the model when that option is selected, and not any intermediary state of the view.  It could get tricky having one board listen to (or notify) the other board since events aren't caught in the one that is not currently in view... and the fact that there is only ever one board in view at any time means that changing both seems to add unnecesary complexity to functionality that will never actually be seen by the user.

Since the model is only supposed to be updated when a valid move is made (i.e. when the user is done dragging a checker around), two boards with a shared model should just show the same board configuration at any point in time, and I don't think we have to worry about one view changing of its own accord before the model changes.

Angela

--
Angela N. Chang
department of electrical engineering & computer science
massachusetts institute of technology || class of 2011
nih...@mit.edu || 305.215.6586 || http://nihwey.scripts.mit.edu

[Ted Tomlinson]

The problem is that a component that is not selected on the view that isn't visible can be changed if both views share the same model. Clicking "make king" will make the selected checker on that view a king, and change the associated board model to reflect that. The problem is that when the board model changes it triggers the change event for all views attached to it. Thus the piece on the non visible view will change to a king even though it isn't selected. I think this is probably the right behavior, since the view should always be consistent with the model, but it is confusing from a UI perspective because the non visible board will change independently of its selection. 

[Brianna Veenstra]

I think it's reasonable to say that once you aren't viewing the board it doesn't have a selection?

[Shawn Conrad]

Readdressing the second post to this thread, I'm having trouble getting around not using a sprite.  In fact, I can't even get a circle to draw where I click.  I assume its because the order that my graphics are being drawn is causing my desired circle to be drawn under everything else.  This confuses me, because I think the order of what I'm doing is:

check for mouseDown/mouseDrag
find if there is a checker in the row/column where I clicked
if there is, remove it (this should call checkerListener, which repaints the other squares/checkers)
draw a circle centered where I clicked (to show that I've made a "draggable" checker)

This is as far as I've gotten because I can't make the circle in the last step.  From there, I figure its easy enough to continually remove and redraw the last made circle as one drags their mouse.

Could anyone show me where I'm going wrong or give me a pointer?

Thanks

Shawn

[Fuming Shih]

do you try the difference of "event.target" and "event.currentTarget"?

--
Fuming, Shih
Research Assistant ,
Decentralized Information Group,
CSAIL, MIT

[Shawn Conrad]

I'm sorry, but I'm confused at what you're getting at.  I don't use either, although it sounds like I should be using one for something.

[Ted Tomlinson]

It sounds like you are talking about the first part of the pset with the stroke model. You don't (and probably shouldn't) be using the generic CheckerboardInteractor class since you are binding click events to only the checkboard (since there are no children). This means you shouldn't have to worry about the event.target or current target since you are writing it inside the checkerboard class and can just use this.mouseX and this.mouseY to get the mouse position inside the checkerboard. With the stroke model I used the same technique you used by redrawing the board, then all the checkers but the active one (based on its location), and then the active checker that should be moving. When the user initially clicks on the board I add event listeners for MouseMove (to redraw the enire board every time the mouse moves with the active checker in the new "dragged location") and Mouseup to end the drag drop interface and check if the new spot is open. Drawing in the order you gave should have the circle on top. Not sure if this helps.

Ted

On Sat, Apr 3, 2010 at 11:29 PM, Shawn Conrad <shw...@gmail.com> wrote:

[Tony Tran]

Question on part 3 (more like clarification)

Clicking on the square in either view (without hit-testing, which is optional) basically starts the drag & drop operation.  So when we "select" a square, that's basically the same as picking up the piece and immediately dropping it down on the same square isn't it?  Currently, I can't think of a way to click the square and not having the UI think you're trying to drag&drop the checker.  

Am I missing something?  The implications are you can literally only "select a piece" if that piece has just been dragged and dropped.  

--
Tony Tran
Massachusetts Institute of Technology
Dept. of Electrical Engineering and Computer Science

[Steven Bartel]

I don't see the problem here - you are supposed to select after things are dragged and dropped.  The fact that clicking on a checker results in a drag drop makes this even easier, since you can just handle the selection once at the end of the drop event.

-Steve

  

--

Steven Bartel

Department of Electrical Engineering and Computer Science

Massachusetts Institute of Technology 2010

Phone: (617) 312-7225

[Zhilei Xu]

But the tricky things happen when you press your mouse button on an empty square, then move a little bit, and then release your mouse button.

This is a "drag and drop", but should this be considered a "clicking" so that it still clear the selection?

I suppose it should clear the selection. Anyone knows an official answer? Thanks!
________________________________________
From: 68...@googlegroups.com [68...@googlegroups.com] On Behalf Of Steven Bartel [sba...@MIT.EDU]
Sent: Sunday, April 04, 2010 3:15 AM
To: 68...@googlegroups.com
Subject: Re: [6831staff] If PS3 didn't work...

I don't see the problem here - you are supposed to select after things are dragged and dropped. The fact that clicking on a checker results in a drag drop makes this even easier, since you can just handle the selection once at the end of the drop event.

-Steve

--
Steven Bartel
Department of Electrical Engineering and Computer Science
Massachusetts Institute of Technology 2010
Phone: (617) 312-7225

On Apr 4, 2010, at 1:22 AM, Tony Tran wrote:

Question on part 3 (more like clarification)

Clicking on the square in either view (without hit-testing, which is optional) basically starts the drag & drop operation. So when we "select" a square, that's basically the same as picking up the piece and immediately dropping it down on the same square isn't it? Currently, I can't think of a way to click the square and not having the UI think you're trying to drag&drop the checker.

Am I missing something? The implications are you can literally only "select a piece" if that piece has just been dragged and dropped.

On Sun, Apr 4, 2010 at 1:10 AM, Ted Tomlinson <zum...@gmail.com<mailto:zum...@gmail.com>> wrote:
It sounds like you are talking about the first part of the pset with the stroke model. You don't (and probably shouldn't) be using the generic CheckerboardInteractor class since you are binding click events to only the checkboard (since there are no children). This means you shouldn't have to worry about the event.target or current target since you are writing it inside the checkerboard class and can just use this.mouseX and this.mouseY to get the mouse position inside the checkerboard. With the stroke model I used the same technique you used by redrawing the board, then all the checkers but the active one (based on its location), and then the active checker that should be moving. When the user initially clicks on the board I add event listeners for MouseMove (to redraw the enire board every time the mouse moves with the active checker in the new "dragged location") and Mouseup to end the drag drop interface and check if the new spot is open. Drawing in the order you gave should have the circle on top. Not sure if this helps.
Ted

On Sat, Apr 3, 2010 at 11:29 PM, Shawn Conrad <shw...@gmail.com<mailto:shw...@gmail.com>> wrote:
Readdressing the second post to this thread, I'm having trouble getting around not using a sprite. In fact, I can't even get a circle to draw where I click. I assume its because the order that my graphics are being drawn is causing my desired circle to be drawn under everything else. This confuses me, because I think the order of what I'm doing is:

check for mouseDown/mouseDrag
find if there is a checker in the row/column where I clicked
if there is, remove it (this should call checkerListener, which repaints the other squares/checkers)
draw a circle centered where I clicked (to show that I've made a "draggable" checker)

This is as far as I've gotten because I can't make the circle in the last step. From there, I figure its easy enough to continually remove and redraw the last made circle as one drags their mouse.

Could anyone show me where I'm going wrong or give me a pointer?

Thanks
Shawn

On Thu, Apr 1, 2010 at 2:57 PM, Brianna Veenstra <veen...@mit.edu<mailto:veen...@mit.edu>> wrote:
I think it's reasonable to say that once you aren't viewing the board it doesn't have a selection?

On Thu, Apr 1, 2010 at 1:39 PM, Ted Tomlinson <zum...@gmail.com<mailto:zum...@gmail.com>> wrote:
The problem is that a component that is not selected on the view that isn't visible can be changed if both views share the same model. Clicking "make king" will make the selected checker on that view a king, and change the associated board model to reflect that. The problem is that when the board model changes it triggers the change event for all views attached to it. Thus the piece on the non visible view will change to a king even though it isn't selected. I think this is probably the right behavior, since the view should always be consistent with the model, but it is confusing from a UI perspective because the non visible board will change independently of its selection.

On Thu, Apr 1, 2010 at 1:27 PM, Angela N Chang <nih...@mit.edu<mailto:nih...@mit.edu>> wrote:
Someone from the course staff should probably answer this question to be safe, but they way I see it, the two boards just need to share the model when that option is selected, and not any intermediary state of the view. It could get tricky having one board listen to (or notify) the other board since events aren't caught in the one that is not currently in view... and the fact that there is only ever one board in view at any time means that changing both seems to add unnecesary complexity to functionality that will never actually be seen by the user.

Since the model is only supposed to be updated when a valid move is made (i.e. when the user is done dragging a checker around), two boards with a shared model should just show the same board configuration at any point in time, and I don't think we have to worry about one view changing of its own accord before the model changes.

Angela

On 4/1/2010 12:55 PM, Ted Tomlinson wrote:
Ok.

For the third part of the problem set since we can have different selections on each view, what do we do if the user clicks "remove checker" or "make king" on the stroke view, but it has a different selection than the pixel view and the two view are sharing the same model? I presume that we are supposed to update the model when we change the view, but this could mean that when the model is shared, a change according to the selection unique to one view will change the component on the other view even though it isn't selected. Is that okay behavior? I'm not sure if I've described the situation well, but it basically comes down to the inconsistency of selection being unique to the view and generating changes in a model that is not unique to the view.

On Thu, Apr 1, 2010 at 11:11 AM, Rob Miller <r...@mit.edu<mailto:r...@mit.edu>> wrote:
No, a sprite is effectively a component with event-handling capability built-in. Part of the point of Problem 1, StrokeCheckerboard, is to learn how to write the input-handling code when you're drawing things yourself, not representing them as components.

On Thu, Apr 1, 2010 at 11:04 AM, Ted Tomlinson <zum...@gmail.com<mailto:zum...@gmail.com>> wrote:
Are we allowed to use a sprite for the first part of the problem set for the checker as we are moving it? The sprite is still drawn with the graphics component in the spirit of the stroke model, but it is a child of the stage. Or do we have to do all of our drawing only on the checkerboard graphics component?

On Thu, Apr 1, 2010 at 3:53 AM, Michael Bernstein <msbe...@mit.edu<mailto:msbe...@mit.edu>> wrote:
Good question. You'll need to fix enough bugs in PS3 for the PS4 functionality to work and be testable. If you're worried about whether it will be testable, show it to one of us in class on Friday.
- Michael

Hello,

A large part of this pset relies on our PS3 code working fine. If it doesn't, then a) how much would be deducted for improper PS3 code, and b) would it be possible to get a working copy?

--
Angela N. Chang
department of electrical engineering & computer science
massachusetts institute of technology || class of 2011

nih...@mit.edu<mailto:nih...@mit.edu> || 305.215.6586 || http://nihwey.scripts.mit.edu

[Kanjun Qiu]

Is anyone having trouble calling board.size in CheckerboardInteractor (subclass of MoveInteractor)? Underneath the drop function override, I have this if statement that calls board.size:

if (destLoc.row > board.size-1 || destLoc.col > board.size-1)

It seems that no code after that is run because board.size makes the program angry for some reason. I tried calling Alert.show((board.size).toString()) before that, and then Alert.show("test"), neither of these two alerts displays. However, if I only have Alert.show("test") before the if statement, it shows up. I can only assume that this is because the program doesn't execute anything after board.size.

Does anyone know what the issue might be? I call board.size from StrokeCheckerboard and there isn't a problem...I'm not sure why it's causing issues here.

Thanks!

Kanjun

--
Kanjun Qiu | kan...@mit.edu | 630.803.8449
Massachusetts Institute of Technology | 2012

Electrical Engineering and Computer Science

[Olayemi A F Oyebode]

I do get access to board, but the way I did was that I passed the pixelCheckerboard as a parameter to the CheckerboardInteractor when I create it and store it as a variable of the CheckerboardInteractor

2010/4/4 Kanjun Qiu <kan...@mit.edu>

--
Mr Olayemi A F Oyebode

[Kanjun Qiu]

Woops, my bad - figured out that the board was null. I for some reason don't get any console printouts. Does Flex tell you when things are null?

Kanjun

[Sean Liu (Gmail)]

You need debugging flash to get it to give you error messages.

I'm stuck in the same boat...when things aren't happening have to go digging for the error with Alert.show >_<.

Sean

--
Sean Liu
Massachusetts Institute of Technology
Department of Electrical Engineering & Computer Science '10
(916) 220-4326 | sean...@mit.edu

[Olayemi A F Oyebode]

I was stuck in the same boat, but I went and installed FlashPlayer 9 debugger version. I had to uninstall my existing flashPlayer (Version 10) first. http://www.adobe.com/support/flashplayer/downloads.html

Once you've done that, you can run Flex Builder in debug and use trace. 

2010/4/4 Sean Liu (Gmail) <sean....@gmail.com>

[Sean Liu (Gmail)]

I guess this question should be directed to the staff...

Do we need to handle the "Move randomly" button with respect to the selected checker?  For instance, say we had a selected checker.  If the user clicks "move randomly" and the checker gets moved, do we need to handle de-selecting that checker?

[Rob Miller]

That behavior is left unspecified in the problem set writeup, so it won't be graded.  But it seems sensible that if a selected checker is moved in the model, it should stay selected in the view.  Otherwise you're throwing away the work the user did to select that checker, for no good reason.

[Usman Masood]

So the pset says that we have implement the selection stuff in the view; but what if we're using different models for the two views? In that case I think we have to save some sort of state in the model.

Usman

[Tobe Nwanna]

When you release the mouse button there shouldn't be a selected checker anymore

[Brianna Veenstra]

Regarding selection: Is there a specific "yellow" we should be using for part 3?  For instance, the GOLD already defined?

[Michael Bernstein]

Zhilei, I would think that it would clear the selection.  I'd imagine that this makes things much easier to implement, too.
- Michael

On Sun, Apr 4, 2010 at 12:34 PM, Zhilei Xu <ti...@mit.edu> wrote:

[Maria Rodriguez]

Anyone know how/where to use addChildAt() to make the component being dragged show up on top? I want to put it inside my pickUp method in CheckerboardMoveInteractor, but I don't know what to call .addChildAt(checker,1) on...

Thanks!
Maria

--
Maria I. Rodriguez
Massachusetts Institute of Technology

Electrical Engineering & Computer Science

Class of 2011

[Michael Bernstein]

I would call it on the component's parent, which you can get out of the component.  You can also ask the component to tell you how many children it has, which will be helpful in getting it the highest in the Z-order.

- Michael

[Maria Rodriguez]

That works! :)

Thank you,
Maria

[Nicole Bieber]

Okay, I have what may be a very dumb question - but why do we need to
use MouseEvent.target to figure out what component is being dragged?
Don't we already know which component is being dragged because that's
the component whose listener was activated?
-n

> <mailto:68...@googlegroups.com> [68...@googlegroups.com
> <mailto:68...@googlegroups.com>] On Behalf Of Steven
> Bartel [sba...@MIT.EDU <mailto:sba...@MIT.EDU>]

> Sent: Sunday, April 04, 2010 3:15 AM

> To: 68...@googlegroups.com <mailto:68...@googlegroups.com>

> <mailto:zum...@gmail.com><mailto:zum...@gmail.com

> <mailto:zum...@gmail.com>>> wrote:
> It sounds like you are talking about the first part of
> the pset with the stroke model. You don't (and
> probably shouldn't) be using the generic
> CheckerboardInteractor class since you are binding
> click events to only the checkboard (since there are
> no children). This means you shouldn't have to worry
> about the event.target or current target since you are
> writing it inside the checkerboard class and can just
> use this.mouseX and this.mouseY to get the mouse
> position inside the checkerboard. With the stroke
> model I used the same technique you used by redrawing
> the board, then all the checkers but the active one
> (based on its location), and then the active checker
> that should be moving. When the user initially clicks
> on the board I add event listeners for MouseMove (to
> redraw the enire board every time the mouse moves with
> the active checker in the new "dragged location") and
> Mouseup to end the drag drop interface and check if
> the new spot is open. Drawing in the order you gave
> should have the circle on top. Not sure if this helps.
> Ted
>
> On Sat, Apr 3, 2010 at 11:29 PM, Shawn Conrad
> <shw...@gmail.com

> <mailto:shw...@gmail.com><mailto:shw...@gmail.com

> <mailto:veen...@mit.edu><mailto:veen...@mit.edu

> <mailto:veen...@mit.edu>>> wrote:
> I think it's reasonable to say that once you aren't
> viewing the board it doesn't have a selection?
>
>
> On Thu, Apr 1, 2010 at 1:39 PM, Ted Tomlinson
> <zum...@gmail.com

> <mailto:zum...@gmail.com><mailto:zum...@gmail.com

> <mailto:zum...@gmail.com>>> wrote:
> The problem is that a component that is not selected
> on the view that isn't visible can be changed if both
> views share the same model. Clicking "make king" will
> make the selected checker on that view a king, and
> change the associated board model to reflect that. The
> problem is that when the board model changes it
> triggers the change event for all views attached to
> it. Thus the piece on the non visible view will change
> to a king even though it isn't selected. I think this
> is probably the right behavior, since the view should
> always be consistent with the model, but it is
> confusing from a UI perspective because the non
> visible board will change independently of its selection.
>
>
> On Thu, Apr 1, 2010 at 1:27 PM, Angela N Chang
> <nih...@mit.edu

> <mailto:nih...@mit.edu><mailto:nih...@mit.edu

> <r...@mit.edu <mailto:r...@mit.edu><mailto:r...@mit.edu

> <mailto:r...@mit.edu>>> wrote:
> No, a sprite is effectively a component with
> event-handling capability built-in. Part of the point
> of Problem 1, StrokeCheckerboard, is to learn how to
> write the input-handling code when you're drawing
> things yourself, not representing them as components.
>
>
> On Thu, Apr 1, 2010 at 11:04 AM, Ted Tomlinson
> <zum...@gmail.com

> <mailto:zum...@gmail.com><mailto:zum...@gmail.com

> <mailto:zum...@gmail.com>>> wrote:
> Are we allowed to use a sprite for the first part of
> the problem set for the checker as we are moving it?
> The sprite is still drawn with the graphics component
> in the spirit of the stroke model, but it is a child
> of the stage. Or do we have to do all of our drawing
> only on the checkerboard graphics component?
>
>
> On Thu, Apr 1, 2010 at 3:53 AM, Michael Bernstein
> <msbe...@mit.edu

> <mailto:msbe...@mit.edu><mailto:msbe...@mit.edu

> <mailto:msbe...@mit.edu>>> wrote:
> Good question. You'll need to fix enough bugs in PS3
> for the PS4 functionality to work and be testable. If
> you're worried about whether it will be testable, show
> it to one of us in class on Friday.
> - Michael
>
> Hello,
>
> A large part of this pset relies on our PS3 code
> working fine. If it doesn't, then a) how much would
> be deducted for improper PS3 code, and b) would it be
> possible to get a working copy?
>
>
>
>
>
>
> --
> Angela N. Chang
> department of electrical engineering & computer science
> massachusetts institute of technology || class of 2011
> nih...@mit.edu

> <mailto:nih...@mit.edu><mailto:nih...@mit.edu

[Nicole Bieber]

nevermind, I think I answered my own question. I feel silly now.
-n

[Tony Tran]

true, you don't have to use MouseEvent.target

--
To unsubscribe, reply using "remove me" as the subject.

[Katherine Lin]

Ok, so I have a really strange bug that I am stumped on how to fix. Wondering if anyone has encountered similar?

The behavior is like this:
You select a checker and start dragging out of the panel, say towards the address bar and move the cursor into the address bar area. Release the mouse. Then come back into the panel and let the checker follow you. Even though you are not MouseDown, the checker follows you. To release, you have to MouseDown, but if you do that, say in the white space to the right of the checkerboard, you get:

Error: square [3,15] is not found  in this 8x8 board
    at model::Board/checkIsValid()[C:

\Users\Katlin\workspace3.4\Pset4\src\model\Board.as:247]
    at model::Board/checkerAt()[C:\Users\Katlin\workspace3.4\Pset4\src\model\Board.as:104]
    at ui::CheckerMoveInteractor/pickUp()[C:\Users\Katlin\workspace3.4\Pset4\src\ui\CheckerMoveInteractor.as:171]
    at ui::CheckerMoveInteractor/onMouseDownListener()[C:\Users\Katlin\workspace3.4\Pset4\src\ui\CheckerMoveInteractor.as:130]

I think the issue is that there is no listener to catch the MouseUp event if you release at the address bar, but not sure how to fix it?

Help!
-Katherine

[Steven Bartel]

When you release outside of the board, the behavior is undefined, so you can make the behavior be whatever you'd like.  Personally, if they release outside of the board boundaries, I drop it the next time the user clicks.

The specific error you see is because you are dropping outside of the bounds of your checkerboard.  You click on what would be square (3,15) if the board was big enough.  However, since it isn't, the model throws an error.  You can solve this by having the view query the model for the board dimensions and explicitly checking whether your dropped falls within the dimensions or not.

Good luck,

-Steve

--

Steven Bartel

Department of Electrical Engineering and Computer Science

Massachusetts Institute of Technology 2010

Phone: (617) 312-7225

[Katherine Lin]

Thanks Steve, but that doesn't quite fix it.

So if I release the mouse within the webpage, everything is fine, (that is, outside of the checkerboard, but inside the panel). But if I release my mouse outside of the webpage, there is nothing to listen to the MouseUpAction and that's when I get the error. =(

-Kat

[Steven Bartel]

I have code that remembers if i was dragging, so I just check if I was dragging on the mouse down events too.  Give that a try if you want.

-Steve

[Sean Liu (Gmail)]

Is there a simple way to do bind the button enabled="{}" to if a selection has been made?

At first I tried making a [Bindable] var hasSelected:Boolean = false inside Checkerboard.mxml.  But the issue is how to specify the enabled="{}" inside the button in Main.mxml.  It seems like if I do:

enabled="{Checkerboard(tabs.selectedChild.getChildByName('checkerboard')).hasSelected}"

It only binds to the StrokeCheckerboard's hasSelected, since it's the first tab in view.  Alternatively if I try defining a new [Bindable] get and set method for a variable, I run into the issue in which the variable itself then needs to bind to two separate hasSelected variables (one for the StrokeCheckerboard and one for the PixelCheckerboard).

Alternatively I tried adding an "id" to the boards where they're defined in Main.mxml.  But then I also need to make sure that I switch between the variables I'm binded to 9either strokeCheckerboard.hasSelected or pixelCheckerboard.hasSelected) depending on the tab selection.

Any pointers?

Thanks,

Sean

--
Sean Liu
Massachusetts Institute of Technology

Department of Electrical Engineering & Computer Science '10
(916) 220-4326 | sean...@mit.edu

[Olayemi A F Oyebode]

My solution was multi part:

1.) Based on a TA's suggestion, I defined separate functions that get called by strokeCheckerboard and pixelCheckerboard on creationcomplete. This function then uses BindingUtils to set the bindings. I used specifically BindingUtils.bindSetter(...) so that I could call another function that detected which board/checkerboard was visible and changed it. 

2.) Whenever you switch between views, the tabnavigator generates change events. So I edited the tabnavigator to call a function  for change. This function detected which board is visible (if there is one) and turns on/off the buttons. 

Hope that helps. 

2010/4/4 Sean Liu (Gmail) <sean....@gmail.com>

Is there a simple way to do bind the button enabled="{}" to if a selection has been made?

[Sean Liu (Gmail)]

Thanks, Olay!  That worked.  I made it possibly less complicated...

Added a Bindable boolean variable in Checkerboard.

I named the various boards by adding an id property in the Main.mxml.

Then I made the change event handler for the tabNavigator, which just toggled the binding between the stroke and pixel boards' boolean.

Thanks so much!

Sean

[Nicole Bieber]

Okay, possible silly question again, but how do I figure out which
checker is selected in part 2? I can figure out which UIComponent is
selected - but since the mouse coordinates are all relative, how do I
actually get the checker?
Thanks,
n

Sean Liu (Gmail) wrote:
> Thanks, Olay! That worked. I made it possibly less complicated...
>
> Added a Bindable boolean variable in Checkerboard.

> I named the various boards by adding an /id/ property in the Main.mxml.
> Then I made the /change/ event handler for the tabNavigator, which

> just toggled the binding between the stroke and pixel boards' boolean.
>
> Thanks so much!
> Sean
>
> On Sun, Apr 4, 2010 at 6:25 PM, Olayemi A F Oyebode <olay...@mit.edu
> <mailto:olay...@mit.edu>> wrote:
>
> My solution was multi part:
>
> 1.) Based on a TA's suggestion, I defined separate functions that
> get called by strokeCheckerboard and pixelCheckerboard on
> creationcomplete. This function then uses BindingUtils to set the
> bindings. I used specifically BindingUtils.bindSetter(...) so that

> I could call /another/ function that detected which

> board/checkerboard was visible and changed it.
>
> 2.) Whenever you switch between views, the tabnavigator generates
> change events. So I edited the tabnavigator to call a function

> for /change/. This function detected which board is visible (if

> there is one) and turns on/off the buttons.
>
> Hope that helps.
>
> 2010/4/4 Sean Liu (Gmail) <sean....@gmail.com

> <mailto:sean....@gmail.com>>

>>> <mailto:msbe...@mit.edu
>>> <mailto:msbe...@mit.edu>>> wrote:
>>>
>>> I would call it on the component's
>>> parent, which you can get out
>>> of the component. You can also ask
>>> the component to tell you how
>>> many children it has, which will be
>>> helpful in getting it the
>>> highest in the Z-order.
>>> - Michael
>>>
>>>
>>> On Sun, Apr 4, 2010 at 3:17 PM, Maria
>>> Rodriguez <mar...@mit.edu
>>> <mailto:mar...@mit.edu>

>>> <mailto:mar...@mit.edu

>>> <mailto:mar...@mit.edu>>> wrote:
>>>
>>> Anyone know how/where to use
>>> addChildAt() to make the
>>> component being dragged show up
>>> on top? I want to put it
>>> inside my pickUp method in
>>> CheckerboardMoveInteractor, but I
>>> don't know what to call
>>> .addChildAt(checker,1) on...
>>>
>>> Thanks!
>>> Maria
>>>
>>>
>>> On Sun, Apr 4, 2010 at 2:51 PM,
>>> Michael Bernstein
>>> <msbe...@mit.edu
>>> <mailto:msbe...@mit.edu>

>>> <mailto:msbe...@mit.edu
>>> <mailto:msbe...@mit.edu>>> wrote:
>>>
>>> Zhilei, I would think that it
>>> would clear the selection.
>>> I'd imagine that this makes things much
>>> easier to
>>> implement, too.
>>> - Michael
>>>
>>> On Sun, Apr 4, 2010 at 12:34
>>> PM, Zhilei Xu <ti...@mit.edu
>>> <mailto:ti...@mit.edu>

>>> <mailto:ti...@mit.edu

>>> <mailto:ti...@mit.edu>>> wrote:
>>>
>>> But the tricky things
>>> happen when you press your mouse
>>> button on an empty
>>> square, then move a little bit, and
>>> then release your mouse
>>> button.
>>>
>>> This is a "drag and
>>> drop", but should this be
>>> considered a "clicking"
>>> so that it still clear the
>>> selection?
>>>
>>> I suppose it should clear
>>> the selection. Anyone knows
>>> an official answer? Thanks!
>>>
>>> ________________________________________
>>> From:
>>> 68...@googlegroups.com
>>> <mailto:68...@googlegroups.com>
>>>

>>> <mailto:68...@googlegroups.com

>>> <mailto:68...@googlegroups.com>>
>>> [68...@googlegroups.com
>>> <mailto:68...@googlegroups.com>
>>>

>>> <mailto:68...@googlegroups.com

>>> <mailto:68...@googlegroups.com>>] On
>>> Behalf Of Steven
>>> Bartel [sba...@MIT.EDU
>>> <mailto:sba...@MIT.EDU>

>>> <mailto:sba...@MIT.EDU

>>> <mailto:sba...@MIT.EDU>>]
>>>
>>> Sent: Sunday, April 04,
>>> 2010 3:15 AM
>>> To: 68...@googlegroups.com
>>> <mailto:68...@googlegroups.com>

>>> <mailto:68...@googlegroups.com

>>> <mailto:zum...@gmail.com>><mailto:zum...@gmail.com

>>> <mailto:shw...@gmail.com>><mailto:shw...@gmail.com

>>> <mailto:veen...@mit.edu>><mailto:veen...@mit.edu

>>> <mailto:veen...@mit.edu>
>>>
>>> <mailto:veen...@mit.edu
>>> <mailto:veen...@mit.edu>>>> wrote:
>>> I think it's reasonable
>>> to say that once you aren't
>>> viewing the board it
>>> doesn't have a selection?
>>>
>>>
>>> On Thu, Apr 1, 2010 at
>>> 1:39 PM, Ted Tomlinson
>>> <zum...@gmail.com
>>> <mailto:zum...@gmail.com>
>>> <mailto:zum...@gmail.com

>>> <mailto:zum...@gmail.com>><mailto:zum...@gmail.com
>>> <mailto:zum...@gmail.com>
>>>
>>> <mailto:zum...@gmail.com

>>> <mailto:nih...@mit.edu>><mailto:nih...@mit.edu

>>> <mailto:r...@mit.edu>><mailto:r...@mit.edu

>>> <mailto:r...@mit.edu>
>>>
>>> <mailto:r...@mit.edu
>>> <mailto:r...@mit.edu>>>> wrote:
>>> No, a sprite is
>>> effectively a component with
>>> event-handling capability
>>> built-in. Part of the point
>>> of Problem 1,
>>> StrokeCheckerboard, is to learn how to
>>> write the input-handling
>>> code when you're drawing
>>> things yourself, not
>>> representing them as components.
>>>
>>>
>>> On Thu, Apr 1, 2010 at
>>> 11:04 AM, Ted Tomlinson
>>> <zum...@gmail.com
>>> <mailto:zum...@gmail.com>
>>> <mailto:zum...@gmail.com

>>> <mailto:zum...@gmail.com>><mailto:zum...@gmail.com
>>> <mailto:zum...@gmail.com>
>>>
>>> <mailto:zum...@gmail.com

>>> <mailto:zum...@gmail.com>>>> wrote:
>>> Are we allowed to use a
>>> sprite for the first part of
>>> the problem set for the
>>> checker as we are moving it?
>>> The sprite is still drawn
>>> with the graphics component
>>> in the spirit of the
>>> stroke model, but it is a child
>>> of the stage. Or do we
>>> have to do all of our drawing
>>> only on the checkerboard
>>> graphics component?
>>>
>>>
>>> On Thu, Apr 1, 2010 at
>>> 3:53 AM, Michael Bernstein
>>> <msbe...@mit.edu
>>> <mailto:msbe...@mit.edu>
>>> <mailto:msbe...@mit.edu

>>> <mailto:msbe...@mit.edu>><mailto:msbe...@mit.edu

>>> <mailto:nih...@mit.edu>><mailto:nih...@mit.edu
>>> <mailto:nih...@mit.edu>
>>>
>>> <mailto:nih...@mit.edu

> (916) 220-4326 | sean...@mit.edu <mailto:sean...@mit.edu>

>
>
>
>
> --
> Mr Olayemi A F Oyebode
>
>
>
>
> --
> Sean Liu
> Massachusetts Institute of Technology
> Department of Electrical Engineering & Computer Science '10

> (916) 220-4326 | sean...@mit.edu <mailto:sean...@mit.edu>

[Sean Liu (Gmail)]

Possibly not the best solution, but it's what I did.

Use component.x and component.y and calculate the row/col of the component.

Then use board.checkerAt(row, col).

[Wolfe Styke]

This occurs when you either try to move the checker to [3,15] or when you are checking if a checker exists in that square.  CheckIsValid is called in both cases, and sense this square is out of bounds, it throws an error.

You need to check the out-of-bounds property of the square before you check if there is a checker on it or try to move a checker to the square.

~ Wolfe Styke

[Fuming Shih]

I think you need to catch the exception and do something about it.

--
Fuming, Shih
Research Assistant ,
Decentralized Information Group,
CSAIL, MIT

[Wolfe Styke]

For Katherine Lin's problem, you can very easily check if the mouse click happens outside the board bounded by [0, board.size * PPS] in both directions, if it does, you know you're outside the board and you shouldn't ask whether there's a checker there (there shouldn't be) or try to board.move the checker to this location (off the board).  As long as you dont call any methods in board that check if the destination is a valid place for a checker, you wont get the exception.

~ Wolfe Styke

[Tobe Nwanna]

The solution I used was event.isButtonDown() (something like that, I can't remember). Anyway, I used this to check if the button is actually pressed when in my dragging method so if it isn't it just resets everything as if the checker was moved to an invalid space. If you check for this before anything else in that method it should do that right when the mouse re-enters a valid zone

[Alex Jiang]

I've had the same bug since last night, and I've tried debugging like
crazy, but I still can't figure it out. For pixel view, when I drag King
checkers, the regular checker stays in the original location while the
cursor drags the King checker. As soon as I release my mouse, the
checker in the original location disappears and the King checker is
selected in the destination square like what should happen. This also
happens on the first move after "New Game". If I drag normal checkers
(after the first move), everything works normally.

Did anyone have this error or knows how to fix it?
Thanks,
Alex

>> <mailto:msbe...@mit.edu
>> <mailto:msbe...@mit.edu>>> wrote:
>>
>> I would call it on the component's parent,
>> which you can get out
>> of the component. You can also ask the
>> component to tell you how
>> many children it has, which will be
>> helpful in getting it the
>> highest in the Z-order.
>> - Michael
>>
>>
>> On Sun, Apr 4, 2010 at 3:17 PM, Maria
>> Rodriguez <mar...@mit.edu
>> <mailto:mar...@mit.edu>

>> <mailto:mar...@mit.edu

>> <mailto:mar...@mit.edu>>> wrote:
>>
>> Anyone know how/where to use
>> addChildAt() to make the
>> component being dragged show up on
>> top? I want to put it
>> inside my pickUp method in
>> CheckerboardMoveInteractor, but I
>> don't know what to call
>> .addChildAt(checker,1) on...
>>
>> Thanks!
>> Maria
>>
>>
>> On Sun, Apr 4, 2010 at 2:51 PM,
>> Michael Bernstein
>> <msbe...@mit.edu
>> <mailto:msbe...@mit.edu>

>> <mailto:msbe...@mit.edu
>> <mailto:msbe...@mit.edu>>> wrote:
>>
>> Zhilei, I would think that it
>> would clear the selection. I'd
>> imagine that this makes things much easier to
>> implement, too.
>> - Michael
>>
>> On Sun, Apr 4, 2010 at 12:34 PM,
>> Zhilei Xu <ti...@mit.edu <mailto:ti...@mit.edu>

>> <mailto:ti...@mit.edu

>> <mailto:ti...@mit.edu>>> wrote:
>>
>> But the tricky things happen
>> when you press your mouse
>> button on an empty square,
>> then move a little bit, and
>> then release your mouse button.
>>
>> This is a "drag and drop", but
>> should this be
>> considered a "clicking" so
>> that it still clear the
>> selection?
>>
>> I suppose it should clear the
>> selection. Anyone knows
>> an official answer? Thanks!
>>
>> ________________________________________
>> From: 68...@googlegroups.com
>> <mailto:68...@googlegroups.com>

>> <mailto:68...@googlegroups.com

>> <mailto:68...@googlegroups.com>>
>> [68...@googlegroups.com
>> <mailto:68...@googlegroups.com>

>> <mailto:68...@googlegroups.com

>> <mailto:68...@googlegroups.com>>] On Behalf Of
>> Steven
>> Bartel [sba...@MIT.EDU
>> <mailto:sba...@MIT.EDU>

>> <mailto:sba...@MIT.EDU

>> <mailto:sba...@MIT.EDU>>]
>>
>> Sent: Sunday, April 04, 2010
>> 3:15 AM
>> To: 68...@googlegroups.com
>> <mailto:68...@googlegroups.com>

>> <mailto:68...@googlegroups.com

>> <mailto:zum...@gmail.com>><mailto:zum...@gmail.com

>> <mailto:shw...@gmail.com>><mailto:shw...@gmail.com

>> <mailto:veen...@mit.edu>><mailto:veen...@mit.edu

>> <mailto:veen...@mit.edu>
>>
>> <mailto:veen...@mit.edu
>> <mailto:veen...@mit.edu>>>> wrote:
>> I think it's reasonable to say
>> that once you aren't
>> viewing the board it doesn't
>> have a selection?
>>
>>
>> On Thu, Apr 1, 2010 at 1:39
>> PM, Ted Tomlinson
>> <zum...@gmail.com
>> <mailto:zum...@gmail.com>
>> <mailto:zum...@gmail.com

>> <mailto:zum...@gmail.com>><mailto:zum...@gmail.com
>> <mailto:zum...@gmail.com>
>>
>> <mailto:zum...@gmail.com

>> <mailto:nih...@mit.edu>><mailto:nih...@mit.edu

>> <mailto:r...@mit.edu>><mailto:r...@mit.edu

>> <mailto:r...@mit.edu>
>>
>> <mailto:r...@mit.edu
>> <mailto:r...@mit.edu>>>> wrote:
>> No, a sprite is effectively a
>> component with
>> event-handling capability
>> built-in. Part of the point
>> of Problem 1,
>> StrokeCheckerboard, is to learn how to
>> write the input-handling code
>> when you're drawing
>> things yourself, not
>> representing them as components.
>>
>>
>> On Thu, Apr 1, 2010 at 11:04
>> AM, Ted Tomlinson
>> <zum...@gmail.com
>> <mailto:zum...@gmail.com>
>> <mailto:zum...@gmail.com

>> <mailto:zum...@gmail.com>><mailto:zum...@gmail.com
>> <mailto:zum...@gmail.com>
>>
>> <mailto:zum...@gmail.com

>> <mailto:zum...@gmail.com>>>> wrote:
>> Are we allowed to use a sprite
>> for the first part of
>> the problem set for the
>> checker as we are moving it?
>> The sprite is still drawn with
>> the graphics component
>> in the spirit of the stroke
>> model, but it is a child
>> of the stage. Or do we have to
>> do all of our drawing
>> only on the checkerboard
>> graphics component?
>>
>>
>> On Thu, Apr 1, 2010 at 3:53
>> AM, Michael Bernstein
>> <msbe...@mit.edu
>> <mailto:msbe...@mit.edu>
>> <mailto:msbe...@mit.edu

>> <mailto:msbe...@mit.edu>><mailto:msbe...@mit.edu

>> <mailto:nih...@mit.edu>><mailto:nih...@mit.edu
>> <mailto:nih...@mit.edu>
>>
>> <mailto:nih...@mit.edu