logo
logo

Форум Мелочи

создать новую тему раскрыть все
Мелочи Дим(м) 26/02/2004 16:57 #написать ответ
Сюда предлагаю постить различные некритичные мелкие доработки которые могут улучшить "доведенность" программы.
Например, такие:
 
1. При создании квалификатора его название пишется с большой буквы - чтобы закладки были похожими на стандартные. А вот уже в иерархии конкретного квалификатора хотелось бы видеть "Все статьи расхода" вместо "Все Статьи расхода". Может, стоит там приводить название к нижнему регистру? Точнее, делать маленькой первую букву, если в слове только она одна большая.
 
2. Есть небольшая несогласованность полей в статусной строке. Поле "Операций" отображает общее количество операций на странице, а поля "Приход"/"Расход" - суммы для выбранных. Мне кажется, стоит сделать, чтобы и "Операций" показывало сколько сейчас операций выделено. Чтобы выходило: "Приход от вот этих 123 операций составил 456". Как считаете?
 
Dervish: В мелочах дьявол. Вот с такими мелочами нужно бороться, поэтому я двумя руками "за"!
 
1. Решаемо. И я, кстати, уже обращал на это внимание. Исправляется относительно просто.
 
2. Вообще, я думал, что статус-бар, точнее его возможности и настройки вызовут критику и пожелания, а то, что сделано сейчас, я рассматривал как первую "пристрелочную" версию. Я готов дорабатывать его, но мне хотелось бы, чтобы сформировалось цельное видение его возможностей. Уже было предложение сделать так, чтобы в нём можно было показывать сумму прихода и расхода для всех операций, а не только выделенных. Может быть мы объединим все предложения по статус-бару, я готов существенно переработать его настройки и возможности, но желательно делать это один раз и так, чтобы больше к нему не возвращаться.
 
Может быть сделать в статус-баре настройку через диалог, а не через контекстное меню? Может быть будут предложения по самому меню, что в него включить, что из него убрать? Очень хочется увидеть действительно гармоничное решение по статус-бару.
Статус-бар Artem Fedorov 27/02/2004 09:29 #написать ответ
Краткие мысли по статус-бару:
1) Настройка как в экселе (через контекстное меню), выбираем постоянно показывать один из показателей
2) При наведении мышки в тултипе показывать все остальные показатели (?)
 
Dervish:
1. Так и сделано. Неудобство в том, что иногда для настройки поля статус-бара приходится несколько раз вызывать контекстное меню. Неудобно. Можно сделать отдельный диалог, но будет ли это хорошо? Не знаю.
 
2. Очень сложно, да и, думаю, не нужно.
это же один раз Ed 27/02/2004 16:52 #написать ответ
Статус же настраивается не каждый день. Можно и так - ничего в этом страшного нет. А вот есть ли смысл показывать в статусе то же, что и так видно в самой операции - а именно ее сумму? Статус как раз нужен для отображения итоговой инфомации. Если взять тот же ексель - когда стоишь на одной ячейке статус-бар пустой. Показывает только после выделения нескольких ячеек. Вот я и предлагаю (извините за повторение) считать все обороты, если ничего не выделено, и обороты по определенным операциям, если выделено две и больше
 
Dervish: Один вариант, когда ничего не показывается, другой вариант, когда показывается некая сумма, которая никак не связана с суммой одной единственной выбранной операции. Будут вопросы.
Мысль по статус-бару Draco 04/03/2004 01:14 #написать ответ
Мысль возникла, глядючи на винамп. Инфу оформить в таком виде: Операций 30(7), Приход 2000(245), расход 1000(123). Т.е. перед скобками цифры для всех отображённых операций, в скобках -- для выделенных. Ну или наоборот...
 
И ещё пожелание вдогонку. В выпадающих списках при раскрытии ветви дерева хотелось бы, чтобы оно скроллировалось вверх так, чтобы открывшиеся элементы сразу были видны. А то сейчас проматываю вниз, открываю ветку, проматываю вниз, открываю ветку, проматываю вниз...
 
А вообще программа классная. Спасибо!
 
Dervish: Про оформление "инфы": приведённый пример просто замечательно подходит для итогов, в которых нужно показывать количество, но не суммы. Представьте: в некоторых момент времени у вас показывается сумма 50.00, а потом вы дополнительно выделяете операцию, скажем, в сотни тысяч... Представляете, как у вас будут "прыгать" суммы? Ведь поле в статус-баре подстраивается под нужный размер суммы, а правые поля сдвигаются...
 
