-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
EXIT button cannot work in non-blocking mode #1353
Comments
I guess the question should be, should it work ? Do we want it to ? Or should it be fixed to allow code to decide what to do via a callout maybe ? hmm |
An EXIT button should work the same way in blocking and non-blocking mode, right? /**
|
I mean do you always want to allow an end user to stop portal? |
I think, you miss the point: there is an "EXIT" button automatically presented in the portal. And therefore it should work exactly like an end user expects it to. Needless to say, after 2-3 days learning curve, the WiFiManager does exactly what I need for my application:
Thanks for this very good project! |
The menu is customizable, if we let the user add an exit buton say for ondemand use, then we might have to also add security so someone cannot force it to exit when its not allowed. thanks for the use case, I agree but might add something extra for this for example there is also a close item |
ALL I do configure is this: void wifiman_setup() { |
Yes i know sorry, I meant changes going forward and fixing this its already marked as bug, I will have a fix today |
lol in the code
|
didn't see that, though I had added a printf there to see whether its called at all ;) |
Basic Infos
Hardware
WiFimanager Branch/Release: Master
The EXIT button in the Portal does not work in non blocking mode, because:
void WiFiManager::handleExit() faithfully sets "abort = true",
but "abort" is only checked in the while(1) loop in blocking mode
if one uses non blocking mode it is not checked and there is no method to read this private variable.
I believe it should be handled in the "boolean WiFiManager::process()" function in a similar way it is handled while in blocking mode?
I will try to do that :)
The text was updated successfully, but these errors were encountered: