Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

8 Март 2021, 08:25 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Часто задаваемые вопросы по LibreOffice и Apache OpenOffice.org
 
   Начало   Помощь Поиск Войти Регистрация    задать вопрос  
Страниц: « 1 2   Вниз
  Печать  
Автор Тема: нужна помощь для перевода простого VBA-макроса в формат OOCalc  (Прочитано 13951 раз)
0 Пользователей и 1 Гость смотрят эту тему.
JohnSUN
Капитана в тот день называли на "ты"
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Киев
Сообщений: 2 764


Помогаю людям и компьютерам понимать друг друга


WWW
« Ответ #15: 18 Август 2012, 15:38 »

"Я на вас удивляюсь..." Вроде как и по-доброму прокомментировал, а практически каждый приведенный тезис - тема для отдельной дискуссии
... однако мне, не имеющему никаких познаний в программировании (по образованию - врач) от этого не легче. Даже более того скажу, когда писался скрипт под VBA - я и то спрашивал помощи у спеца по программированию на этом языке и, хоть с его слов задача выеденного яйца не стоила - для меня это все равно было как чудо.
Собственно к делу: перед тем как писать сообщение сюда, за вчерашний день я постарался вникнуть хотя бы в основы пунктуации кода на OO Basic, но, конечно, перевести код самостоятельно не смог...
JohnSUN! И ты предлагаешь ему бросить почти готовую программу и лезть в дремучие дебри Base.
Именно так... Я же предупредил - мой совет не понравится. Знал об этом еще когда тема только началась. Потому и отмалчивался все это время.
Прекрасно помню, как раздражали ответы BigAndy в темах про Calc - "это всё делается без единой строчки кода..." Но там-то он пытался свести к Base настоящие расчетные задачи - например, "страховой калькулятор". А здесь ведь явная база данных!
Да попытка написать что-то внятное на Base у него займет в 10 раз больше времени, чем замена неработающих функций VBA на аналогичные из OOBasic, а именно это и нужно для того, чтобы заработал его макрос.
Во-первых, не в 10 раз больше, а столько же. И большая часть времени, я надеюсь, будет посвящена не писанию программы, а обдумыванию задачи, ее обсуждению здесь, поиску оптимальной структуры данных и элементов пользовательского интерфейса...
А во-вторых, в том то и фишка, что заработавший макрос не до конца решит первоначальную задачу - простенькая база данных с результатами исследований. Вот, например, сколько у нас там строк на лист Калка влазит? И что будем делать, когда явится обследоваться миллион-с-чем-то-там пациент? Удалим устаревшие данные из первых строк листа "основной журнал"? В принципе, можно... Но ценность базы будет утеряна... Вот, для примера, такой факт: в инете можно нарыть статистические данные Всемирной Организации Здравоохранения (никто не в курсе, ВОЗ и ныне там?) по онкологическим заболеваниям за многие и многие годы. И сопоставляя цифры из этих таблиц можно сделать сногсшибательное открытие - надписи на пачках сигарет "Курение вызывает рак" мягко говоря не подтверждаются этой статистикой: онкобольных среди некурящих не намного меньше. Но зато можно проследить динамику (не постоянный рост, а резкие скачки) за многие годы. И все потому, что эти данные были заботливо сохранены. Так имеем ли мы право "срезать" из базы "устаревшие данные"? И лишь потому, что изначально выбрали не то хранилище для них?
Я уже молчу про время открытия-сохранения книги, когда записей наберется несколько десятков тысяч...
Честно говоря, вот эта необходимость замены неработающих функций VBA на аналогичные из OOBasic, а это тоже очень немалая работа, и отвращает от всяких попыток повозиться тех, кто это мог бы сделать.
Да нет... Не объем работ отпугивает: заранее понятно, что КПД готового решения будет безобразно мал, "гора родит мышь".
Но и с Base будет тоже самое, даже намного хуже - функции придется использовать совсем другие, совсем не похожие на уже имеющиеся.
Это в случае, если их придется использовать. Основная нагрузка на программу - обработка данных, их ввод-поиск(отбор)-изменение-удаление - будет переложена на специализированный компонент. Собственно программировать придется только разные "вкусности" связанные с пользовательским интерфейсом...
И хоть этот тезис выглядит как "А слабо?..", я не тороплюсь орать "Не слабо!" и набрасывать решение в Base - просто не до конца понимаю задачу: по внешнему виду формы в Книга1.0.xls, по составу листов, по названиям колонок и текстам VBA-макросов трудно определить конечные задачи проекта. Да и термины выглядят неоднозначно. Вот, например, я не возьмусь без тестовых данных или словесного описания судить о назначении колонки "время выполнения" - то ли часы-минуты проведенные на обследовании, то ли время, когда пациенту сказали прийти в рентген-кабинет...
Мораль всего того, что я сказал:
1) трудоёмкость этой задачи по переводу VBA и OOBasic отпугивает потенциальных "гуру",
2) писать программы для Base должен программист БД, а не врач (когда он закончит писать программу, все его пациенты уже закончат свой жизненный путь).
1. "Русский офицер... бывшим..." (с) "12" - Гуру потенциальным не бывает. Гуру ничего не боится (кроме сквозняков).
2. А пуркуа бы, собственно, и не па? Я не про жизненный путь, а про профессиональную принадлежность автора базы данных. В 95-ом или в 97-ом Аксессе базы данных для себя делали и врачи, и актеры, и водители... БОльшая часть работы выполнялась Мастерами - создание таблицы, ее нормализация, построение отчета... Достаточно было запустить нужный Мастер, выбрать один из готовых ответов на два-три вопроса  и получить результат... Работа с Base - НЕ СЛОЖНЕЕ. "Базы данных - дело исключительно для хорошо обученных специалистов" - миф.
Записан