Скролирование можно сделать, меня только смущает, не будет ли это смущать пользователя тем, что списки будут "прыгать"? Впрочем, всё равно это можно будет делать только после того, как я доделаю экспорт/импорт.
 
И ещё: такое поведение списков (автоскроллирование) нужно только для выпадающих списков или для всех? (Например, список статей или список операций, если установлена группировка)
статус-окно Ed 04/03/2004 10:56 #написать ответ
Альтернативный вариант, но тоже выходящий за рамки идеологии программы (помню, вы когда-то специально писали про такую организацию рабочих окон) - сделать статусное окно. Чтобы оно либо болталось поверх окон программы либо выделить область не внизу, а сбоку.
Но еще я думаю, что все эти просьбы по статусу скорее вызваны отсутствием отчетов. И скажите по секрету :-) - настраиваемые отчеты планируются? Потому как возможности программы и возможные ее применения, ИМХО, выходят за рамки домашней бухгалтерии
 
Dervish: Я экспериментировал с "плавающими" окнами. Результаты экспериментов мне, честно говоря не понравились: неудобно. Область сбоку будет занимать довольно много места, причём не всегда рационально, так что этот вариант я пока тоже не рассматриваю.
 
По отчётам... Крутится у меня одна мысль: реализовать отчёты на HTML. Программа будет просто брать странички с диска (а на диск их может положить любой пользователь), загружать их и показывать. А для того, чтобы отчёты содержали информацию из базы, сделать доступ к данным из JavaScript, который будет выбирать нужную информацию и форматировать её в отчёте как нравится вам.
 
Плюсы такого подхода очевидны: любой человек сможет сделать такой отчёт, который нужен ему и оформить его в соответствии со своими вкусами и задачами, которые перед ним стоят.
 
Но есть и минусы: для подготовки отчёта (для создания страницы отчёта) нужно знать JavaScript, HTML и объекты программы, которые доступны из скрипта. Впрочем, готовится отчёт всего один раз, потом будет только вызываться. Кстати, можно будет на сайте сделать отдельный раздел, где можно будет размещать готовые отчёты. А самые удачные могут войти в дистрибутив программы.
 
Прошу вас, не воспринимайте мои слова как обещание, тут ещё много спорного. И работы немало: возможно придётся переделать существующие контролы программы в ActiveX, чтобы их можно было бы разметить прямо на самом отчёте. А такая переделка очень непроста. Кроме того, хотелось бы, чтобы была возможность встроить в отчёт графики, генерируемые программой...
 
В общем, планов громадьё, а вопрос пока открыт.
Статус-бар + автоскроллинг Draco 04/03/2004 14:21 #написать ответ
По статус-бару. Если заранее зарезервировать место под максимальный размер суммы (в принципе, как это сделано сейчас), то ничего прыгать не будет.
 
По скроллингу. Реализацию с автоскроллингом дерева я где-то видел, вот только не помню где; но мне она тогда очень понравилась. Ведь если я раскрываю ветвь дерева, то я определённо собираюсь выбрать какой-то элемент именно из этой ветви. Ну или хотя бы посмотреть, что там. В такой ситуации наиболее логичным будет, если вся ветка будет видна сразу. Это касается всех окон, а не только выпадающих списков.
 
Кстати, глюк. Поставил группировку по дате, потом изменил дату у одной операции. Операция осталась в той же ветке под "старой" датой.
 
Dervish: По статусу: сейчас не резервируется место, там немного другой алгоритм. Поле динамически расширяется, но не сужается.
 
Автоскроллинг: это возможно.
 
Глюк: просто не успел доделать, будет реализовано.
Счета Ed 02/03/2004 11:49 #написать ответ
На листе Счета поле "Показывать остатки по состоянию за" лучше писать "... по состоянию на"
И (там же) желательно сохранять состояние, в котором развернуты ветви деревьев, если можно
 
Dervish: "Показывать остатки на" означает "на начало дня", а нас более интересует цифра на конец дня, то есть за день. Потому там и стоит "за". )
 
