Galkov, не будем перевирать написанного:

при желание возобновить обсуждение предлагаю перейти в другой топик, а в этом воздержаться от своих комментариев по поводу изменения палитры св-тв.


таким, что св-во Icons выносится во вторую вкладку св-тв и далее пользователь отмечая её(т.е. делая видимой на основной палитре св-тв) галочкой говорит компилятору о том, что желает использовать иконки.

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

nesco, о каком усложнение кода компонента можно говорить, если даже интерфейсных методов для такой техники нет? Да и в любом случае через какое место это не реализуй в FTCG все сведется к замене одного оператора на другой. Поэтому твои опасения даже в случае их оправдания это некий очень частный пример, который серьезным минусом являться не может... Другие там минусы имеются, поважнее этих.

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

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

Вспомнил я в этом топике, потому-что ИМЕННО ЗДЕСЬ появилось предложение о введении св-ва UseЧего-то
Будет другой топик, в котором опять придумаем этот "всем понятный" Use - будет логично вспомнить и там, мне кажется
Как бы, я сразу прошу прощения за будущее напоминание

Вот есть строка Replace.
И хоть пустая она, хоть нет - это не то же самое, что ее отсутствие (отсутствие замены вообще)
Я что ли виноват, что это так, и что никакой FTCG не поймет разницы между таковой пустой строкой, и ее отсутствием
Пока ему не влепят UseReplace (присмотрись-ка к своей цитате про FTCG)

А мое предложение заключалось просто в ином интерфейсном решении, и обобщении того что мы и так делаем регулярно (а вовсе не в ведении новой сущности)
Предлагаю я НЕ вводить новое св-во UseCtrl3D (несмотря на всю его "понятность"), НЕ делать его листом для троичной логики (типа True, False, None), а сделать возможность этого "Use" для всех св-в всех элементов

А то до смешного ведь уже дошло
"Продвинутые" программисты просто пишут
И все. Не очень даже зная всех св-в формы, KOL-ом предоставляемых
А вот программист на HiAsm должен пролистать для MainForm аж кучу св-в (хотел было посчитать, но плюнул)
Разбираясь при этом, где играть, а где рыбу заворачивали

Вот мое предложение, грубо говоря, в том и состоит: оставить только это 'Ха-Ха-Ха', а остальное - в "невидимось"

------------ Дoбавленo:


А на мой взгляд, это база, на котором построен KOL.
Это, грубо говоря, одно из его отличий от VCL
И является не минусом, а плюсом -- на мой уже взгляд

Строка выше - 20К кода
Добавь еще одну "нейтральную" строку
получишь +еще около 1К
Прибавишь "прозрачность"
уже и считать не хочется

А ведь мы прибавляем. И чем больше мы прибавляем, тем дальше мы отходим от преимуществ KOL, приближаясь к VCL, но с худшим качеством

Вот тебе и весь сказ

никаких директив нет и не скоро планируется. Поэтому о каком усложнение "уже сейчас" идет речь я не понимаю.

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

Удивил

Ну и ладно, вводите св-ва UseProperty
С таким примерно хинтом


Вот только зря ты не обратил внимания на то, что я не придумывал ничего, а излагал реально происходящее
И излагал не от того, что моей правой ноге так захотелось, а потому, что нечто произошло.
Причина была.
А реально произошло следующее:
У нас кое-где было реальное отключение видимости
Именно было, и именно реальное
Но, в 168-й - оно пропало.

И это уже не перемалывание чего-то там, это совершенно реальные действия
Поэтому, я позволю себе уточнить: не только это в корзину выкинуто (что еще можно пережить), а и еще кое-что полезное
Как бы я попросил, не забывать про таковое выкидывание
Причина
Да просто кто-то считает, что этого не может быть, потому-что этого не может быть никогда
И вместо аргументации - "перемалывание", и не с моей стороны

А это тогда что

И вот это в придачу



Dilma, хочу еще маленький вопрос задать -- а для чего ты откатил иконку СD-ROM, она тебе не понравилась

