Заполнить таблицу через форму Dialog

[Кот]

sheets это имя свойства, и я бы не рисковал его использовать как имя переменной.

Я не против, если это можно изменить и поправить. Главное чтобы это работало.
Спасибо!

[bigor]

Я не против, если это можно изменить и поправить

ну так замените у себя в макросе переменную (хотя скорее это объект) sheets на что-нибудь другое, например oSheets

[Кот]

sheets

заменил на oSheets, заработала.
А как же дописать код чтобы таблица пополнялась через форму dialog?
Спасибо!

[bigor]

Смотрите пример в файле, изучайте

[Кот]

изучаю

Прошу уточнения в целях образованности и понимания
В коде есть цифра 10, что она обозначает?
Nstr – это любое значение в строке?
Я когда искал варианты для TextField, а надо было для getText, это одно и тоже или есть разница?

С формулами Вы меня привели в состояния шока. Как великолепно все написано.
Спасибо!

[bigor]

В коде есть цифра 10

Позанудствую, 10 это не цифра, 10 это число. Это часть адреса ячейки(K1), где хранится номер следующей строки, который присваивается переменной Nstr.
TextField это элемент формы, он имеет метод getText. По правильному в макросе меню  нужно было присваивать переменным oCntrl() значения текстового содержимого TextField

Код Выделить Развернуть

oCntrl(1) = oDialog.getControl("TextField1").GetText.
Скачайте книжку Питоньяка, ссылку на последнюю, которая на английском, sokol92, давал в вашей теме недавно. Если с английским туго, на форуме есть ссылки на более раннюю на русском языке.

[Кот]

В коде есть цифра 10

Позанудствую, 10 это не цифра, 10 это число. Это часть адреса ячейки(K1), где хранится номер следующей строки, который присваивается переменной Nstr.
TextField это элемент формы, он имеет метод getText. По правильному в макросе меню  нужно было присваивать переменным oCntrl() значения текстового содержимого TextField

Код Выделить Развернуть

oCntrl(1) = oDialog.getControl("TextField1").GetText.
Скачайте книжку Питоньяка, ссылку на последнюю, которая на английском, sokol92, давал в вашей теме недавно. Если с английским туго, на форуме есть ссылки на более раннюю на русском языке.

К сведению все принял. Спасибо за приятное общение. 
Буду продолжать мучиться дальше.
Спасибо!

[economist]

В некоторых случаях программирование Диалогов для ввода данных м.б. мучительным и долгим.
Хорошая альтернатива - отдельный "серый" лист Calс с имитацией всех контролов диалога. Такая форма ввода - легко создается и является динамической. Ее "разработку" можно вести одновременно.

Плюсы:
- кода обработки в десятки раз меньше, логику проверок можно реализовать формулами, проверкой данных итд
- реактивное программирование, все формулы, значения, статусы, метки - пересчитываются автоматически
- доступны все контролы (флажки, комбобоксы итд), но часть из них не нужна, т.к. можно сделать в ячейках
- можно использовать Условное форматирование, списки выбора из БД, ячеек книги итп LOW CODE
- красоту и формулы можно поручить не-программистам/юзерам с острым чувством "прекрасненького"
- нет проблем с мелким масштабом (Ctrl+колесо мыши меняют масштаб)   

Минусы (нет их - так, мелкие придирки):
- легко наверстать "дичь" из разных шрифтов и форматов
- псевдо-диалог не выровняешь по центру экрана для разных диагоналей/экранов
- лист отображается не модально, если уснуть на клавиатуре - можно ввести что-то невалидное.

[eeigor]

ИМХО, чтобы создать грамотную, а не топорную форму, сделать придётся очень многое: тут и навигация по записям, и переход к новой записи при взаимодействии с листом, и, возможно, фильтрация/поиск записей по условию...
Здесь и работа с диапазоном данных и обновление его размера... Да и открываться форма должна с выбором текущей (на листе) записи. И должна ли она быть модальной или нет? Так что, скорее всего, будет достигнут результат «с большими ограничениями».

По замыслу разработчиков лист электронной таблицы – это и есть то, из чего можно и надо сделать приемлемую форму для ввода данных (тоже требует усилий и, порой, программирования).

Полагаю, вся ваша дискуссия носит чисто теоретический характер.

Формы могут понадобиться для организации навигации между листами в приложении со сложной логикой, при разработке мастеров для решения непростых задач (в помощь) и пр.
Лист – это почти готовая форма! Разработка альтернативной, профессионально сделанной формы – задача, требующая достаточно высокой квалификации. Трудозатраты должны быть оправданы.

P.S. Каждая строчка макрокода снижает устойчивость приложения. В идеале – макросов нет совсем!

[eeigor]

@economist, вся беда в том, что легкость электронных таблиц только кажущаяся. Для того, чтобы сделать что-то путное, требуется высокая квалификация. Причём сразу по всем пунктам. И разработка альтернативной формы – задача тридесятая...

Ваш пост – косвенное подтверждение сказанному. Вы говорите с автором, находясь на другом (значительно более высоком) уровне обобщения информации...


P.S. Хотелось бы полюбопытствовать: что не устраивает автора при вводе данных непосредственно на листе? Может, текущая запись не помещается на экране (только с прокруткой) или выведено записей больше, чем одна, с которой надо работать, и это отвлекает? Что не так?

[economist]

сделать придётся очень многое: тут и навигация по записям, и переход к новой записи при взаимодействии с листом... Да и открываться форма должна с выбором текущей (на листе) записи.

