I noticed that if I do two downloads in a row using:
setDisableOnClick(true); addDownloadFinishedListener(e -> setEnabled(true));
that often on the second download the button stays disabled (no download finished is fired). You can also do this if you click too fast. But even with very slow clicking it seems to happen after the second download very often. I also put a debug statement on the listener and the event is fired for each click.
Hi!
IIRC the event is fired outside of "event loop". You might need UI.access wrapping of your UI changes and Push/Polling enabled.
In my email notification I saw some other questions from you as well, but can't see them here in the discussion. Did those get resolved?
Thank you for responding. Although I wasn't able to find the answers I did come up with workarounds to everything but one issue which I pushed back so I pulled back the comments.
By ui.access do you mean:
addDownloadFinishedListener(e -> ui.access(() -> setEnabled(true)));
If so I tried that as well without success.
Checked the example in the project and there it doesn't seam to require UI.access. But having push communication on or polling during the download is required. Maybe this is what you are missing?
I tend to use Push always on my apps as it is needed often for many things and also makes apps bit faster as the TCP connection stays on.
I've too always tend to include push. And yes that was the example code I was using. Btw that example code was extremely helpful in discovering the capabilities of the addon. If it's ok with you I can create arepo in github to replicate the issue.
\u0000
\uD83D\uDC4D That would help a lot to investigate the issue!
Here's the link to the github repo: https://github.com/FollowSteph/download-test
Hi Stephan! Checked the example. There was a small mix with where the implicit "this" references. Here is the "solution":
https://github.com/FollowSteph/download-test/compare/master...mstahv:download-test:master
First good catch on the implicit this. Thank you, I missed that one. The polling also makes a difference. That being said if you click fast enough it still has the issue. Just not as frequently because it has to be slower than a doubleclick but faster than 1 second. Say maybe 300-500ms after the initial click. I could increase the polling speed further but I'm not sure that's a good idea... Either way in essence the polling speed has to be faster than the clicking speed is my understanding if they are doing more than one click. It can still lock but it requires a click in the windows between after a double click and before the polling value. Would that be a correct assessment?
The feature seems to be implemented with a server side API, so in theory the href property might be there for another click if one is very fast or the network is somehow slow. I added an additional client side logic. This change should be available in 2.5.3 soon (once Maven central is synchronised).
That's awesome. And if I may also add, you have a very nice plugin. The download feature had a lot of options that were especially useful and well thought out.