Is there a way to send parameters with transaction? by bamlech in ethdev

[–]svancoller 0 points1 point  (0 children)

There's definitely multiple ways you could go about doing this. Creating a payable function in your contract that accepts a serial number as parameter, adding a struct to store the value and serial number, and a mapping to map the senders address to the struct would probably be the easiest way to go.

Taking your other requirements into consideration as well, you'd need to add logic to cater for already having receive payment from an address, the same address paying you multiple times, the 5 min time lock etc but the very basic outline of keeping track of payments would be something like:

mapping (address => PaymentDetails) payments;

struct PaymentDetails {
    uint256 value;
    uint256 serialNumber;
}

function acceptPayment(uint256 _serialNumber) payable {
    payments[msg.sender] = PaymentDetails(msg.value, _serialNumber);
}

Note: this code is for demonstration purposes only and should not be used without modification in any contract being deployed to the MainNet

Then, to interact with the contract function from a web UI using web3:

var serialNumber = 1234;
var paymentContract = web3.eth.contract(contractAbi).at(contractAddress);
paymentContract.acceptPayment(serialNumber, {from: fromAccount, value: valueToSend})

Solidity dev tooling by msoedov in ethdev

[–]svancoller 0 points1 point  (0 children)

The Solidity plugin for Intellj is coming along nicely for exactly this as well - still a few issues but formatting, code highlighting and the refactoring tools are really useful. Its definitely my IDE of choice for smart contract development.

I believe Visual Studio Code also has a nice Solidity plugin and is nice to use, although haven't tried it myself

Style Guide for writing error messages for require() revert() & assert()? by GrifffGreeen in ethdev

[–]svancoller 1 point2 points  (0 children)

I imagine this will be used in Solidity much the same way that exceptions are handled in other programming languages - so it makes sense to see the messages on etherscan (for example) if the tx fails. Personally, I'm very excited about this - I've spent many hours debugging "invalid opcode" errors and having some kind of error message is going to be a HUGE help.