Все это есть из коробки: Данные - Форма... Но юзеры не хотят пользоваться "Формой" (ни в Excel, ни в Calc), говорят что неудобно, что значения не цветные, нет проверки данных, нет пересчета вида 2*4=8. Эти хотелки в Диалоге на Basic реализовать можно, но сложно (особенно если действия оператора ПК хаотичны, например при одновременном разговоре по телефону), а в Листе Calc - легко, и оператор вправе сам эту "форму" для себя разработать.

Показательный и одновременно ужасающий пример: 1С УПП/ERP. Почти любой документ - это экран на три части. Вверху - шапка документа, ниже - табличная часть (вечно не влезают все колонки) и еще зона с несколькими(!) вкладками. И оператор кликает аки дятел по всему этому многообразию точек ввода, скроллит, расширяет, сжимает столбцы, устает, ошибается. Calc хорош тем что даже цветом оператор может выделить важное и тратить ресурс внимания правильно.

[Кот]

Смотрите пример в файле, изучайте

Всем добрый день!

Ребята, выручайте!
После оптимизации в школе, определенную нагрузку скинули на одного человека, хотя должны были заниматься 4 человека.

Помогите пожалуйста дополнить (изменить) код макроса в форме Dialog.

Пожелания были такими:
- после нажатии на кнопку ВВЕСТИ ТЕКСТ в форме Dialog под названием А с данными, данные очищались для заполнения следующих данных;
- при переходе от одного к другому по нажатию клавиши Enter;
- номер телефона чтобы отображался в формате +7-(000)-000-00-00;
- самое главное, при выборе номера класса в форме Dialog, данные должны появиться на соответствующих Листах (1А, 1Б, 1В, 1Г, .....11Г);
- в таблицах (на листах) сортировка данных по алфавиту.

Для меня задача эта НЕ выполнима (английский не знаю). Прошу помощи у Вас.
Буду рад любым примерам, ссылкам на примеры.

Спасибо!

[bigor]

Не понимаю как это

После оптимизации в школе, определенную нагрузку скинули на одного человека, хотя должны были заниматься 4 человека.

связано с этим

Помогите пожалуйста дополнить (изменить) код макроса в форме Dialog.

Решил без формы обойтись, смотрите, хотите переносите все на форму, только переход по Enter как нибудь сами реализуйте
Все красивости, проверки итп тоже сами. Так вроде всем 3-м 5-ти поставленным условиям удовлетворяет

[Кот]

Не понимаю как это

После оптимизации в школе, определенную нагрузку скинули на одного человека, хотя должны были заниматься 4 человека.

Добрый вечер!
Вести сопровождение платных услуг в школе, изначально было определено для 4 человек (сбор, учет данных желающих обучаться в кружках, ведение табелей учета, печать квитанций на оплату услуг, раздача квитанций и сбор оплаченных квитанций, формирование отчетов), а теперь все это делает один человек. (Оптимизация)
Спасибо!

[eeigor]

ОФФТОПИК
Беглый взгляд.
Данные организованы неправильно. Точнее так, чтобы потом пришлось много программировать и мучиться. Впрочем, автор и так мучается, о чем и пишет выше. Полагаю, что @economist меня поддержит в том, что все классы надо слить на один лист. Вверху добавить диапазон условий расширенного фильтра для получения данных требуемого класса. Добавлять прямо на листе. Порядок следования записей значения не имеет. Такие данные можно потом фильтровать, сортировать, анализировать в сводных таблицах, в таблицах подстановки с двумя входами (множественные операции), на диаграммах и пр.
Диалог для ввода данных, конечно, можно реализовать, но никакого смысла в этом нет.
Автор, выбрал трудный путь: не хочу изучать штатные возможности продукта (расширенный фильтр или там, не дай бог, - регулярные выражения, сводные таблицы, multiple operations)... А надо создать геморрой, чтобы потом его обслуживать с нашей помощью. Это влечет за собой нагромождение глупостей. Самое главное в том, что впереди у автора тупик. И что, никто этого не видит?

То есть пока я усматриваю только один единственный лист - "Классы". Все остальные следует удалить. Класс - это одна сущность (entity).

@Кот, для начала надо объединить все классы на одном листе. И все, кто дает вам советы, прекрасно это знают. Просто существует негласный уговор: автор спрашивает, форумчанин тупо-глупо отвечает строго на поставленный вопрос или проходит мимо. При этом "вина" за вопрос возлагается на вопрошающего, а отвечающий лишь оказывает услугу. Порочная практика. Так работает Ask (ask.libreoffice.org/).

UPD. Эффективное использование расширенного фильтра требует некоторой автоматизации (можно и вручную). Но это уже совсем другая история.
Из 167 строк кода пока не увидел ни одной, соответствующей условию "необходимо и достаточно".

В общем, проблема в том, что автор не учитывает, что хранение данных, ввод данных, вывод данных - это совершенно разные задачи с разными подходами. Автор предпочитает хранить данные в виде, удобном для их представления (вывода). Это ошибка. Данные при этом хранятся абсолютно не эффективно, и в дальнейшем это породит массу проблем. Но эффективное хранение данных потребует потом некоторых усилий и квалификации для их представления, коих (представлений) может быть великое множество, а не как у автора - только одно на листе класса. Вот этого автор и избегает. Скорее, не знает, как правильно. А правильно, повторюсь: данные лежат, так сказать, в "куче", порядок следования записей роли не играет. Красоту и стройность они приобретают только перед заданным выводом на экран или печать (и здесь может потребоваться макропрограммирование, но не обязательно). Лучше помогите автору преодолеть свой страх и перестать работать с электронной таблицей как с листом обычной бумаги.

Желательно, конечно, видеть задачу целиком, а не "выдергивать по нитке"... В сказке про Репку надо начинать с репки (с того, что дано), а не с внучки и не с жучки.