-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
table hack failing #222
Comments
actually, it also looks like the mappings between keys and their labels is being lost. in the example above, the field |
I found what was causing my problem. I was looking for the row and column of a particular value in the table outside of the event thread and then selecting that row (within the event thread) - many times very quickly and occasionally this problem would occur. Definitely some non-deterministic threading voodoo. I don't mind your |
This issue is being caused by the use of I think the easiest solution is to replace the use of |
I have a case where the table hack here is failing:
https://github.com/daveray/seesaw/blob/master/src/seesaw/table.clj#L71-L72
somehow, the mapping is lost causing this to execute:
https://github.com/daveray/seesaw/blob/master/src/seesaw/table.clj#L97-L102
so, in my case, when the hack is working, it looks like:
and when it fails, it gets recreated looking like:
I'm not sure what is causing my problem, but the fact that the
ArrayIndexOutOfBoundsException
is caught and a workaround is implemented indicates the hack doesn't always work.I'm trying to figure out the best way of fixing this problem, perhaps with
meta
and implementingIObj
to store the col-key mapping, but your comment here makes me think you had a definite idea of how it could be improved.In theory, if I manually juggle the row key normalisation outside of seesaw and just use string keys, then even when the hack fails and is replaced with the bad mapping, it should still continue to work.
The text was updated successfully, but these errors were encountered: