Shouldn't this work? I am unsure of the exact use case and why you need

[bphudson1984]

the two description variables.

It seemed the only difference was that your isChanged variable but that
doesnt seem to be used anywhere!

Either way there is a tonne of nuts stuff going on here and I will go
through and rewite it as prod code and you can use it as a reference.

By the way. I have not executed this code so don't know if it is functionally equivilent. (I can't build as you use a 3rd party JSON library I couldn't be bothered to download yet)

bh

[jebbster88]

Cheers.

Idea is to have a form, with controls bound to each field in a taskItem. With a Save and a Cancel button. Cancel would need to revert the values back to their original state, Save would write the changes back to the third party tool (a different command for each field).

E.g: "task.exe " + task.uuid + " mod description:" + task.description
See: https://taskwarrior.org/docs/syntax.html#cmd

I wanted to bind the controls directly to the taskItem, hence wanting to track old/new values.

Maybe I'm better off binding the controls to a clone of taskItem, then discarding on cancel, and comparing the original object to the changed object to determine what values need writing back?

[bphudson1984]

Yes, the approach you have suggested is the correct one. It is a bad idea to complicate what is essentially just a Model class.

The idea of storing a list of tasks would work well, another option would be to use a the command pattern to give you proper undo/redo (this may be tricky as you are using direct binding though).

As a more direct answer to your question about having to repeat that property code repeatedly, you may be able to get less verbose code using the Null Coalescence (??) operator.

Alternatively get yourself a Resharper license and make a template. (You would type something like TTProp and it would place a template and you just fill in the blanks. You should get resharper anyway as it will help you learn to write c#