Сохранять развёрнутостьветвей очень непросто: надо учитывать, что дерево может само по себе измениться. Появятся новые ветви и всё такое...
было - полтора года назад Explorer 02/03/2004 17:16 #написать ответ
причем практически слово в слово
 
Dervish: Да, я помню, что такой вопрос был. И помню, что ответил на него точно так же.
сохранение Ed 02/03/2004 18:22 #написать ответ
А что если сохранять автоматом при закрытии (с сохранением) базы? Тогда с момента закрытия до момента следующего открытия ничего не изменится Предполагаю, что скажете - нарушится логика работы в разных окнах На что я скажу, что мне вообще не очень нравится ручное сохранение параметров страницы. :-) Но это мелочи Из-за такой ерунды не стоит ломать ТАКУЮ программу
 
Dervish: Есть противоположный пример: Excel. Он ведёт себя совсем по-иному. Если просто открыть экселевский файл и, ничего не изменяя просто переместить активную ячейку, то при попытке выхода из Excel-я он спросит: "Сохранить изменения?" В ситуации когда постоянно приходится лазить по разным файлам и для того, чтобы только что-то посмотреть в них, такое поведение, мягко говоря, раздражает. Лично меня раздражает. А вас?
лучше так Ed 03/03/2004 11:36 #написать ответ
Меня - нет. Уж лучше он 10 раз спросит перед закрытием, чем я 1 раз не сохраню. Хотя и это не всегда спасает А в Ability вряд ли будет много файлов.
 
Dervish: Вопрос вкуса...
Я тоже за сохранение "свернуто/развернуто" Дим(м) 03/03/2004 22:24 #написать ответ
Причем, на мой взгляд, эта "развернутость" не является "содержимым" самой базы. Т.е. если я сверну/разверну какой-то узел, то будет неправильно, если у базы появится признак "Модифицирована".
 
Мне кажется, это лучше сохранять где-то отдельно, а не в самой базе. Например, это может быть строчка из 0 и 1 (свернуто-развернуто), хранящаяся где-то отдельно и каким-либо образом ассоциированная с базой.
На мой взглдяд, это свойство не самой базы, а сессии работы с ней. Т.е. если унести базу на другую машину, то будет нормально, если там свернутость-развернутость не восстановится.
 
Кроме того, так же можно было бы хранить, например, активную закладку.
 
Чтобы предотвратить возможные вопросы, сразу оговорюсь, что если версия/дата модификации базы отличается от той, что была сохранена при завершении предыдущей сессии, то все такие настройки можно сбросить. Это решит проблему с переносом базы "туда-сюда".
 
И еще идея: сохранять развернутость для выпадающих списков. Причем, на мой взгляд, оно должно совпадать с развернутостью узлов на соответствующей странице. Т.е. если я на странице Статьи разворачиваю какой-то узел, то и в выпадающем списке он будет развернут. И наоборот.
 
Dervish: Как раз "развёрнутость" является содержимым базы. Попробуйте предложить какой-нибудь способ ассоциации отдельно хранящейся строчки и, например, статей.
Да просто ведь все.. Нет? Дим(м) 05/03/2004 22:08 #написать ответ
Да нет здесь, на мой взгляд, ничего сложного. Например, можно сделать так:
- в качестве ключа используется, например, путь к файлу базы или какой-нть уникальный идентификатор, который не позволит перепутать базы
- а в качестве значения просто набор строк, по одной на каждый иерархический список в базе (т.е. для разных баз кол-во таких строк может быть различным).
 
