Вставить заголовок диаграммы из ячейки листа

Автор tagezi, 1 июля 2016, 13:55

0 Пользователи и 1 гость просматривают эту тему.

rami

Цитата: tagezi от  1 июля 2016, 21:38То что работник может перепутать правую руку и левую или намерено исказить, или непонимать применения инструментов, я думаю должен заботиться его начальник, а не я. Я могу только рассматривать случайные ошибки. Ты правильно отметил что значения в полях проверяются криво, это моя задача, предсказать неправильное действите. Но куда тыкает пользователь, это дело пользователя.
Вот прийдёт JohnSUN, он тебе расскажет кто о ком должен беспокоиться и кто будет виноват в любом случае.

Вот как ты объяснишь такую ситуацию? Ты выложил документ и файл конфигурации на github, но я не смог скачать файл конфигурации, а если бы ты заархивировал оба этих файла в одну папку и выложил на форуме, то эта проблема ни куда бы не делась, она бы просто осталась бы не замеченной до самого не подходящего момента.

Есть ещё несколько проблемных моментов, например, если переименовать лист Interim calculation (добавить 1 в конце) и оставить его на месте, то получишь ошибку 1 Адрес для факторов указан не верно! сразу после вставки нового листа, но если переименованный лист переместить в конец, то ошибки не возникает.

tagezi

Цитата: rami от  1 июля 2016, 21:30Вот прийдёт JohnSUN, он тебе расскажет кто о ком должен беспокоиться и кто будет виноват в любом случае.
Я с удовольствием выслушаю его мнение, да и твоё тоже... но сделать 100% защиту не возможно, всё равно можно найти как всё испоганить. Сам спроси у JohnSUN, на 100 твоих хитростей с парсингами и тотальными проверками, пользователь придумает такое, что ты та даже в страшном сне не представишь. :)
Жена рассказывала, на работе был шаблон электронной таблицы, куда нужно было вводить циферки и он сам всё считал. Естественно, чтобы его не ломали, ячейки имели запороленую защиту. Так люди, вместо того чтобы просто заполнять, находили кряки, ломали эту защиту и писали как хотели. В итоге документ приходилось переделывать с нуля. Вот что ты с ними сделаешь?

Цитата: rami от  1 июля 2016, 21:30Вот как ты объяснишь такую ситуацию? Ты выложил документ и файл конфигурации на github, но я не смог скачать файл конфигурации, а если бы ты заархивировал оба этих файла в одну папку и выложил на форуме, то эта проблема ни куда бы не делась, она бы просто осталась бы не замеченной до самого не подходящего момента.
Сознаюсь, конфигурацию я выложил зря, и листы с расчетами нужно для тестового файла удалять, тогда всё будет нормально. Если макрос не находит файл конфигурации он создаёт новый. Ошибки которые ты описываешь, я попробую обработать, хотя бы просто чтобы не вылетало ошибки, а было нормально предупреждение: "ЕГГОГ 2" :)

Цитата: rami от  1 июля 2016, 21:30Есть ещё несколько проблемных моментов, например, если переименовать лист Interim calculation (добавить 1 в конце) и оставить его на месте, то получишь ошибку 1 Адрес для факторов указан не верно! сразу после вставки нового листа, но если переименованный лист переместить в конец, то ошибки не возникает.
А вот это очень интересно и неожиданно для меня. Спасибо.

Вообще, почему тебя ещё нет в команде QA, ты прекрасный тестировщик. :)
(x86_64) Kubuntu 16.04.3 - LibreOffice 6.0.2 / 6.1 alpha

rami

Цитата: tagezi от  1 июля 2016, 22:46... но сделать 100% защиту не возможно, всё равно можно найти как всё испоганить. Сам спроси у JohnSUN, на 100 твоих хитростей с парсингами и тотальными проверками, пользователь придумает такое, что ты та даже в страшном сне не представишь.
Проблема не в коварных пользователях, а в не продуманной реализации. Пользователь вводит не правильные данные, а ты сначала удаляешь лист или рисуешь заготовку диаграммы, а потом проверяешь введённые данные, если есть ошибка, остаёшься без листа или с болванкой диаграммы, а почему бы не проверить сразу после ввода данных. У тебя не правильный порядок действий.

JohnSUN

Нет, юные друзья мои, вы оба не правы - самое прекрасное в... э... я сейчас уже не вспомню как оно называется... и где находится...
Тоже мне, нашли кем друг друга пугать! Не стану я вам жупелом, не до того мне сейчас - я код пытаюсь читать. И понимать.
Вот, например,
aTempAddres = Split(sAddress, "$")
aTempAddres = Split(aTempAddres(1)&aTempAddres(2)&aTempAddres(3), "'")
Длинннная конкатеннннация в скобках во второй строке режет глаз - Join(aTempAddres, "'") получился бы чуть лаконичнее. Но вся конструкция от этого не стала бы лучше... Все равно осталось что-то неизящное. Чего-то эдакого тут не хватает... Или лишнее?
Слишком много возни вокруг вроде бы простого действия: Функция, вот тебе строка, в которой должен быть адрес одной ячейки (диапазона? пачки несвязных диапазонов?) где-то в текущей книге- верни True если адрес написан без ошибки, а в остальных параметрах верни имя листа, колонки, номер строки и значение из ячейки (если вернешь False, в эти переменные можешь насовать что хочешь, я туда даже смотреть не стану)

