lulgu
И это все, что вы можете предложить?

Еще один кредитор)))
Я вам что то должен?)

Аспид
Я сразу признался, что не пишу m. Ну не привык. Такой персональный стиль)))

В том то и дело что плохой стиль - как Олеговы PRIVATE ALL... Я ещё допускаю что можно не ставить m. перед обращениями к This/ThisForm - т.к. сравнительно несложно "запретить административно" создавать курсоры с такими именами (я и сам не ставлю, хотя понимаю что "злодей" создавший курсор с именем This порушит пол программы), ну а одноименные переменные сам фокс не позволит создать. Но полагаться на то что "уж точно не появится поля с таким именем, а если и появится то наверняка не в текущей рабочей области" - нельзя. Увы таков фокс - убогое наследие далёких предков вынуждает к таким корявостям как m. и избегание однобуквенных переменных.

Аспид
Можно было бы, коли это был бы 1 параметр.

Какая разница один он или их десять? Их (свойства) ведь даже не обязательно прописывать в классе - вполне можно добавлять динамически через AddProperty()

Аспид
Скажу более того, у меня уже эти переменные собраны в классе. Просто они в массиве класса.

Массив как раз тем и не удобен что элементы "безымянные" (даже если он многомерный и "человеческое имя" в соседней колонке со значением находится). А что мешает использовать подобъект на основе Empty класса, где и держать все эти параметры? Заодно такое решение позволяет и выносить сам SQLEXEC наружу класса (например в другой класс или "плоскую" процедуру) - передавай вместе со строкой и ссылку на этот объект, а в коде с SQLEXEC-ом обеспечь его видимость по "фиксированному" имени (т.е. там переменную со ссылкой на этот объект обзови в соответствии с тем как в строке запроса прописано - скажем если тамто переменную par и делай. Или спец-синтаксис в самой строке запроса придумай, который потом STRTRAN-ом заменит такой кусок на "правильное" имя объекта с параметрами. Ну типа <P>Discount...

Аспид
Коли запускаю какие то утилиты (прг) из класса... ну не бывает такого тупизма, чтобы пересеклись.

Просто ты ОДИН являешься автором всех буковок кода. Когда же работает команда, то абсолютно невозможно гарантировать что если "Вася" в одном модуле сделал приватную переменную nDiscount, то "Петя" в другом модуле, при том именно "по цепочке вызовов" не захочет такое же имя применить... Конечно, если хотя-бы один из них аккуратен и будет использовать LOCAL то проблемы не будет. Но лучше чтобы ВСЕ были аккуратны и просто не допускали теоретической возможности конфликта.
Кстати, даже когда ты один автор, то отслеживать "неиспользование такой-то переменной, т.к. она была задействована вот тут" весьма утомительно - а через 3-4 года, возвращаясь к своему старому коду... В общем лучше не раскладывать граблей даже на хорошо знакомой дорожке

Igor Korolyov
Кстати, даже когда ты один автор, то отслеживать "неиспользование такой-то переменной, т.к. она была задействована вот тут" весьма утомительно

Ну, я в таких случаях сначала придумываю переменную, а потом ищу ее при помощи Far. Ежели не найдена, то использую эту новую переменную. Но у меня FPD - там такой поиск "без проблем".

Игорь.
Ты прав в каждой букве!)
Про m. вообще все непременно)
Ну когда я пишу, то думаю несколько об ином, чем переучиваться писать)
Еще раз - ты прав. Я таким и останусь. Сознавая что это не верно.
С Приватом все несколько не так обстоит.
Я не один, в фоксе нас трое.
Писать стараемся одинаково.
Но... все же частенько по коду можно догадаться кто)))
Введены некоторые правила. Об опасности все знают.
Тут вообще, очень большой вопрос. О взаимодействии объектов.
Но, для читающих- начинающих. Я 100% не прав.

Igor Korolyov
Кстати, даже когда ты один автор, то отслеживать "неиспользование такой-то переменной, т.к. она была задействована вот тут" весьма утомительно - а через 3-4 года, возвращаясь к своему старому коду... В общем лучше не раскладывать граблей даже на хорошо знакомой дорожке

Практически все пишется так, что бы именно через 10 лет, легко было разобраться.

Все же попытаюсь отмазаться от обвинений))) (Не следуйте моему примеру)
Есть определенный набор классов, с правилами взаимодействия между ними.
Одним словом фрйемворк.
Про AddProperty() естественно знаем.
Пробовали, тестировали различные способы.
Решили сделать как есть (приват). (признаюсь конечно, 90% решения - это я)

Igor Korolyov
?m.par.Discount

- а вот это, навело на мысль, что можно было бы в empty это дело напихать. Красиво было бы.
Увы не догадались.
Думаю сейчас нет смысла что то менять.
Фох... используется для изменения логики в действующих приложениях.
Делать половину так, а 10% иначе, полагаю еще хуже.
В общем... как в дворовом футболе - заиграли)))

Народ, а как из класса вытащить форму и сохранить ее как форму в виде отдельных двух файлов?

Вопрос снимается.
Ответ был найден здесь:
forum.foxclub.ru

Владимир Максимов
Есть еще такой инструмент Tools \ ToolBox.
Если в него добавить свою библиотеку классов, то по нажатию правой клавишей мыши на иконке своего класса формы внутри ToolBox среди прочих пунктов меню будет пункт меню "Create Form". Т.е. создание формы на основе текущего класса...

Респек Владимиру!



Исправлено 1 раз(а). Последнее : descent52_tmp, 25.08.17 13:52

Вообще-то "вытащить форму" и создать форму на основе класса это далеко не одно и то же...
А создаётся форма на основе класса командойили с диалогом выбора Как по мне, так всяко быстрее чем по каким-то тулзам шариться