Владислав Орлов aka JohnSUN
Благодарить-не зазорно.
Подарить благо создателям офиса, нашему ресурсу, мне
VlhOwn
Форумчанин
***
Offline Offline

Пол: Мужской
Расположение: Ростов-на-Дону
Сообщений: 1 076


« Ответ #16: 18 Август 2012, 16:08 »

Позволю себе вставить свои 15 копеек:
1. Аппетит приходит во время еды. Остановится доктор, получив документ с учетом рентгеновских процедур? Очевидно, нет - он по аналогии начнет ваять учет всех других элементов обследования и лечения. А потом что? Открывать десяток документов и в каждом искать пациента? Долго ли его будет удовлетворять такая организация дела? Как скоро возникнет необходимость объединять все в единое целое? А это, полагаю, будет совсем иной уровень программирования. И использование неподходящего инструментария (Calc) приведет к взрывообразному увеличению объема и трудоемкости процесса. Больше того, отказаться и начать заново будет уже неимоверно сложно.
2. В 90-х годах врач, уже тогда обладавший международным признанием, Голубев Георгий Шотович, ныне доктор наук, профессор, заведующий отделением ортопедии ЦГБ Ростова-на-Дону, с нуля освоил программирование БД до уровня профессионала. И, заметим, в те годы у него не было под рукой таких удобных инструментов. Если не ошибаюсь, он пользовался досовским FoxPro.
Записан
JohnSUN
Капитана в тот день называли на "ты"
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Киев
Сообщений: 2 764


Помогаю людям и компьютерам понимать друг друга


WWW
« Ответ #17: 18 Август 2012, 16:28 »

По первому пункту +1!
Забыл упомянуть об этом нюансе... Один и тот же пациент проходит серию однотипных обследований на протяжении полугода. В принципе, калковская таблица позволит, скажем, через Автофильтр отобрать все данные об этом... э-э-э... ну, пусть Пупкине. И эти данные будут достоверными. До тех самых пор, пока в болезнях Пупкина Алексея Александрович (постоянно заносимого в книгу как "Пупкин А.А.") не заподозрят генетическое заболевание... И не пригласят на обследование всю его семью... и не появятся в книге его отец Александр Адамович, и его брат-близнец Андрей Александрович, и его сын Анатолий Алексеевич... И все они будут Пупкин А.А.
Отличить их можно по дате рождения. Всех. Кроме брата-близнеца...
Записан

Владислав Орлов aka JohnSUN
Благодарить-не зазорно.
Подарить благо создателям офиса, нашему ресурсу, мне
Страниц: « 1 2   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!