|
Доброго времени суток, Посетитель!
|
|
|
|
|
|
|
|
|
вид форума:
|
| |
|
|
| | Калькулятор "а-ля Windows 7"
Иногда, при разработке MS Access (MSA) приложений, приходится сталкиваться с выбором инструмента расчета, проще говоря "Калькулятора". Много уже написано по этой теме, многие уже имеют свои наработки. Я тоже решил поставить для себя "точку" в этом вопросе.
Итак. Разница между сторонними Калькуляторами (ActiveX, входящими в состав ОС, ...) и написанными в среде MSA очевидны - полная управляемость интерфейсом и программным кодом; возможность тонкой адаптации под конкретные нужды; практически полная независимость от ОС (работал бы MSA); и т.п.
Просмотрев некоторое количество подобных Калькуляторов, и не обнаружив для себя подходящего, решил "не ковырять имеющиеся рыбы", а написать новый "с нуля", благо прототип Калькулятора в виде встроенного в Windows 7 перед глазами.
Выбор сделан - только Калькулятор, написанный в среде MSA; прототип из W7.
Отличия от прототипа:
- оставлен только Обычный вид, за ненадобностью остальных;
- кнопка Enter принимает два значения "=" (равно), когда вычисление логически не закончено и "ОК", когда уже можно закрывать Калькулятор, соответственно убраны кнопки оконного меню ;
- введена возможность сохранять Историю Вычислений - полезна при анализе, как получился конкретный результат, что существенно упрощает общение с пользователями, которые почему-то всегда "ничего такого не делали";
- изменена функция работы кнопки "CE", в соответствии с предыдущим пунктом;
- введены ограничения на выполнение некоторых операций (очистка Истории Вычислений, Редактирование формул);
- имеется также возможность частичного вычисления функций и методов MSA, хотя это не входило в задачу и по возможности заблокировано.
P.S. Калькулятор разработан в MSA2010, там и тестировался. Конвертирован в 2000, только цветовая гамма поехала.
Кому ИНТЕРЕСНО, то прошу потестить, сам вроде все посмотрел, но "глаз уже замылен".
Файл доступен на: http://slil.ru/29239950 - Калькулятор_2010
http://slil.ru/29240029 - Калькулятор_2000 | |
| |
| |
| |
|
|
| | ссылки битые
404 Not Found | |
| |
| |
| |
 41 Кб. |
