Enhanced Darkcoin Wallet UI

[AjM]

In the "Amount and Rounds" section, actually we need all 8 decimals place holdings now because it can show the exact amount to be in the mixing. For instance, if I put in settings 1000/ 8 rounds, but I have less than 1000 DASH, it automatically adjusts the number for me, it's a quite nice change in v.12:

View attachment 1473

It is amount setting info, why we need 6 or 8 decimal for that?
Its looks so silly 10.12345678 tDASH, i like old 2 decimal better 10.12 tDASH or without decimals 10 tDASH.

 

[moli]

It is amount setting info, why we need 6 or 8 decimal for that?
Its looks so silly 10.12345678 tDASH, i like old 2 decimal better 10.12 tDASH or without decimals 10 tDASH.

I don't know. Maybe someday Dash will be valued at 5000 USD and 0.00065897 DASH will still be worth enough to buy two movie tickets at the One-Dollar Theater for you and your gf without your wife knowing about it? :grin:

Edit: Joking, ofc.

 

[crowning]

I don't know. Maybe someday Dash will be valued at 5000 USD and 0.00065897 DASH will still be worth enough to buy two movie tickets

Those were my first thoughts as well, mainly because having less digits would make the UI-layout way simpler.

On the other hand, you could easily switch the units to "duffs" in this case...I'll think about this and its implications.

 

[AjM]

Those were my first thoughts as well, mainly because having less digits would make the UI-layout way simpler.

On the other hand, you could easily switch the units to "duffs" in this case...I'll think about this and its implications.

Well, it is mixing settings info, not your wallet balance.

 

[moli]

Wallet repair button -zapwallettxes does not work on windows 32-bit (actually v.12.0.3, but I will test again on v.12.0.4). It froze and crashed my wallet (tested 3 times). I had to zap my wallet the old-fashioned way.

Edit: crowning -I think I found the reason why my wallet crashed when using -zapwalletxes from "Wallet Repair" button. I think because I had "-listen=0" in the shortcut Target and that caused it. I just did this on another wallet after removing "-listen=0" and it worked.

AjM - Maybe you also had the same thing in your shortcut?

 

[AjM]

Wallet repair button -zapwallettxes does not work on windows 32-bit (actually v.12.0.3, but I will test again on v.12.0.4). It froze and crashed my wallet (tested 3 times). I had to zap my wallet the old-fashioned way.

View attachment 1487

Welcome to the team 'random crash' :smile:, https://dashtalk.org/threads/enhanced-darkcoin-wallet-ui.1705/page-23#post-56280
Its known random event, no known reason yet.

 

[crowning]

Welcome to the team 'random crash' :smile:, https://dashtalk.org/threads/enhanced-darkcoin-wallet-ui.1705/page-23#post-56280
Its known random event, no known reason yet.

I've never been able to reproduce this problem, however I'll make a version with a ton of debugging output next weekend to track this one down.

moli , if your issue should happen again, could you please save the debug.log of the last failed attempt together with the successful "old-fashioned" attempt so I can compare both?

 

[moli]

I've never been able to reproduce this problem, however I'll make a version with a ton of debugging output next weekend to track this one down.

moli , if your issue should happen again, could you please save the debug.log of the last failed attempt together with the successful "old-fashioned" attempt so I can compare both?

Sure, will do.

 

[UdjinM6]

crowning that could be it https://github.com/dashpay/dash/pull/381
I had crashes on restart before too but not so often, can't reproduce any with that patch now yet

 

[crowning]

crowning that could be it https://github.com/dashpay/dash/pull/381
I had crashes on restart before too but not so often, can't reproduce any with that patch now yet

This could very well be the cause for the problem...I remember that my first implementation of "restarting the wallet from within the wallet itself" caused some boost::filesystem errors which disappeared when I found the correct order to de-instantiate objects.

Sometimes is nice to be a Bitcoin offspring...you get fixes for free and can enjoy the weekend with your honey instead of the debugger :grin:

 

[Coinease]

Hi there :smile:

"n/a" - means that wallet was not able to identify a single address to associate with that transaction (if you have "change" there for example both addresses will be yours). And as a result wallet can't decide which address to display/copy. There are some situations when it's still possible but I believe it was made "n/a" for every "Sent to yourself" to keep things consistent.

What "any available funds" actually means is that you are using non-mixied funds so you should treat your transaction as "usual" / "bitcoin-like" transaction i.e. with privacy lower than you could get if you used only mixed funds instead. Yep, I agree, that could be a bit misleading/confusing when someone is using coin control. Ideas how to say it better are welcome :smile:

Thanks for the explanation, I doubt I can say it better without complicating everything

 

[AjM]

This could very well be the cause for the problem...I remember that my first implementation of "restarting the wallet from within the wallet itself" caused some boost::filesystem errors which disappeared when I found the correct order to de-instantiate objects.

Testing v.12.0.6.

I found this: repairing causing crash quite easy IF your wallet is mixing and/or mining.

 

[crowning]

Testing v.12.0.6.

I found this: repairing causing crash quite easy IF your wallet is mixing and/or mining.

At least under Linux (no time to build a Windows wallet right now) I'm absolutely not able to reproduce this...I mined and mixed hundreds of Dash and restarted the wallet all the time, no crash

What version + OS are you using? Which options do you have in your dash.conf?
Does it crash during shutdown or during the (re-) start?
Does the wallet also crash when you exit it the normal way while you mine/mix?

Before I start the tedious task to stop mixing and mining before I restart the wallet: eduffield / UdjinM6 , would it be sufficient to just add a warning to the text of the wallet-repair tab?

 

[AjM]

At least under Linux (no time to build a Windows wallet right now) I'm absolutely not able to reproduce this...I mined and mixed hundreds of Dash and restarted the wallet all the time, no crash

What version + OS are you using? Which options do you have in your dash.conf?
Does it crash during shutdown or during the (re-) start?
Does the wallet also crash when you exit it the normal way while you mine/mix?

> What version + OS are you using? Which options do you have in your dash.conf?
- Dash v.12.0.6.
- Windows 7 x64.
- dash.conf is empty, but shotrcut have: -datadir=F:\Dash_testing -testnet.

> Does it crash during shutdown or during the (re-) start?
- Almost immediately when i click repair button.

> Does the wallet also crash when you exit it the normal way while you mine/mix?
- No, exit is clean, tested this 3 times.

Just tested 5 times, mixing and mining ON, 3 crashes when i clicked recover 1 or 2 or rebuild index.

 

[AjM]

Before I start the tedious task to stop mixing and mining before I restart the wallet: eduffield / UdjinM6 , would it be sufficient to just add a warning to the text of the wallet-repair tab?

If you want to do it easy, you can disable repair tab IF mining or mixing is active, and give user info box also.

 

[UdjinM6]

Before I start the tedious task to stop mixing and mining before I restart the wallet: eduffield / UdjinM6 , would it be sufficient to just add a warning to the text of the wallet-repair tab?

I would love to know the root before applying the fix and I'm not quite sure if it's mixing or mining yet - at least mining should stop properly imo as it's built-in. But for the sake of simplicity we can implement "stop mixing, wait 1 sec, restart" method here. This way wallet will have some additional time to cleanup and it should also take care of all other crash cases we might not even know of yet :grin:

EDIT: However it will not help if crash happens not because of wallet restart but because of wallet shutdown and in case we do it improperly. So I would still stick with "know the root first patch where it's needed later".

 

[moli]

I've also done some testing on the Repair Wallet buttons in v.12.0.06 (windows 32bit.) It seems very confusing..

- First round of testing: wallet not running DS or mining, using -zap #1 button, wallet did not crash. Same button with DS and mining, wallet crashed.
- Second round of testing: I deleted Dash-qt Testnet folder in the registry, tested wallet with rescan, reindex, zap#1 buttons, running or not running DS/mining: wallet crashed.
- Third round of testing: I deleted the whole Dash folder in registry (Dash-qt and Dash-qt Testnet). Repeated the same testing like in second round, the wallet crashed also.

Now I'm not sure if deleting the registry can help. Maybe not. Something in the complicated design of windows is screwed up or not connected well to the repair buttons. One thing for sure: if a wallet is not running DS or mining, yet gets crashed by the repair buttons, then for sure it will crash while running DS or mining... And most of the times the error screen looks like this:

 

[AjM]

I've also done some testing on the Repair Wallet buttons in v.12.0.06 (windows 32bit.) It seems very confusing..

- First round of testing: wallet not running DS or mining, using -zap #1 button, wallet did not crash. Same button with DS and mining, wallet crashed.
- Second round of testing: I deleted Dash-qt Testnet folder in the registry, tested wallet with rescan, reindex, zap#1 buttons, running or not running DS/mining: wallet crashed.
- Third round of testing: I deleted the whole Dash folder in registry (Dash-qt and Dash-qt Testnet). Repeated the same testing like in second round, the wallet crashed also.