А по поводу ваших препирательств на тему какой термин лучше подходит - "очень" или "очень-очень" - для выражения "пользователь ... большая сволочь"
Вот мы разбираем строку из текстового поля ввода диалоговой формы. Типа, предполагается, что там адрес одной ячейки. Причем, абсолютный, с долларами. Ну, мы же кнопку выбора ячейки рядом с полем нарисовали - значит пользователь будет щелкать мышкой в нужную ячейку и в форме с заголовком "Выбор адресса" будет появляться абсолютный адрес ОДНОЙ ячейки.
Что-то я запутался - кто из вас тут писал о всемогуществе дураков при преодолении foolproof?
Это - обычные текстовые поля в которые пользователь может от руки вписать, например, относительный адрес или "босс все-таки редкостный упырь". И даже защитив это поле от редактирования, мы не сможем запретить пользователю при выборе адреса зажать Ctrl и поелозить мышью по всему листу, напихав в поле что-то вроде $'Cash flow'.$C$25:$I$25;$'Cash flow'.$C$28:$H$28;$'Cash flow'.$D$30:$K$30(К комбобоксам, кстати, это тоже относится)... Как-то слишком уж плотно диалоговая форма (реальный View) влез в область данных (предполагаемый Controller).
Владислав Орлов aka JohnSUN
Благодарить-не зазорно.
Подарить благо создателям офиса, нашему ресурсу, мне

rami

Цитата: JohnSUN от  2 июля 2016, 05:53А по поводу ваших препирательств на тему какой термин лучше подходит - "очень" или "очень-очень" - для выражения "пользователь ... большая сволочь"
Не надо переводить стрелки на пользователя. Я о том, что проверки нужно проводить до перехода к следующему действию, а не после. Введённые данные не прошли проверку, — "Извините, у вас ошибка..." и ничего не делать пока не будет правильный ввод данных.
Цитата: JohnSUN от  2 июля 2016, 05:53Что-то я запутался - кто из вас тут писал о всемогуществе дураков при преодолении foolproof?
Чур, не я.
Дурак силён непредсказуемостью и неадекватностью, а программист — качественным кодом, их вселенные не пересекаются, разве только если программист дурак.

rami

Цитата: JohnSUN от  2 июля 2016, 05:53...не до того мне сейчас - я код пытаюсь читать. И понимать.
Это тебе не детективы читать ;D

Вот такое место меня смущает: переменная aTempConfParam определяется как массив с элементами от 1 до 3, а по факту в неё впихивается массив от 0 до 1 (в случае флажка) или от 0 до 2 (в остальных случаях). Пока это не делает проблем, но кто знает... Почему бы не определить проще:Dim aTempConfParam()

Нужно избавляться от неработающего или мутного кода.

tagezi

Вот я тормоз. Естественно, проверку данных в поле нужно делать при вводе (при изменении состояния поля), а не при начале расчета. А я думаю, что у меня за мышиная возня вокруг простых текстовых полей.
Спасибо, rami, JohnSUN.

По поводу переменных, там ещё вагон и маленькая тележка, мне например не нравиться что куча переменных вынесено в шапку, куча переменных не определено, куча лишних переменных, которые вообще по факту не нужны.
Но когда пилил код для диплома, помню, у меня была проблема с передачей в функцию трёх переменных. Две - нормально, три - кукиш. Думаю просто от усталости не догнал почему.
Ещё, по уму бы, нужно кучу этих массивов заменить на одну структуру...
Так что с переменными там путь долгий ещё.
rami, но конкретно этого я не заметил, видимо там массив переопределяется, спасибо.

И вот с этим вопрос, почему он в этом месте, зараза, творить что хочет? Если мне не изменяет память, массив, обычно заполняется с первого элемента и до того, которого может, оставляя остальные в состоянии пусто.
Или я со своей документацией уже начал забывать как программировать?
Даже если я выставлю Base 1, то это всё равно не спасёт, так как массив меняет количество элементов. Я так предполагаю, отладка начнётся с нуля, когда я выставлю Option Explicit.
(x86_64) Kubuntu 16.04.3 - LibreOffice 6.0.2 / 6.1 alpha

rami

Цитата: tagezi от  2 июля 2016, 10:53Но когда пилил код для диплома, помню, у меня была проблема с передачей в функцию трёх переменных. Две - нормально, три - кукиш. Думаю просто от усталости не догнал почему.
Некоторые Офисные функции передают 30 параметров, а функция SUMIFS даже 61. Я пробовал передать 15 параметров, всё нормально. Естественно есть особенности: иногда нужно передавать переменную по значению ByVal, иногда опционально Optional
Цитата: tagezi от  2 июля 2016, 10:53И вот с этим вопрос, почему он в этом месте, зараза, творить что хочет? Если мне не изменяет память, массив, обычно заполняется с первого элемента и до того, которого может, оставляя остальные в состоянии пусто.
Массив с известной размерностью можно заполнять в любом порядке, но обычно удобно заполнять перебором индексов по порядку в цикле.
Цитата: tagezi от  2 июля 2016, 10:53...видимо там массив переопределяется.
Да, переопределяется, поэтому нет смысла задавать ему размеры изначально, это только сеет смуту и сбивает с толку. Но учти, что массивы передаются  по ссылке, а не по значению. Питоньяк об этом хорошо написал.