|
| | Только что проверил - все скачивается 
Я бы напрямую залил, но здесь ограничение 50кБ, а первый файл 74кБ весит. Второй (Калькулятор_2000) прицепил. | |
| |
| |
| |
|
|
| | Красиво - чёрнинький такой дисплей и ничего не отображает на своём "ТАБЛО"
Чё та он мне там понаписал 9=>8*0
А ваще - прикольно!!!
У мну тоже есть такая вещица
http://hiprog.com/index.php?option=com_content&task=view&id=251661591 | |
| |
| |
| |
|
|
| | Если запускать через форму TEST_Calc, то там есть "Поле0" - это начальные значения и затем результат вычислений. И еще одно поле "TextFld" - История вычислений (закрыта на доступ), где через разделитель " => " перечислено то, из чего вычислился результат.
А по поводу приведеноой ссылки, то в коде функция Eval встречается неоднократно 
К сожалению не имею возможность тестировать 2000 вариант, поэтому просьба написать какие подробно действия (нажатия клавиш/кнопок) привели к результату "9=>8*0" - скорее всего последовательность нажатия кнопочек была такая: "9" "=" "8" "*" "0" "ОК" при этом в результате На Калькуляторе в листе Истории вычислений две строчки 9 и 8 * 0, а в форме TEST_Calc "Поле0" = 0.00, в "TextFld" = "9 => 8 * 0" | |
| |
| |
| |
|
|
| | формат 2000 из прицепа:
При нажатии клавиши в русской раскладке правомерно ругается.
Шрифты кнопок у меня великоваты, надпись в кнопку не влезла в строку (верхний ряд)
Не нашел кнопки отмена, может плохо искал?
A2003 sp2, WXP | |
| |
| |
| |
|
|
| | На буковки то я и не расчитывал.
Спасибо. Принял к сведению
А что под отменой понимается? Если сброс поля ввода, то "С", ESC или Delete | |
| |
| |
| |
|
|
| | Я имел в виду:
В поле есть число, я открыл калькулятор, что-то посчитал, итог меня не устроил.
Мне надо закрыть калькулятор так, что-бы изначальное число в поле не изменилось.
Доп.
1. Найдите календарик от Сергея Гаврилова или KrukVN,
посмотрите там методы позиционирования формы и возврата значения.
2. На сайте есть пример: Класс для сохранения настроек формы Access от alecks_lp
http://hiprog.com/index.php?option=com_content&task=view&id=251661603&Itemid=35
посмотрите, пригодится. | |
| |
| |
| |
|
|
| |
Мне надо закрыть калькулятор так, что-бы изначальное число в поле не изменилось.
|
Как раз это то и пытался избежать. Все Результаты вычислений должны быть зарегистрированы в Истории вычислений. Конечно не трудно восстановить входное значение и записать его в Историю вычислений, но СОЗНАТЕЛЬНО не стал этого делать, т.к. 1) Получаю доп. знания о пользователе - понимаю с кем имею дело, а это уже козырь в разговоре с любым руководством; 2) Воспитываю пользователя по принципу "не умеешь работать головой - работай руками"; 3) Кроме того, догадываясь, что пользователь сначала нажмет "С" (обнулит строку ввода), а потом наберет первоначальное значение, тем самым повторно, хоть и косвенно, подтвердит правильность первоначального ввода. А не введет, так такие ошибки (наличие нуля в реальной проводке) и искать проще 
Спасибо за ссылки. Обязательно посмотрю. Но в данном контексте мне интересно какие минусы имеют "...методы позиционирования формы и возврата значения..." в данном Калькуляторе.
Универсализма и здесь хватает: подвинул пользователь форму, в следующий раз открылась на том же месте. Записал в таблицу позицию окна, так она тоже распространяется вместе с приложением. Конечно для многопользовательских приложений структура такой таблицы должна быть отличной от той простейшей, приведенной в примере. Зато простота: ни каких API, Коллекций, и в случае чего любой админ может что-то в таблице подправить штатными средствами не изучая MSA, VBA, ... | |
| |
| |
| |
|
|
| | Lukas: Мне надо закрыть калькулятор так, что-бы изначальное число в поле не изменилось.
AlexSyr: Все Результаты вычислений должны быть зарегистрированы
Одно другому не мешает.
...наличие нуля в реальной проводке.. - это достигается другими инструментами
Не нравится:
1. передача/возврат значений в форму-калькулятор через паблик структуру .
2. Чтение и присвоение значений положения формы-калькулятора в модуле вызывающей формы. (А если нужно 10 кнопок-вызовов калькулятора в одной форме?)
Сохранение/восстановление положения формы-калькулятора на экране это сугубо ее методы, а никак не вызывающей формы.
3. Хранение значений положения формы-калькулятора в таблице. Приходится таскать вместе с формой и таблицу.
В приведенных выше рекомендациях использованы другие варианты, более правильные и более универсальные.
Есть и еще варианты.
и в случае чего любой админ может что-то в таблице подправить - упаси боже от этого админа и саму БД.  | |
| |
| |
| |
|
|
| | 1. Не посчитайте меня занудой, но, очень хочется знать ПОЧЕМУ правильней так, а не по другому.
Возьмем пример: Маленький календарь, ... Автор Сергей Гаврилов http://hiprog.com/index.php?option=com_content&task=view&id=600
Данные в форму:
Календарь:
* Устанавливаем фокус на контроле с инф.
* Вызываем форму, где:
...
With Application.Screen
Set mCallingControl = .ActiveControl
End With
...
mDtmDate = mCallingControl.Value
...
Калькулятор:
* Инициируем паблик переменную значением из нужного поля
* Вызываем форму, где:
...
Me.InputFld = GloCalc.Value
...
Данные из формы:
Календарь:
* При закрытии присваиваем вызываемому контролу значение:
...
mCallingControl.Value = mAffectedDate
...
* Закрываем форму
Калькулятор:
* При закрытии присваиваем паблик переменной значение:
...
GloCalc.Value = Round(Me.InputFld, 2)
...
* Закрываем форму
* Присваиваиваем вызываемому полю значение из глобальной переменной
Где грабли? Я еще мог бы понять, что округлять нужно в вызываемой форме, а не в Калькуляторе - согласен. Дело в одной лишней строчке - это не цикл - затраты времени тьфу. Глобальная переменная продолжает хранить значение? Так все равно при следующем вызове нужно заново ей переприсваивать значение, на худой конец и обнулить можно.
2. Здесь думаю, что не придумали пока такого искусственного интеллекта, который бы лучше человека понимал как расположить форму Калькулятора, если еще и 10 кнопок-вызовов. Если с маленькой формой Календаря еще можно допустить автоматическое расположение относительно вызываемого элемента, то с большой формой Калькулятора - это уже проблематично, для того форма и сделана перемещаемой. Хотя это конечно вопрос риторический и не требующий ответа.
3. И что значит таскать и таблицу - ведь все равно в Базе есть таблицы. И чем же таблицы с настройками отличаются от других? Пусть также как и другие хранятся в отдельной базе на сервере ли или еще где. Впрочем это лично мое мнение, что не стоит городить частокол кода из-за этого. | |
| |
| |
| |
50 Кб. |
|
| | 1. Грабли в том, что вы в вызывающей форме считываете положение формы-калькулятора, и сохраняете их в модуле вызывающей формы.
2. При таком размере формы, конечно, вопрос об интеллектуальном размещении формы=пустая трата времени. И все-же, вы можете со 100% уверенностью ответить на вопрос:
Значение какого поля расчитывает Калькулятор на скрине? => | |
| |
| |
| |
10 Кб. |
|
| | При меньших размерах калькулятора, это сделать довольно просто =>
3. Вот если-бы Вы хранили положение Калькулятора для каждой вызывающей формы раздельно,
это вполне имело бы смысл делать в табличке. Еще и с фиксированием по пользователям.
Впрочем, и так тоже сойдет. Не берите в голову. : ) | |
| |
| |
| |
59 Кб. |
|
| | А здесь еще один вариант передачи/возврата значений на базе вашего.
Все по-быстрому, потому возможны нарушения изначального функционала,
но главное должно работать.
Да, и функции чтения-записи в вашу служебную табличку лучше сделать в отдельном модуле,
и вызывать их, передавая параметры, из всех мест, где это нужно. | |
| |
| | |
| |
|
| |
|
|
| | а мне не понравилось
это мое мнение - отнеситесь к нему великодушием
не понравилось то что в форме выдается список в формате 1+2=>3-2=>1+4
а в другом поле результат
как-то это не по-математически
в листбокс хотел бы видеть результат выражения т.е. 1+2=3 | |
| |
| |
| |
|
|
| | В форме TEST_Calc поле "TextFld" (История вычислений) по уму должна быть вообще скрыта для пользователя (ему то зачем загружать голову какими-то формулами - ему нужен ТОЛЬКО Результат вычислений). Я оставил ее открытой только ради демонстрации. Другое дело админ БД - ему наверное нужно открывать это поле для проведения разборок на предмет того КТО и ЧТО некорректно ввел, но ему, как мне кажется, и такой инф. будет достаточно. Хотя, конечно, не сложно добавить результат в Историю вычислений (типа: 1 + 2 = 3; 3 - 2 = 1; 1 + 4 = 5). Здесь надо понимать, что данная строка может принимать и такое значение: 1 + 2 = 3; 77 * 2 = 154, т.е предыдущий результат не всегда может быть одним из операндов следуещего вычисления.
Считаете, что так будет "понятнее"? Один голос принят ЗА Вариант "Расшифровать Историю Вычислений в вызываемой форме".
Если же говорить про листбокс самого Калькулятора, то при ограниченности инф. пространства стоит ли здесь расшифровывать, если при нажатии на строку листбокса в строке ввода можно посмотреть Результат вычислений. Вопрос!!! | |
| |
| |
| |
|
|
| | пока листбокс предполагает значение предыдущего вычисления-
тут хозян - барин | |
| |
| |
| |
|
|
| | Мне в принципе понравилось (в код я не лазил)
В редакторе MultyEdit (был такой под DOS) в нем был калькулятор с историей, я потом такой же слобал на Clipper
Довольно удобно, может только несколько великоват...  | |
| |
| |
| |
|
|
| | Великоват - это я специально так сделал (ИСКЛЮЧИТЕЛЬНО для себя - слеподыр знаете ли ).
Посчитал, что наверное все равно каждый будет переделывать под себя (цветовую гамму, размер, эффекты наведения/нажатия на кнопки, шрифт,...)
Кстати а какой у всех шрифт? У меня в W7 "Calibri" - это наверное от темы рабочего стола зависит. Может поэтому внешний вид Калькулятора сразу отталкивает | |
| |
| |
| |
|
|
| | шрифт может быть только Arial
остальное от лукавого | |
| |
| |
| |
|
|
| | Не вопрос!!! Поправлю. Но почему так категорично - Arial??? Что-то магическое в этом шрифте? | |
| |
| | |
|
| |
|
|
| |
От меня Tahoma. | |
| |
| |
| |
|
|
| | я потихонечку тоже пользую тахому, но это не тру | |
| |
| |
| |
|
|
| | Я в основном arial
Но нравится мне new roman | |
| |
| |
| |
|
|
| | У меня, например ни в одном примере не работают круглые скобки (на нажатие - ноль эффекта), ни операция %. такая последовательность ввода: 100-25 %% - вываливает ошибку. :( | |
| |
| |
| |
|
|
| | Скобки работают только в режиме редактирования формул. Необходимо для этого дать разрешение на редактирование формул: в форме TEST_Calc в событии на кнопку изменить на:
GloCalc.AllowEditFormula = True
Тогда станет доступен двойной клик на строке листбокса, где собственно можно редактировать формулу.
Проценты работают как в прототипе. Например: "1" "5" "0" "+" "3" "%" - в поле ввода вставляется результат "4.5", если после этого нажать, к примеру "7" "%", то результат изменится на "10.5" - можно набирать "=". Если так не удобно, то предлагайте как Вы считаете более правильным, потому как % везде считаются по разному  | |
| |
| |
| |
|
|
| | с редактированием понятно.
ввожу "123-4%=" выдаёт ошибку "Деление на ноль". :(
процент вычисляет прально - 4,92
На точку не реагирует %) | |
| |
| |
| |
|
|
| | Есть косяк, но другой. Зафиксировал. Спасибо - буду исправлять. Но такого результата, как у Вас НЕ СМОГ получить. Может где еще баг. Опишите подробно, как вы набираете комбинацию (на клавиатуре или кнопками на форме), где находится курсор (в поле редактирования?). Буду премного благодарен.
Про точку не понял. Опять - как производите набор. | |
| |
| |
| |
|
|
| | точка не вводится ни с клавы ни с формы.
То, что с % - видно разные у нас установки региональные для чисел. В дебаггере выставляю вместо запятой точку - всё работает. :) | |
| |
| |
| |
|
|
| | Пооонял. Я бы сам никогда на это не напоролся. Спасибо. | |
| |
| |
| |
|
|
| | Подводя итоги, хотел бы заметить, что представленный Калькулятор заметно изменился, надеюсь, что в лучшую сторону. Спасибо ВСЕМ за участие в тестировании.
Новую версию для MSA2010 и 2000 можно скачать --> http://slil.ru/29282883
Изменения:
- Переделан вызов и передача значений (Lukas);
- Заменен шрифт на Arial (Explorer, час), уменьшены немного размеры шрифтов, что соответственно уменьшило размер Калькулятора;
- Результат вычислений на выходе Калькулятора не округляется;
- Исправлено возникновение ошибки при вводе букв на русском регистре (Lukas), теперь блокируются все клавиатурные клавиши с кодом больше 127, т.е. ввод латинских букв разрешен (может, кто захочет, в режиме Редактирования формул, проверить результат работы какой-либо функции, типа FV(0.1/12,4*12,-10000)  );
- Исправлена ошибка при работе со значениями из листа Истории вычислений в качестве операндов (snipe);
- Исправлена ошибка неверного ввода арифметических операций ("+", "-", "*", "/") - последняя арифметическая операция всегда заменяет предыдущую;
- Расшифрована История вычислений в вызывающей форме (snipe) - теперь выводится с результатом (например: 456 + 44 = 500; 500 * 7 = 3500; 3500 / 5 - 200.25 = 499.75)
- Исправлена ошибка с вводом дробных значений числа;
- Исправлена ошибка работы кнопки "С" - теперь память Калькулятора не очищается;
- Исправлена ошибка работы клавиши "Delete" - теперь обнуляет только Строку ввода;
- Переделаны вычисления с учетом разных разделителей ("." или ",") целой и дробной частей числа (DeBob). Используемый разделитель будет сразу виден на кнопке "Точка";
- Исправлены ошибки при обработке Процентов (DeBob);
- Изменена работа кнопок "(", ")" (DeBob) - теперь кнопки работают во всех режимах, а не только при Редактировании формул;
- Исправлены разные мелочи.
P.S. О ПОЛЬЗЕ ТЕСТИРОВАНИЯ:
Скачав инструкцию к первому попавшемуся аппаратному калькулятору, которым оказался CITIZEN SR-135T, решил проверить его примеры. НЕОЖИДАННЫЙ результат.
Пример: 6 + ((5 - 3.6 + 5) * 0.8 - 6) * 3.2
Результат:
CITIZEN = 3.184;
Excel = 3.184;
Мой Калькулятор = 3.184;
Калькулятор встроенный в Windows 7 (вид Обычный) = 16.384 !!!!! 
Начинаю разбираться. Получается:
6 + ((5 - 3.6 + 5) * 0.8 - 6) * 3.2 = 16.384
а так:
((5 - 3.6 + 5) * 0.8 - 6) * 3.2 + 6 = 3.184 ВО КАК!!!!! Прямо как по Задорнову.
Т.е. к числу в скобке сначала добавляется 6, а потом умножается на 3.2, поэтому, чтобы получить правильный вариант нужно в Калькуляторе Windows 7 добавить дополнительные скобки:
6 + (((5 - 3.6 + 5) * 0.8 - 6) * 3.2) = 3.184
а в Инженерном виде все работает правильно.
Всем Удачи! | |
| |
| |
| |
|
|
| |
- Заменен шрифт на Arial (Explorer, час)
|
Я тут совершенно ни при чём...
Занесите мои показания в протокол........  | |
| |
| |
| |
|
|
| | Вот ведь как просто написать калкулятар..........  | |
| |
| |
| |
|
|
| | Запротоколировано
----------------
автор: час (01.06.2010 в 23:05)
Я в основном arial
Но нравится мне new roman
---------------- | |
| |
| |
| |
|
|
| | В версии 2000 (то что бросилось сразу в глаза):
1. Сразу вылетает в аут на строчке: strNewDelimiter = Mid(CDbl(CStr("4.56")), 2, 1)
Как-то смущает такой способ определения разделителя, но "на крайняк" так проще: =Mid$(1/2,2,1)
2. В строчке(-ах): If blnFlagKeyb = True Then сравнение переменной типа Boolean с константой бессмысленно. Можно проще: If blnFlagKeyb Then
3. Названия свойств и методов класса с префиксом "frm" как-то "неестественно".
4. "Размытое" присвоение свойств "frmAllowCE" и "frmAllowEditFormula".
По идее, эти значения должны быть прописаны где-то в "настройках ролей", то есть форма-калькулятор сама должна определять роль пользователя и, соответственно, значения этих свойств.
Ну не прописывать - же каждый раз в вызове калькулятора значения этих свойств.
5. Так-же и с позиционированием формы на экране. Допустим в "настройках" есть опция:
позиционировать форму по контролу или по сохраненному ранее положению.
Открываясь, форма читает эту опцию, и, соответственно перемещается в нужное место экрана.
Не надо в каждом вызове формы прописывать куда ей двигаться, она должна сама это делать.
В рекомендованных мной выше примерах - календариках, процедуре, вызывающей форму
-календарь достаточно перевести фокус на поле, значение которого интересует и создать
экземпляр формы- календаря. Все остальное делается самой формой-календариком.
Вы же "перекладываете обязанности" формы-калькулятора вызывающим формам. А им это надо?
И, если предполагается хранение истории вычислений и положение формы при закрытии,
это должно делаться опять же самой формой-календариком, а не вызывающей формой. | |
| |
| |
| |
|
|
| | 1. Сразу оговорюсь, что проверял на MSA2003 (2000 просто не нашел), там не было ошибки, правда разделитель на "," не менял. Сфилонил. Каюсь. 
Более простого способа определять разделитель не придумал. Использовать API - только на самый крайний случай. Ваш "на крайняк" оценил - возьму на заметку.
2. Безусловно Вы правы. Такие конструкции только от того, что не люблю условности/предположения/по умолчанию/..., хотя, конечно, частенько отхожу от этих принципов
3. Собственно префикс можно вообще не ставить. Только с ним гораздо проще - все свойства/методы сгруппированы в одном месте. А какой он будет - ведь по большому счету и не важно.
4. Принципиально не согласен, что какой-то там Калькулятор должен определять роль пользователя? Да и по сути, роль - это тот же набор элементарных прав/правил, прописанных в настройках. Наверное уместно говорить "роль Калькулятора" - так она и складывается на основе передаваемых свойств.
Да и каждый раз прописывать не обязательно - все будет по умолчанию.
5. Это коррелируется с предыдущим пунктом. Ведь Калькулятор - это тот же инструмент, ну скажем как отвертка/молоток/..., которым можно делать даже то, что в них конструкторы и не закладывали. И не инструмент (читай Калькулятор) определяет как им будет распоряжаться пользователь (читай Вызывающая форма), ну по крайней мере на 100%.
Впрочем - это все риторика. | |
| |
| |
| |
|
|
| | "Жираф большой, ему видней." (с)
И придется в каждой из 30 (к примеру) форм с 3 (к примеру) расчетными полями в каждой,
считывать настройки и прописывать калькулятору что ему можно, что-нельзя,
куда ему переместиться, сохранять настройки и историю. Итого 90 раз.(к примеру).
Говно вопрос, подумаешь, две-три страницы лишнего, абсолютно ненужного, однотипного кода. | |
| |
| | |
|
| |
|
|
| |
Полагаю, что я всех уже "достал"...
|
Никоим образом.
Форум ведь и существует для обмена мнениями, поиска оптимальных решений и прочяя.
...вынести весь этот "абсолютно ненужный, однотипный код" ...
|
Так я и предлагаю вынести часть этого в модуль самого калькулятора, часть в модуль(и) настроек/разрешений.
А он при загрузке пусть спрашивает у модуля(ей) настроек/разрешений все что ему от него нужно.
Каждый будет заниматься только "своим делом": калькулятор считать, модуль настроек читать/сохранять настройки, модуль разрешений - разрешениями.
Если надо что-то изменить, то только в одном, специально обученном для этих целей модуле.
Ну как-то так.
Уф, хорошо поболтали. | |
| |
| |
HiProg.com - Технологии программирования
|
своими поисками "истины" 