Вопрос может уже и поднимался, всего не упомнишь.
Можно, конечно, все параметры собрать в одну строку, разделив запятой (или другим разделителем). Но какое-то некрасивое решение.

Может стОит и о самой задаче рассказать. Написал в глобальном oApp метод ToCollection, который переданные ему параметры помещает в коллекцию. Для чего? Для того чтобы однотипные вызовы с разными параметрами обработать перебором коллекции.

Вот и застрял, как это красиво сделать, если не на бесконечном числе параметров, то хотя бы под 100, а то 26 явно мало.

А если передавать параметры "транспортным" курсором? Принял, обработал,закрыл.
Вся мощь СКЛ, команды скан и прочее в Вашем распоряжении для обработки.



Исправлено 1 раз(а). Последнее : wow1970, 06.12.17 21:18

У меня сделана передача через курсор - XML - вызов обьекта with XML - курсор.

Коллекции - замечательная вещь!
Может для вашей задачи подойдет следующее решение.

Есть классы различных контролов (текстбоксы, комбики и т.п. и каждому КЛАССУ присвоен типа ИД) у которых есть ОБЩЕЕ свойство - имя КЛАССА управляющей ими колекции. Т.е. их "начальник".
Колекция естественно тоже оформлена классом.

В ините КОНТРОЛОВ проверяется есть ли объект коллеции (как обжект).
Если нет, то самый первый ее "зовет" (создает) и в нее "прописывается". Готов к выполнению задач так сказать. Остальные "подчиненные" уже прописываются в существующую в памяти колекцию. Контрол в Ините записывает в СВОЕ свойство уже ссылку на коллекцию типа обжект.

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



Исправлено 6 раз(а). Последнее : wow1970, 06.12.17 23:23

Большое число параметров в метод передают массивом (по ссылке) или объектом (со свойствами) в частности той же коллекцией, если числа параметров заранее не известно, и если они по сути "равноценны".

Не понимаю смысла метода помещающего "параметры в коллекцию".
Чем не устраивает писать там где это нужно
Всяко логичнее и нагляднее какого-то
oCol = goApp.ToCollection("строка на 5 листов")
или
oCol = goApp.ToCollection(p1,p2,p3,...p100500)
опять же занимающего кучу места, и "очень удобного" в плане добавить/убрать нечто из середины, или переставить местами элементы.

wow1970
А если передавать параметры "транспортным" курсором?

Методы goApp как правило работают в первой (основной) датасессии, тогда как формы работают в своих отдельных датасессиях. Так что передать курсор не выйдет (в общем случае - в частных случаях это, конечно, можно делать). Городить огород с постоянными таблицами, или с курсор-XML-курсор - имеет смысл весьма нечасто. И уж точно не для "передачи параметров".
Конечно же в принципе можно и отказаться от goApp, банально создавая там где требуется экземпляр объекта с этим самым методом ToCollection - тогда он будет работать в той же DS и все курсоры увидит. НО это будет иметь смысл если нужные параметры-данные УЖЕ находятся в курсоре. Делать специально курсор, наполнять его записями, вызывать метод какого-то объекта лишь для того чтобы получить коллекцию... Ну если сказать мягко - бредовая идея. Т.к. приведенный выше код из createobject("Collection") и набора .Add() - логичнее, короче и проще. С тем же конечным результатом

Транспортным курсором и параметрами не пользуюсь. Пользуюсь 2-м решением "начальник колекция -подчиненый контрол". Вопрос был как красиво обойти ограничение на 26 параметров вот и предложил. Параметры - это стиль фокса под ДОС, свойства объектов значительно лучше.



Исправлено 1 раз(а). Последнее : wow1970, 06.12.17 22:04

Вот, например есть колекция для Гридов.
Каждый себя в коллекцию прописал вишеописанным способом.
Вот для примера вырезан один из методов колекции.