Сами эти строки упорядочены в соответствии со следованием самих списков в базе (есть ведь у них какой-то порядок или ассоциированы со списком по его имени.
 
Каждая такая строка представляет собой последовательность из 0 и 1, где 0 означает, что узел свернут, а 1 - развернут. Естественно, отдельная цифра нужна для каждого узла. Даже для тех, которые находятся внутри свернутых узлов - развернули статью Продукты, а в ней подстатья Бакалея свернута, а вот чаще используемая Мясные - уже развернута.
 
Дальше. Очевидно, что если длина строки не совпадает с общим кол-вом узлов соотв. списка, то данные "свернутости" неактуальны и их нужно проигнорировать. Кроме того, там же можно хранить версию (дату модификации) базы, для которой эти строки были сохранены. И тоже игнорировать "свернутость", если открыли другую версию.
Оптимальнее, конечно, было бы хранить не версию всей базы, а версию конкретного списка - чтобы "свернутость" была все же более устойчивой. Но я не уверен, что внутренний формат AC хранит эти номера редакций списков, а вводить их только ради этого, конечно же, не стоит.
 
Dervish: Ну чтож, возможный вариант. Только мне не очень нравится "ассоциированы со спискомпо его имени", получается, что в реестре будут храниться названия узлов списка. А это уже утечка информации. Впрочем, необязательно хранить по названию.
Не совсем так Дим(м) 09/03/2004 13:58 #написать ответ
Это ведь будут не названия узлов, а названия самих списков. Например, "Статьи" или "Агенты"
Конечно, это тоже информация, но, не думаю, что настолько секретная.
 
Кстати, я вот подумал, что ничто ведь не помешает использовать комбинированный подход: если настроек в реестре нет, или они не "актуально", то используются настройки сохраненные в базе. Т.е. когда делается "Сохранить настройки страницы", то они сохраняются и в базе тоже. Получится, что-то вроде статического состояния (в базе) и динамического (в реестре). )
 
P.S. Еще раз оговорюсь, что вовсе не обязательно делать все так серьезно. Это просто идея, как можно было бы сделать.
 
Dervish: Нужно подумать. Давайте вернёмся к этому после экспорта и импорта.
Не мелочь ... СамСебе 09/03/2004 18:40 #написать ответ
Не люблю быть категоричным, но уникальность (отличие от множества других подобных) Cash/AbilityCash в наличии только 1-го (всего одного файла), в котором хранится все. Как в Lotus Notes, например. Любые предложения по использованию дополнительных файлов/записей в регистре должны рассматриваться прежде всего с этой точки зрения, - что они дают, лишая указанного достоинства - все в одном флаконе.
 
Dervish: Ну, мне кажется, что часть настроечных данных можно хранить в реестре. И в том числе информацию о том, где какой узел раскрыт, а где закрыт. И переносимость данных при этом не пострадает: ведь если открыть базу на другом компьютере, то она просто не найдёт этих настроек, а значит, будет показывать всё так, как сейчас.
 
Другой вопрос в том, что в этих настройках не должен упоминаться ни один идентификатор, ни одно название из самой базы данных, в противном случае будет просто разглашение данных пользователя.
а нельзя ли... Li Si Cin 26/03/2004 14:01 #написать ответ
те же "0 - узел свернут, а 1 - развернут" хранить в самой базе, там же, где и названия узлов?
Самое простое, что приходит в голову - перед записью строки в файл дополнять ее нулем или единицей, а перед "выводом не экран" последний знак отбрасывать и принимать его как руководство к действию (разворачивать или нет список).
Хотя в стандартных компонентах есть поля-комментарии типа Tag? Туда можно заносить всё, что угодно.
 
Dervish: Хранить-то можно, только записываться это дело будет не само по себе, а только если пользователь нажмёт Ctrl+S. И я не совсем уверен, хорошо ли это будет. Если же хранить в реестре, то данные могут обновляться автоматически, незаметно для пользователя. С другой стороны, при переносе базы на другой компьютер состояние узлов переноситься не будет.
 
Что лучше?
лучше бы, чтобы программа не "растекалась" по компьютеру, но... Li Si Cin 31/03/2004 18:43 #написать ответ
Вообще, где хранить - для меня не принципиально. Весь смысл моего предыдущего высказывания - поддержать идею сохранения внешнего вида (развернутости/свернутости) деревьев
 
Dervish: ok, понятно. Кстати, возможно, насчёт реестра я погорячился. Посмотрим.
статус-бар для списка счетов Ko$tya 08/03/2004 18:49 #написать ответ
Предлагаю сделать статус-бар для списка счетов, т.к. иногда необходимо узнать сумму остатков нескольких счетов из разных групп счетов или сумму нескольких групп счетов.
 
Dervish: Это, в принципе, возможно, только непросто: если будет статус-бар на странице счетов, то понадобится "мультиселект", одновременное выделение нескольких счетов. А это, в свою очередь, повлечёт за собой переделку диалога редактирования счёта: возможность исправлять несколько счетов сразу. Я с операциями намаялся, насколько необходимо делать то же самое для счетов?
мультиселект Константин 09/03/2004 06:02 #написать ответ
Про мультиселект понятно.
Не понятно зачем нужна "возможность исправлять несколько счетов сразу"?
Это совсем не нужно, т.к. названия у счетов уникальны, валюта выбирается один раз при создании, начальный остаток тоже у всех счетов разный, а родительскую группу можно и по одиночке поправить.
Статус-бар на списке счетов - это конечно не очень важно, но всё же было бы удобно.
 
