search

EverGreenCoinDev / EverGreenCoin

EverGreenCoin Official Development Tree
https://www.evergreencoin.org
MIT License
20 stars 12 forks source link

Unlocking during sending tx puts the unlock button in an incorrect state #29

Closed EverGreenCoinDev closed 6 years ago

EverGreenCoinDev commented 6 years ago

If a wallet is locked and a send is attempted, you must enter the password to unlock. This unlocks only for that transaction and then is re-locked automatically. The unlock triggers the "lock / unlock" button on the overview to switch to lock. The transaction-following automatic re-lock does not signal the "lock / unlock" button on the overview to switch to "unlock". This leaves the "lock / unlock" button in a misleading state of "lock your EverGreenCoin" while the wallet is in fact again locked already. Clicking it will prompt for a password as expected, since it is truly locked. But the text on the button needs to reflect the true status after a locked wallet send or not be effected by a locked wallet send / brief unlock / sign tx / quick auto re-lock.

arfonzocoward commented 6 years ago

Perhaps we could wrap both lock/unlock steps in a single function and call that whenever we lock/unlock?

Other use event handlers to listen for the lock/unlock event and ensure both backend and UI elements trigger their respective actions whenever a lock/unlock occurs.

EverGreenCoinDev commented 6 years ago

At a daemon level, it already is one function for either lock or unlock. At a daemon level it is only unlocked and locked in one way also, that being RPC. However; the Qt does have more situations to lock, unlock, and even relock. Those and also RPC from the debug console.

That said, you are correct in the approach you mention of signaling. I do have this now working, and yes for RPC also, and will be committing it tonight after I cleanup the code from my notes/comments, debugging, and failed attempts.

Thanks for the push in the right direction, matey!