Исправлено 2 раз(а). Последнее : wow1970, 06.12.17 22:20

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

Глобальная сущность тоже водится. Стартовый класс от ЕМПТИ.
Колекция создается до гридов.
В класе грида прописано.
lcCollName = 'oApp.oColGrids'
Но это не столь важно. И грид может заставить oApp ее "запустить".
Глобальная переменная у меня как положено всего одна - oApp.
БиндИвент тоже использую и ассигн.
С биндивентом у меня другая ассоциация - он подсматривать за чужим поведеннием и попугайничает. Типа увидел что горит костер - стучи в бубен.



Исправлено 2 раз(а). Последнее : wow1970, 07.12.17 01:16

Igor Korolyov
... Городить огород с постоянными таблицами, или с курсор-XML-курсор - имеет смысл весьма нечасто. И уж точно не для "передачи параметров"...

Да ладно

У тебя разве нет кнопки "Создать дубль документа" или "Док. на основании"?

Если есть, то как ты во вновь созданный документ курсоры Мастер-Детали на 100500 записей переносишь из дока "донора" или заставляешь юзера заново всё вводить руками?

Можно, конечно использовать другой путь, типа вордовского "Сохранить как", записать на сервер док. под другим ID, а затем вызвать его на редактирование, тоже решение.

Зачем все утрировать? Для всех текстбоксов не надо.

Для каждого контрола колекция не создается.
Токо для контролов решающих ОБЩУЮ задачу.

Например задача ПОИСКА. Вот пример.
Допустим 10 контролов - 10 условий.

Начинать можно искать заветное с любого.
Как только в первом (любом из 10) что-то выбрали- Колекция обрабатывает и раздает другим источники.
Таким образом уже не получится выбирать во 2-м контроле ПРОТИВОРЕЧАШЕЕ условие которое не будет найдено. Получается поиск с уточнением.

Например выбрали город, остались улицы ЭТОГО города, затем выбрали улицу, дома - тоже не какие зря.

И лучше чем этот способ не видел.
Да это сложно запрограмировать как класс. И это работает медленнее чем просто набор контролов в котором можно навыбирать чепуху и потом нажать кнопку "НАЙТИ".
Пользователь получает сообщение что не найдено и начинает чесать репу - почему жеш.
На страдания пользователя уйдет значительно больше времени чем на выборку источников для контролов.

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

Но теперь коллекция не опрашивает 2 явных контрола-возмутителя и те шо уже задисаблились ранее. Типа оптимизации получается. При чем 1-й уже для выбора тоже не доступен. В каком порядке условия ставились так и снимаются НО в обратную сторону.

Причем пользователь может продолжать искать до единственной записи, а может решить что ему подходит група. По сути получается фильтр.
Вот для этих записей/записи он теперь шото полезное сделает. Удалит например.

Написал ГОРУ кода. Так как все абстрактно из-за классов.
Зато теперь выставил свойства и все. Наследование как никак.



Исправлено 6 раз(а). Последнее : wow1970, 07.12.17 00:12

PaulWist
У тебя разве нет кнопки "Создать дубль документа" или "Док. на основании"?

Есть.

Цитата:

Если есть, то как ты во вновь созданный документ курсоры Мастер-Детали на 100500 записей переносишь из дока "донора" или заставляешь юзера заново всё вводить руками?

Однако... Всегда хватало ссылки на копируемый документ, через которую новый документ и заполняется.

Цитата:

Можно, конечно использовать другой путь, типа вордовского "Сохранить как", записать на сервер док. под другим ID, а затем вызвать его на редактирование, тоже решение.

Угу. Уж всяко не передавать кучу курсоров. Это ж надо так извращаться...

Сделай коллекцию одним из допустимых типов параметров и, если хочется все поместить именно в одну команду, можно будет писать:
или

Во втором варианте все 100 параметров будут написаны последовательно друг за другом, так что визуально это будет почти как 100 параметров у одной функции.

