Quote from: BitKoot on June 02, 2014, 06:56:22 PM

Quote from: QuadraQ on June 02, 2014, 01:09:34 AM

Actually no, but so far all of my attempts to send monero using your GUI have failed. If I leave the payment ID blank it gives me the error message that the Payment ID is in the wrong format. If I fill it in, then it tells me the payment address is invalid.

I'm sorry to hear you are having problems with my wallet. I have test the sending and receiving of coins with my wallet with and without payment id. They both still seem to work ok. Could it be there is a space somewhere in your destination address or in the payment id textbox?

Quote from: Jojatekok on June 02, 2014, 12:37:19 PM

EDIT: Look what I have for today! Wink

Looking good!

I see you also have a 'spend/received' column. I just noticed in my own wallet this might be wrong. I had test wallets where the amount of spend and received combined dit not add up to the actual balance. When executing the 'incoming_transfers' command at the command line, with the 'available' or 'unavailable' argument you'll see you get the transactions of type 'F' or 'T' respectivly. I don't think the types correspond to received and spend. I changed the type column to 'Availablity'.

Maybe someone else knows the relation between availablity, the 'T' and 'F' type transactions and spending and receiving coins?

A minor update of my wallet:
- Wallet update status is shown in status bar (just like updating the blockchain, updating the wallet can take some time)
- Transaction grid now adds new transaction instead of clearing the whole grid every time it refreshes
- Changed spend/received to unavailable/available

Thank you for notifying me, I'll surely have a look at this. But the incoming transaction parser should work perfectly. On a side note, I have noticed that a new cmd wallet is in the works on the base repository, ByteCoin. I hope that will fix those issues. I'm also curious about what the 1-4 digit number (some kind of index if I recall correctly - I'm writing these lines from mobile) means at the initial loading of transactions...

They should obviously be changed to block heights, as they would be easier to query from the RPC API than TX IDs. As you can see, I have already reduced the amount of commands given out by the wallet, and the refreshing cycle starts only after the daemon has synchronized with the network (so it isn't busy), see the RpcInitialized event of API/ProcessManagers/DaemonManager. I will be able to get transaction dates when I implement basic RPC support, which is easy to do (based on the concept of my MintPal API implementation.

https://github.com/Jojatekok/monero-client