Now I'm not sure if deleting the registry can help. Maybe not. Something in the complicated design of windows is screwed up or not connected well to the repair buttons. One thing for sure: if a wallet is not running DS or mining, yet gets crashed by the repair buttons, then for sure it will crash while running DS or mining... And most of the times the error screen looks like this:

View attachment 1539

Agree, in short, it mostly feels random, and crash always occur with in exit, no start phase.

 

[moli]

Another test I've done is when I have more than one wallet running at the same time, then it's reasonable that windows would not allow the repair buttons to work. But sometimes when I'm running only one wallet with no "-listen=0" in the shortcut Target, I still get an error that sounds like windows thinks there's another Dash instance is running, or I'm not understanding the message, but it's like this: (I was running DS and then tested the -zap#1 button and it gave this error)

EDIT: From debug.log:

"2015-06-29 18:22:57 CMasternodePayments::AddWinningMasternode - checkhash
2015-06-29 18:22:57 CMasternodePayments::AddWinningMasternode - AddPayee - 1
2015-06-29 18:23:17 opencon thread interrupt
2015-06-29 18:23:17 msghand thread interrupt
2015-06-29 18:23:17 addcon thread interrupt
2015-06-29 18:23:17 dumpaddr thread stop
2015-06-29 18:23:17 net thread interrupt
2015-06-29 18:23:17 PrepareShutdown: In progress...
2015-06-29 18:23:17 StopNode()
2015-06-29 18:23:17 UPNP_DeletePortMapping() returned : 0
2015-06-29 18:23:17 upnp thread interrupt
2015-06-29 18:23:17 Verifying mncache.dat format...
2015-06-29 18:23:17 Loaded info from mncache.dat 15ms
2015-06-29 18:23:17 Masternodes: 101, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 3, entries in Masternode list we asked for: 18, nDsqCount: 117
2015-06-29 18:23:17 Writting info to mncache.dat...
2015-06-29 18:23:17 Written info to mncache.dat 0ms
2015-06-29 18:23:17 Masternodes: 101, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 3, entries in Masternode list we asked for: 19, nDsqCount: 126
2015-06-29 18:23:17 Masternode dump finished 15ms
2015-06-29 18:23:17 Verifying budget.dat format...
2015-06-29 18:23:17 Loaded info from budget.dat 0ms
2015-06-29 18:23:17 not implemented
2015-06-29 18:23:17 Writting info to budget.dat...
2015-06-29 18:23:17 Written info to budget.dat 0ms
2015-06-29 18:23:17 Budget dump finished 0ms
2015-06-29 18:23:17 Verifying coinbase-payee.dat format...
2015-06-29 18:23:17 Loaded info from coinbase-payee.dat 31ms
2015-06-29 18:23:17 16294 objects
2015-06-29 18:23:17 Writting info to coinbase-payee.dat...
2015-06-29 18:23:17 Written info to coinbase-payee.dat 16ms
2015-06-29 18:23:17 Coinbase payee dump finished 63ms
2015-06-29 18:23:21 AppInit2 : parameter interaction: -zapwallettxes=<mode> -> setting -rescan=1
2015-06-29 18:23:21 GUI: "registerShutdownBlockReason: Successfully registered: Dash Core didn't yet exit safely..."
2015-06-29 18:23:32 GUI: void QWindowsClipboard:ropagateClipboardMessage(UINT, WPARAM, LPARAM) const: Cowardly refusing to send clipboard message to hung application...
2015-06-29 18:23:46 GUI: void QWindowsClipboard:ropagateClipboardMessage(UINT, WPARAM, LPARAM) const: Cowardly refusing to send clipboard message to hung application...
2015-06-29 18:29:01 GUI: void QWindowsClipboard:ropagateClipboardMessage(UINT, WPARAM, LPARAM) const: Cowardly refusing to send clipboard message to hung application...
2015-06-29 18:32:11 PrepareShutdown: In progress...
2015-06-29 18:32:11 StopNode()
2015-06-29 18:32:11 Verifying mncache.dat format...
GUI: "registerShutdownBlockReason: Successfully registered: Dash Core didn't yet exit safely..."
2015-06-29 18:32:34 "

 

[AjM]

Another test I've done is when I have more than one wallet running at the same time, then it's reasonable that windows would not allow the repair buttons to work. But sometimes when I'm running only one wallet with no "-listen=0" in the shortcut Target, I still get an error that sounds like windows thinks there's another Dash instance is running, or I'm not understanding the message but it's like this: (I was running DS and then tested the -zap#1 button and it gave this error)

View attachment 1541

Thats because some times repair manage start a wallet again, but crashed wallet is still in live.