создать новую тему раскрыть все
 
Я вот перехожу потихоньку на отказ от мыши где возможно.
Хотелось бы чтобы на диалоге внесения траты можно было передвигаться между полями горячими клавишами.
 
Что думаете?
 
 
Конечно таб никто не отменял, но все же было бы удобнее использовать один шорткат, чем пять раз нажать таб.
 
Плюс обход по табу сейчас слева направо, вверх-вниз. И до наиболее используемых полей приходится нажимать таб болльше раз чем хотелось. Хотя бы как минимум, поменять порядок обхода по таб, чтобы переходить в статьи и суммы за наименьшее число табов?
 
...что называется, "на свой вкус". Сделать это можно путем "перевода" программы вот таким образом:
 
1. На странице загрузки нужно загрузить образец локализации программы на свой компьютер.
 
2. Раскрываете скачанный архив, в нем найдете всего один файлик, в котором находятся все текстовые подписи программы. Там собраны все текстовые метки, которые вообще используются в программе.
 
3. Открываете файл перевода в любом текстовом редакторе и правите его. Правка заключается в том, что нужно найти строки, используемые на диалоге ввода операции и в этих строках нужно поставить символ амперсанда ( & ) перед теми символами, которые должны стать шорткатами.
 
Например, если Вам нужно, чтобы по нажатию шортката Alt+a курсор перескакивал на поле ввода суммы, то метку "Сумма:" надо будет поправить на "Сумм&а:".
 
4. Исправленный файл нужно положить в папку с самой программой и после этого из меню "Сервис" в подменю "Language" нужно выбрать исправленный файл. Перезапускать программу после этого не нужно, все должно подключиться "на лету", сразу же.
 
Надеюсь, это поможет.
 
Спасибо за подсказку
 
Рад буду, если кому поможет. Пишите, если у вас есть лучший вариант.
 
http://www.filefactory.com/file/b225c4d/n/RussianWithShortcuts.lng
 
Настроил клавиши, но фокус прыгает на радиобатоны возле сум в окне перевода. Есть ли возможность по грячей клавише прыгать в эдитбокс?
свернуть/развернуть ветвь Боюсь, ... [Dervish 23/06/2010 13:55] # написать ответ
 
... это невозможно. И вот почему:
 
Когда нажимается шоткат, Windows находит контрол, который должен перехватывать это событие. Если этот контрол обычная текстовая метка, фокус передается следующему контролу за меткой. А если контрол сам умеет что-то делать (как радиобаттон), то фокус передается этому контролу. Поэтому и происходит именно такое переключение как Вы описали. А когда идет ввод сумм в операциях прихода или расхода, то все работает правильно потому что радиобаттоны скрыты и фокус передается следующему контролу.
 
Для того, чтобы фокус прыгал правильно при вводе операций перевода, нужно либо радиобаттоны превратить в обычные метки (но тогда неясно как вообще построить логику работы), либо добавить дополнительные текстовые метки перед полями ввода (но тогда неясно зачем они нужны, никакой другой функции они нести не будут и смотреться все будет очень плохо).
 
Честно говоря, мне кажется, эти радиобаттоны там вообще лишние. Они только добавляют "мысленной работы" (какой радиобаттон надо кликнуть, чтобы ввести имеющиеся у меня данные? тем более, что выбирать надо не то значение, которое "у меня есть", а то, которого нету) и лишних кликов (одно из полей всегда не доступно для ввода, и если надо ввести именно его, то нужно кликнуть другой радиобаттон).
 
Мне кажется, было бы удобнее и проще, если бы были просто три поля, без всяких радиобаттонов. И при изменении значения в одном из них программа сама просто пересчитывала значение в том, которое менялось "позапрошлым".
 
Т.е. если, например, я ввожу:
- сначала "Курс" - оба других поля остаются 0.0, потому что данных не достаточно
- потом ввожу "Сумму списания" - AC тут же на лету считает, какой была бы "Сумма зачисления", исходя из курса и списания,и выводит это значение в соотв. поле (после нажатия каждой цифры в поле списания)
- а если я потом решу исправить и "Сумму списания" (потому что по факту у меня вышла другая, например, из-за того, что я опечатался в курсе или, скажем, комиссии), то теперь уже AC при вводе рассчитывает и корректирует "Курс" исходя из введённых списания и зачисления
(если потом снова начать исправлять значение "Курса", то по этому принципу ("два последних введённых значения - самые актуальные") уже должна пересчитываться "Сумма списания")
 
P.S. Чтобы сделать логику более прозрачной, можно, например, помечать какой-то иконкой поле, которое будет вычисляться автоматически (но не забирать возможность редактировать его!), когда фокус попадает в одно из этих трёх полей.
 
... я не считаю что реализация с радиобаттонами удачна. Они меня тоже раздражают и при вводе операции перевода в разных суммах мне тоже приходится на секунду "зависать" решая, где в них поставить отметку.
 
Я тут как-то делал один интерфейс, там нужно было вводить дату начала события, срок окончания и длину события. На форме было три поля. Первая мысль была замутить что-то аналогичное радиобаттонам, но потом я сделал по другому:
 
1. Если юзер изменяет дату начала, автоматический вслед за ней изменяется дата окончания, а поле длины остается неизменным: 1 день.
 
2. Если изменяется дата окончания, соответственно корректируется поле длины события, дата начала не изменяется.
 
3. Если правится длина события, то изменяется дата окончания события.
 
Такая реализация оказалась вполне удачной и не вызвала никаких вопросов у пользователей. Все было интуитивно понятно.
 
Поэтому у меня возникает желание сделать что-то подобное и при вводе сумм. Как вариант, реализовать то, что Вы предложили: править первое нулевое поле или, если нет нулевых полей, какое-то понятное (осталось решить, какое) поле.
 
Иконки рисовать не хотелось бы, боюсь, что это может запутать пользователя.
 
Мне кажется, такого удачного (простого и понятного) решения, как с датами и длительностью здесь не получится.
Там было вполне логично, что дата начала, скорее всего, "важнее" даты окончания - и можно было всегда сдвигать окончание при редактировании длины.
 
Здесь же обе суммы "равновесны" - в одной транзакции отталкиваешься от суммы списания, в другой - от суммы зачисления.
И потому, наверное, самым интуитивным будет именно корректировка "самого старого" поля - того из двух, которое вводили раньше.
 
В большинстве же случаев будет работать вариант с первым ненулевым полем. Тут и вопросов нет - просто, понятно и удобно.