Contestants: When adding second contestant it overwrites the first one + more

[JonDemelo]

I believe the first bug is already known, but I believe this next thing is attached to it so I included it into the title:

When adding, if the new contestant's tribe is different from the previous add, it overwrite the previous. << this might be a symptom of the original overwrite issue. Aka, its messing up thinking there's one less contestant then their actually is? Just riffing. To setup this bug simply:

New Season >> Add first contestant >> Add second (should mess up and overwrite the first) >> add the rest until it seems to "stall" (aka overwrite every single time) at around MAX amount - 1 (i.e. if there should be 6 contestants, it'll stop one short at 5).

Additional Issues: Can add same contestant id more then once Can change old IDs (weren't you not allowed to change an id?)

[JonDemelo]

Check out line 76 of ContestantPanel.java This is the location of the "index" output message, which might signal the location of the -1 which seems to be resulting in these issues.

Furthermore, I was able to use the "add same contestant id" glitch to temporarily break past the MAX-1 overwrite issue, and can confirm that even if you to reach the required contestant numbers (at least visually), it'll let you start the season, but won't let you advance to the next week.

EDIT: I'm noticing the index System.out that someone has added seems to be pointing out an overall issue where the first row of the contestant table display is 0, which is correct, but then the row that should be 1 is also saying 0, and then onward up the number count. This could be (causing/the result of) some sort of initial storage error, thus not allowing proper saving/adding to continue, and in turn not allowing advancing weeks (due to the point allocation process breaking due to the improper contestant list). You can test this observation by adding whatever number of contestants you'd like, then merely clicking on a row of the contestant table. The message is being printed onClick.

[Nava2]

OK, to clarify:

The bug: When clicking add new, its saving the old, but not resetting the upper panel.

The overwrite is because its not updating the panel properly.

The index output is merely when you click on a row, but that is also output EVERYTIME a row gets selected, which happens a lot. You can ignore it, it won't help you :P

[Nava2]

Temp work around, just click Add New twice to add more, or click save first.

[JonDemelo]

Okay, so the pattern that Kev pointed out seems to hold true, in that it seems that after you add a contestant, even though it graphically looks like you are free to add the next contestant, it stays on the previous contestant and edits it.

Aka.

Enter Contestant 1 > Adds contestant 1 in first slot Enter Contestant 2 > Edits Contestant 1 with the new contestant 2 data Enter Contestant 3 > Adds Contestant 3 in the second slot Enter Contestant 4 > Edits Contesstant 3 with Contestant 4's data, etc.

I think addressing this issue might solve a few of the other issues.

[Nava2]

Let this go, there is no backend problem.

There is a bug, as I said, but it's a very small problem with how the events are triggered.

currently, the add new button programatically clicks the save button, then dies it's own thing. There is a bug in there, and no data is being overwritten. Dates is over written when the user doesn't notice it hasn't updated to be new information.

If you want to help with this, please do the status label we talked about in the meeting. Shows the user that they're editing. On Mar 21, 2012 12:48 PM, "Jon Demelo" < reply@reply.github.com> wrote:

hmm

if the admin hits the add new button, it's assuming that the person wants to create a totally new contestant with its own row. Right now it doesn't look like there's any ID check/comparison, so maybe if we check to see if the IDs are the same, then deny any change, otherwise, allow the new contestant to be added. This will be different then the "save" button, which if the id's are the same, you'd change the new data, and if it's not the same, you don't touch the data since the IDs can't be changed after creation.

---

Reply to this email directly or view it on GitHub:

https://github.com/CS2212-2012-G2/SurvivorPool/issues/49#issuecomment-4621585

[Nava2]

Correction, let the idea that this is backend go. Its definitely a problem, and definitely a problem with the GUI. I'll get to this when I can. :)

[JonDemelo]

Okay, so good news everyone. I found that the iterator was being called twice per loop within the allocation, blowing up the program every time "advance week" was called. It has been fixed, and all the shit seems to now all be under control for that issue. The whole add/save thing is still up in the air tho.

[Nava2]

I have no idea what you're talking about. On Mar 22, 2012 5:12 PM, "Jon Demelo" < reply@reply.github.com> wrote:

Okay, so good news everyone. I found that the iterator was being called twice per loop within the allocation, blowing up the program every time "advance week" was called. It has been fixed, and all the shit seems to now all be under control for that issue. The whole add/save thing is still up in the air tho.

---

Reply to this email directly or view it on GitHub:

https://github.com/CS2212-2012-G2/SurvivorPool/issues/49#issuecomment-4648493

[JonDemelo]

hmm, i must've edited the original post and removed one of the bugs. the original post use to also have a part about how it wouldn't "advance week", which at the time could've been related to our overall contestant issue. Turns out it wasn't, and it was instead just because the method was going through the iterator twice per loop.

I just posted this update here cause I thought it was still in the original post. Sorry

[Nava2]

No problem, just make a new issue. We have unlimited space. :)

And if its solved, no need to do it anyway! :D

[Nava2]

Closing this one instead, clean issue helps.

Use #57 from this point on.