Galkov, см пакеты Web, QT - без напрягов пользователя сущностями "ЕСТЬ" и "НЕ БЫТЬ" можно обойтись и один из вариантов этого обойтись я уже излагал. Предложенный UseProperty это одно из конкретных решений конкретной задачи г-на nesco(всего их было три, если уже успелся позабыться сей факт), подробности которой мне не известны в такой степени, чтобы предложить что-то еще.


ну я не зря предлагал упорному в своих суждениях г-ну Galkov - у перенести свои высказывания в другое мето - вот и получили путаницу. В топике имеется паралельное обсуждение двух тем - одна связана с интерфейсными изменениями в среде и введение для св-ва состояния "не определено", а вторая с защитой кода от нежелательных действий пользователя.
это - пример того, как надо оформлять все куски, которые расчитаны на использование элемента новичком. Не думаю что так сложно вставить пару скрок, которые в большом проекте могут привести к заметному увеличению производительности для тех, кому это реально нужно. Вторая линия дериктив _ERROR_XXX_ это решение давней проблемы, на которую так же не однократно жаловались - не всех устраивает выдача диалоговых сообщений в кодах элемента. Использование уровней защиты кода и сообщений об ошибках решает вот такие вопросы однозначно:

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

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

Да нет, не сложно, можно конечно и вставить, но постепенно, не все сразу, а то и так шарахаюсь от одной задачи к другой -- тут одно всплывет, там другое.

А по иконке ты мне так и не ответил

------------ Дoбавленo:



Нет не является, я пытаюсь свои дополнения максимально приблизить к пользователю, но не всегда получается к начинающему
По моим дополнениям я всегда отвечаю и показываю примерами пользователю

исправлять уже существующее - не к спеху. Но вот вставлять все новое нужно уже с учетом этого факта. Чтобы двойную работу потом не делать.


увлекся составлением трактатов... Иконку с диском когда-то давно рисовал в максе, она конечно не верх совершенства, но зато уникальная и своя.


пакету Delphi к сожалению судьбой предначертан экстенсивный путь развития(не смотря на все наши костыли, которые мы время от времени придумываем), и если над каждым своим дополнением 10 раз не подумать, он в итоге будет пораждать только громоздкие неповоротливые програмы и ничего более.
Напомню тот факт, что стандартная палитра сейчас по производительности в 2-3 раза меньше чем скрипт на Basic

Позволю себе открыть великую тайну: ПОСМОТРЕЛ
И именно посмотревши, утверждаю:

Также, как и не поймет он что св-во Icons следует игнорировать, или создавать пустым, пока не будет UseIcons
И не понимаю, почему эта ПРАВДА упорно не доходит
И чье здесь упорство, все-таки

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


Не надо предлагать, надо сделать
Из, в очередной раз, не услышенного:

Появились лишние коды, приводящие к некоторой кривизне
Это сделано не мной
Вот и примените "эти варианты" чтобы коды "вернулись на место"
Пускай мои предложения пойдут в корзину (а они были напралены именно на это) - давайте свои, воплощенные в жизнь

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

потому что готовые решения хороши для поребителей, а не производителей. Поскольку я себя все таки в данном случае отношу ко второй категории, то и ожидаю нормальных доводов и примеров, а не слов о безусловности правды и абстрактных сравнений с градиентом дивергенции. Ничего кроме желания возражать такой стиль изложения возможно и правильных мыслей не вызывает. Боюсь, что и эта ПРАВДА упорно не доходит. И никак не понимаю смысл продолжения сей беседы - в чем он?


nesco, пока делал примерный вариант элемента ImageList, который через data_element приделывался к ListBox, то возникла идея сделать некий набор элементов, по технологии схожий с SiteBuilder в WEB. Т.е. скажем уже сейчас выделяются например такие части - ImageList(база иконок и изображений для элементов), FileProcessor(элемент сохранения и загрузки данных - сейчас он представлен точками doLoad, doSave и doClear, а так же св-ом FileName), DataManager(элемент для доступа к данным компонент). Сами интерфейсные элементы выступают в качестве ViewManager(т.е. ядра отрисовки на экране и взаимодействия с пользователем). При таком раскладе каждый элемент содержит только самые часто используемые точки и св-ва - все остальное к нему приделывается с помощью менеджеров.

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