Честно говоря, мне кажется, эти радиобаттоны там вообще лишние. Они только добавляют "мысленной работы" (какой радиобаттон надо кликнуть, чтобы ввести имеющиеся у меня данные? тем более, что выбирать надо не то значение, которое "у меня есть", а то, которого нету) и лишних кликов (одно из полей всегда не доступно для ввода, и если надо ввести именно его, то нужно кликнуть другой радиобаттон).
Мне кажется, было бы удобнее и проще, если бы были просто три поля, без всяких радиобаттонов. И при изменении значения в одном из них программа сама просто пересчитывала значение в том, которое менялось "позапрошлым".
Т.е. если, например, я ввожу:
- сначала "Курс" - оба других поля остаются 0.0, потому что данных не достаточно
- потом ввожу "Сумму списания" - AC тут же на лету считает, какой была бы "Сумма зачисления", исходя из курса и списания, и выводит это значение в соотв. поле (после нажатия каждой цифры в поле списания)
- а если я потом решу исправить и "Сумму списания" (потому что по факту у меня вышла другая, например, из-за того, что я опечатался в курсе или, скажем, комиссии), то теперь уже AC при вводе рассчитывает и корректирует "Курс" исходя из введённых списания и зачисления
(если потом снова начать исправлять значение "Курса", то по этому принципу ("два последних введённых значения - самые актуальные") уже должна пересчитываться "Сумма списания")
P.S. Чтобы сделать логику более прозрачной, можно, например, помечать какой-то иконкой поле, которое будет вычисляться автоматически (но не забирать возможность редактировать его!), когда фокус попадает в одно из этих трёх полей.
... я не считаю что реализация с радиобаттонами удачна. Они меня тоже раздражают и при вводе операции перевода в разных суммах мне тоже приходится на секунду "зависать" решая, где в них поставить отметку.
Я тут как-то делал один интерфейс, там нужно было вводить дату начала события, срок окончания и длину события. На форме было три поля. Первая мысль была замутить что-то аналогичное радиобаттонам, но потом я сделал по другому:
1. Если юзер изменяет дату начала, автоматический вслед за ней изменяется дата окончания, а поле длины остается неизменным: 1 день.
2. Если изменяется дата окончания, соответственно корректируется поле длины события, дата начала не изменяется.
3. Если правится длина события, то изменяется дата окончания события.
Такая реализация оказалась вполне удачной и не вызвала никаких вопросов у пользователей. Все было интуитивно понятно.
Поэтому у меня возникает желание сделать что-то подобное и при вводе сумм. Как вариант, реализовать то, что Вы предложили: править первое нулевое поле или, если нет нулевых полей, какое-то понятное (осталось решить, какое) поле.
Иконки рисовать не хотелось бы, боюсь, что это может запутать пользователя.
Мне кажется, такого удачного (простого и понятного) решения, как с датами и длительностью здесь не получится.
Там было вполне логично, что дата начала, скорее всего, "важнее" даты окончания - и можно было всегда сдвигать окончание при редактировании длины.
Здесь же обе суммы "равновесны" - в одной транзакции отталкиваешься от суммы списания, в другой - от суммы зачисления.
И потому, наверное, самым интуитивным будет именно корректировка "самого старого" поля - того из двух, которое вводили раньше.
В большинстве же случаев будет работать вариант с первым ненулевым полем. Тут и вопросов нет - просто, понятно и удобно.