Дополню akvvohinc
А мне нравится Empty.
Ты ж где то берешь эти параметры.
Так запихни их все в Empty. Вот из 100 и получишь 1.
В том числе курсор легко запихивается.

Удивила фраза

wow1970
Параметры - это стиль фокса под ДОС

Что то попутано?
Читал не внимательно)

ssa
Всегда хватало ссылки на копируемый документ, через которую новый документ и заполняется.

+100500




Исправлено 2 раз(а). Последнее : Аспид, 07.12.17 08:16

ssa
Если есть, то как ты во вновь созданный документ курсоры Мастер-Детали на 100500 записей переносишь из дока "донора" или заставляешь юзера заново всё вводить руками?

Однако... Всегда хватало ссылки на копируемый документ, через которую новый документ и заполняется.

Цитата:

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

Да, использование кучи параметров - наследие стиля програмирования для фокса 2,6.
Когда их десятки так точно. В базовых классах контролов не более 5.
Лучше использовать свойства и методы классов.

PaulWist
Если есть, то как ты во вновь созданный документ курсоры Мастер-Детали на 100500 записей переносишь

Они обычно в одной датасессии, и данные видно напрямую, безо всяких "переносов". Фокс не C, и данные обычно в курсорах а не объектах, потому если они нужны "совместно", то и держать их надо в одной DS, а не гонять туда-сюда всякими разными хитрыми способами.
В любом случае это будет исключением, а не правилом касательно параметров. Ни 100500 параметров, ни XML для 99% случаев "вызова метода" не требуется.

wow1970
Токо для контролов решающих ОБЩУЮ задачу.

Такое обычно делается в рамках формы, или нескольких, но не "глобально" на уровне всего приложения. Потому и не нужен "глобальный" объект-координатор. А на форме - да наздоровье. Не хочешь чтобы сама форма знала про эти текстбоксы (т.е. где-то там было прописано ThisForm.containerSome.pageframeOther.pageOne.textboxCity...) используй инверсию - пусть сам контрол себя пропишет в коллекции формы - но глобальная окллекция на всё приложение в этом случае точно не требуется. Пример с цвето-шрифто-оформлением как раз обратный - он именно "глобален" а не ограничен одной бизнес-функцией... Опять же, к вопросу передачи параметров это не имеет отношения.

Аспид
А мне нравится Empty.

Он подходит для разно-смысловых параметров. Т.к. у каждого из них будет своё "имя". Если все параметры по сути равнозначны (как, к примеру, для функции MAX) то "имя параметра" излишне, смысла в p1,p2,...p999 нет - и тут логичнее использовать коллекцию без ключей или массив. Тупо набор значений, каждое из которых равноправно - ну разве что их "порядок" имеет значение...

Лично я сторонник создания методов с осмысленным названием, в которые ИНОГДА передается пару параметров. Их и вызывать.
Если методы не могут прочитать что-то самостоятельно из других объектов, то тогда нужны параметры.
Если внедрять в форму что-то временное/разовое то можно прибиндить ЭТО к свойству/методу. Хорошо тем, что не придется переписывать уже сущестующее.

Параметры потом разбирать придется. Хорошо если в кейсах, а если в стиле 10 вложенных If то кошмар.

Igor Korolyov

PaulWist
Если есть, то как ты во вновь созданный документ курсоры Мастер-Детали на 100500 записей переносишь

Они обычно в одной датасессии, и данные видно напрямую, безо всяких "переносов". Фокс не C, и данные обычно в курсорах а не объектах, потому если они нужны "совместно", то и держать их надо в одной DS, а не гонять туда-сюда всякими разными хитрыми способами.
В любом случае это будет исключением, а не правилом касательно параметров. Ни 100500 параметров, ни XML для 99% случаев "вызова метода" не требуется.
...

Похоже плохо описал.

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

PSS ладно, посмотрим что Серёга нарисует.