Dervish: Да, я согласен с тем, что это не нужно, но тогда я буду вынужден "закрывать", делать недоступным пункт в меню, если выбрано более одного счёта. А это вызовет вопросы пользователей.
Фильтр по примечаниям Дим(м) 10/03/2004 13:28 #написать ответ
Возможно, стоит добавить к фильтрам еще и фильтр по примечаниям? Обычного поиска подстроки будет вполне достаточно.
 
Кстати, написал еще кое-какие идеи по настройке статусной строки здесь:
http://www.dervish.ru/forum.php?theme_id=611&forum_id=4
если кому интересно.
фильтр по примечаниям Explorer 10/03/2004 19:25 #написать ответ
некорректное решение с точки зрения логики построения БД.
примечание не является значащим признаком(вообще не является признаком) - если не хватает формальных критериев для фильтрации - необходимо добавить дополнительные, детализирующие признаки...
блин... извините... под вечер - очепятка на очепятке - устал Explorer 10/03/2004 19:27 #написать ответ
Ну и пусть не признак.. Дим(м) 10/03/2004 23:12 #написать ответ
А, на мой взгляд, это гораздо менее неприятная альтернатива созданию классификатора типа "Доп. инфо" и замусориванию его разрозненными одиночными элементами разного типа.
Я использую Примечание для указания характеристик, для которых не вижу смысла заводить отдельный(е) классификатор(ы).
 
Да и, в конце концов, если есть поле, почему нельзя по нему фильтровать? Чем оно хуже других полей? Тем, что не является (значащим) признаком? Ну и пусть себе не является. Если фильтровать по нему может быть удобно, то пускай себе фильтруется.
Примечания как ключевые слова Artem Fedorov 11/03/2004 10:18 #написать ответ
Фильтр по примечаниям может быть довольно удобной штукой. С ним можно будет реализовать своего рода систему ключевых слов (keywords), чтобы в последствии отбирать опирации по определенному слову. Это частично можно реализовать созданием классификатора, НО! Если использовать примечание, одна запись может иметь сразу несколько ключевых слов, тогда как с классификатором она может иметь только одно значение.
еще раз Explorer 11/03/2004 15:13 #написать ответ
примечания, комментарии не являются признаком записи...
 
например сравните
 
ПРОЕKT (проеkt)
 
и
 
ПPOEКТ (пpoekт)
 
даже в таком написании вы не сможете определить в какой раскладке  набран текст - как вы будете использовать фильтр...
 
что касется Keywords - как правило они выбираются из предварительно составленного листа значений. Да Это мог бы быть хороший вариант - отдельное поле MEMO содержащее KeyWords, но оно не заполняется "от руки" любым текстом, как например поле примечания,
 
его содержимое как правило недоступно для прямого редактирования, и значения в нем разделены каким либо разделителем (
 

в любом случае это разные инструменты с точки зрения БД - Filter By SMTHNG и Find SMTHNG in...
никто не спорит Artem Fedorov 11/03/2004 21:43 #написать ответ
Никто не спорит что с точки зрения back-end`а комментарии -- вещи не играющие роли в фактических данных.
Но для пользователя, что статьи, что примечания -- один хрен. И ему удобно использовать примечания как своего рода сборный классификатор.
Почему не дать ему возможность использовать программу именно таким образом, просто сделав поиск?
 
Или сделать отдельную сущность типа классификаторов, "ключевые слова"?
">>> понеслось >>>" (c) Explorer
 
Dervish: Про "отдельную сущность": это хорошо! Снимаю шляпу! (Даже в кресле подпрыгнул) ) Нет уж, увольте...
еще раз... :) Амонин 12/03/2004 09:38 #написать ответ
просто
 
ПОИСК И ФИЛЬТР разные вещи
 
Dervish: Вне всякого сомнения!
Пардон Artem Fedorov 12/03/2004 18:25 #написать ответ
Сорри, я имел в виду конечно же фильтр )
(фильтр это не обязательно поиск всех вхождений, абсолютно точно соответствующих заданному значению)
 
Пример того, как это используется в существующих приложениях:
http://www.bradsoft.com/feeddemon/screenshots/screen.asp?img=1
Средняя панель, поле сверху "Filter"
 
http://www.nidelven-it.no/articles/introduction_to_thunderbird_6/images/migration4.png
Правая часть, поле сверху "Subject or sender contains"
 
Dervish: Хм, осталось придумать, как назвать это поле, чтобы не выглядело тавтологией и чтобы подпись к нему не занимала слишком много места.
Разъяснение Artem Fedorov 13/03/2004 17:50 #написать ответ
Ну как его можно назвать кроме как "Примечание"? Вообще, ввести это в стандартный список фильтров -- и все, ничего нового придумывать не надо вовсе.
 
Dervish: Возможно. Подумаю.
Ввод времени Дим(м) 10/03/2004 22:52 #написать ответ
Интересно, нужна ли кому-нибудь из пользователей детализация времени до секунд?
Опять же, и в таблице только минуты отображаются..
 
Может быть, стоит и на диалоге ввода операции оставить только часы и минуты? Тем более, что и на выпадающем окне у часов есть только 2 стрелки.
 
И, может быть, тогда объединить поля даты и времени в одно, чтобы оно и выглядело, как в таблице и вводилось все сразу... Но это уже так, просто мысль.
 
А еще, мне кажется, есть смысл сделать, чтобы левый клик передвигал минутную стрелку, а правый - часовую. Чтобы помимо таскания стрелок за самый кончик (это ж ведь в него еще прицелиться нужно) можно было и просто "тыцнуть" мышкой в нужное место.
 
Dervish: Секунды, это просто отображение информации, когда я доделаю файл локализации, там можно будет убрать поле секунд из отображения или наоборот, добавить AM/PM и т.д.
Ввод времени Viacheslav 11/03/2004 06:43 #написать ответ
ИМХО использование времени с точностью до секунд нужно автору для создания/использования времени как UIN-а операции.
 
Dervish: Именно так.
Наврядли Дим(м) 11/03/2004 11:39 #написать ответ
Ведь если учет времени выключить, у всех операций время 0:00:00 - какой же это UIN?
 
Кроме того, я ж не против, чтобы где-то в базе даже миллисекунды были. Вопрос в том, зачем секунды в поле ввода?
 
Dervish: И тем не менее, это UIN, там есть ещё миллисекунды, которые не показываются.
Такой UIN? Дим(м) 11/03/2004 15:43 #написать ответ
Т.е., если учет времени выключен (т.е. у операций часы, минуты и секунды = 0), то получается, что у 2 операций может быть одинаковый UIN?
11.03.2004 0:00:00.241  (время 12:37:13)
11.03.2004 0:00:00.241  (время 18:44:56)
?
Или речь о каких-то других миллисекундах?
 
Но это все оффтопик
Основной вопрос: нужно ли вводить секунды в свойствах операции, если они все равно нигде не показываются?
 
Dervish: Это действительно оффтопик. Главное, что это работает.
 
Скажем так, что в свойства операции введены не секунды, а в свойства введено время. А секунды и миллисекунды просто входят в поле "время". Я не стал изменять стандратный формат. Есть во времени это поле, кушать оно не просит.
in any case Explorer 11/03/2004 16:02 #написать ответ
UIN прямо по времени - детский сад...
 
приличные люди так не делают
что будет, если пользователь переставит часы? BIOS, CYSTEM - без разницы,
 
можно генерить UIN в функции времени используя еще и RANDOMIZEs различные или AUTONUMBERs
 
Dervish: Думал, что это несущественно. Ладно, поясню:
 
Конечно, уникальный идентификатор (UIN) в программе используется другой. Есть специальное автоинкрементное поле, которое действительно уникально определяет каждую запись.
 
Время же (вместе с датой) в операциях выступает в виде уникального ключа, по которому программа сортирует данные и выполняет поиск. Пользователи не видят того, что ключ уникален потому что в этот ключ входит и поле миллисекунд, которое для редактирования недоступно и нигде не видно, да и, пожалуй, и не нужно для работы.
 
Ключ по дате/времени должен быть уникальным потому что остатки по счетам хранятся непосредственно в самой операции и если бы этот ключ не был уникальным, было бы непонятно, в каком порядке эти остатки вычислялись. Возникали бы эффекты, как в первой версии, когда две операции, выполненные в одно время "перепутывались" и показывали неожиданные пользователю остатки.
Я, собственно был уверен что это так... Амонин 12/03/2004 09:42 #написать ответ
мой комментарий является комментарием к комментарию а не к программе...
 
не сочтите за флэйм...
 
с ув., с изв.
 
Explorer
И все-таки мы, похоже, о разном говорим.. :) Дим(м) 11/03/2004 18:18 #написать ответ
Я - про то, что в поле редактирования времени операции не нужны секунды (точно так же, как там сейчас нет миллисекунд).
 
Честно говоря, я уже несколько запутался в Ваших фразах:
"введено свойство времени" - это, наверное, о колонке(ах) в базе
"есть во времени это поле" - это, вроде, о gui компоненте для ввода времени
"миллисекунды входят в поле время" - тоже база?
 
Итого, как я все это понял:
1. В базе хранится все (в т.ч. и миллисекунды) - на здоровье!
2. В таблице отображаются только часы и минуты - отлично!
3. В свойствах можно редактировать еще и секунды - зачем?
 
Весь этот сыр-бор из-за того, что при создании операции секунды берутся текущие. А время я обычно ввожу с точностью до десятков минут или даже получаса. В итоге меня просто несколько коробят ненулевые значения секунд, а принудительно обнулять их тоже хлопотно.
 
Dervish: ok, когда выйдет версия с доступным файлом локализации, вы сможете поправить формат. Возможно я сделаю дополнительную настройку. Думаю, это решит проблему.
Так а клики для стрелок будут? ;) Дим(м) 11/03/2004 23:54 #написать ответ
(см. выше сообщение от 10.03.2004 г. 22:52:31)
 
Dervish: Если делать клики для стрелок, то тогда нужно совсем "убивать" секундную стрелку. Кроме того, если нынешнее поведение является предсказуемым, то есть интуитивно понятно, что стрелку можно "зацепить" и перетащить на нужноеместо, то вот такие клики (имхо) являются неочевидными. Что не есть хорошо.
Да. Неинтуитивно... Дим(м) 16/03/2004 18:14 #написать ответ
Ну да, такие клики неинтуитивны. Зато, на мой взгляд, при умении ими пользоваться работать будет удобнее.
Да и таскание ведь не обязательно убирать.
 
Что касается секундной стрелки: а она там есть? Или речь идет об убивании самой идеи ее использования?
 
А еще, как оказалось, одними кликами не получится переключать AM/PM - понадобится отдельная кнопка?..
Еще можно, например, кликать внутри и снаружи круга..
 
P.S. Таскать стрелку 2 круга тоже не очень удобное решение, хотя и интуитивное.
 
Мда, не зря в таких же часах в Windows ничего сделать нельзя, только посмотреть.
 
Dervish: Не помню про секундную стрелку. Возможно, я её закомментировал в коде. Не помню. В любом случае, восстановить - секундное дело (извините за каламбур!)
 
А в Windows есть стандартные часы? Что-то я пропустил... В настройках времени? Вряд ли их можно назвать стандартными, они недоступны для приложений. Это, скорее, разовая разарботка только для настроек.
вот тоже думал я об этих часах... aGa 16/03/2004 23:03 #написать ответ
как вам нравиться такой алгоритм
 
1) mouseDown на циферблате -> установка часовой стреки на место где курсор, далее можно точнее позиционировать - стрелка ползет за курсорм, при этом минутная стрелка тоже движется с шагом например 10 мин, время PM; mouseUp -> зафиксировать значчение, секунды обнулить.
2) mouseDown+moeseUp+mouseDown -> то же но время AM; mouseUp -> зафиксировать значчение, секунды обнулить.
3) ну а по правой кнопке примерно аналогично с минутной стрелкой.
 
Dervish: Основное, что напрягает в предложенном алгоритме, он непрост в понимании. Лично я всё время буду путаться, левая кнопка, это часы или минуты?
 
Мне кажется, что у моей реализации, конечно, есть недостатки, но есть и преимущество: как только видишь на экране часы, тут же возникает интуитивное желание "зацепить" мышкой за стрелку и подвинуть её. И это работает.