В Delphi можно организовать проверку по условию, чтобы часть когда включалась в программу только если есть к примеру какой то модуль подключенный в программе?

пример:

в программу добавлены Unit1, Unit2, Unit4
на форме есть кнопка с тремя частями кода. Хочу чтобы одна из частей когда не игнорировалась компилятором, если в программе отсутствует подключенный модуль Unit3.

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

Дерективы описанные в этой теме http://forum.vingrad.ru/topic-157380.html могут проверять как то наличие файлов?

Это сообщение отредактировал(а) gesper - 1.1.2013, 17:34

Можно, но по другому.

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

Описание задачи я дал - внутри формы иметь возможноть компилировать при отсутствии нескольких модулей. Пример, это программа с своей БД и отдельно выполненная программа с тем же окном БД для ее заполнения. Если директивы на ваш взгляд не лучшее решение, то какие есть предложения, как вы такие ситуации решаете(на примерах)? Чем не лучше указаный вариант?

Добавлено @ 02:49

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



Это сообщение отредактировал(а) gesper - 2.1.2013, 02:51

зачем у тебя uses файла, который не используется?
а если используется — нормален ли код, который не получит доступа к unit3?

Добавлено через 19 секунд
и вопрос века — что же в себе содержит unit3?

Извини, что носом тыкаю, но два раза сказал


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

Поясняю: Есть форма, из которой управляетса содержимое, ну к примеру, 3-х классов. Есть идея иметь отдельно некоторые функции программы, в виде маленькой программы. Естественно, что форма будет требовать unit-ы которые относяться к полному функционалу, что нам не нужно. Через директивы компилятора это в принцыпе очень удобно получилось реализовать. Просто и удобно. Действия программы уже были на функции разбиты и заключить их в условия компилятора не составило трудов. Вот так.

unit1,2,3 - это описания разных классов и их функции.

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

Это сообщение отредактировал(а) gesper - 2.1.2013, 14:45

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

Я делал по другому. Сделал несколько проектов с разными именами и в Defines/Conditionals каждого записал разные наборы условий. Из этих проектов составил группу проектов. Теперь если изменяется один из общих модулей делаю Build all projects.

Понимаю о чем ты, но сформулировать сложно почему так делаю.

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

Многие программы страдают тем, что используют типовой инспектор обьектов работы с БД, и недают пользователью удобного интрефейса управления данными. Либо мы даем программе модули, где сказано в чем отличия классов, либо получаем неработающую форму редактора, или неудобную форму редактора. 


я так же, только модули общие в папке "general" и сгруппировать не успел еще проекты, поскольку прорабатываю менеджер работы с БД, а потом нарасчивать функционал начну.

Вы не "въехали" в вопрос/сабж.

northener, можешь пояснить?

Постараюсь.
Вот есть у меня проект. ПО работающее с неким внешним железом, показывающее его состояние, посылающее ему команды по требованию оператора, полующее и анализирущее ответы железа.  К этому ПО желательно иметь демоверсию, которая выглядит и "работает" абсолютно также, но не работает с реальным железом, а симулирует такую работу. Кроме того есть т.н. дополнительное рабочее место. ПО, которое выглядит также как основное, показывающее реальное текущее состояние железа, но не управляющее этим железом. Все три программы имеют почти одинаковый набор модулей/дочерних окон. Как мне удобнее всего организовать поддержку такого ПО? Имхо с помощью условной компиляции.

в данном случае идеально работать с железом(драйвером его, видимо) не напрямую, а через оболочку-прокси(спец класс). 
эта оболочка-прокси имеет три класса наследника: полноценная работа, рид онли(когда управляющие сигналы просто глушатся) и эмулятор.
условная компиляция в данном случае действительно пригодится для автоматизации билда, но будет не на уровне подключения модулей, а в фабрике/фабричном методе, генерирующем объект-прокси того или иного класса в зависимости от переменной окружения(к примеру, если target=DEMO, то driverProxy = TSimulatingDriver.create();)
даже если нужны немного другие наборы классов/окон, лучше сделать одну фабрику, чем по всему проекту распихивать логику сборки в виде операторов условной компиляции. 
собственно, для того фабрики и используются ведь — чтоб инкапсулировать логику генерации в одном месте.
П.С. понятно, что специфики проекта я не знаю. но по-прежнему кажется, что лучше такие проблемы решать архитектурно, а не "в лоб".

Заметьте, что я сказал "имхо лучше", а вы сказали то, что я выше процитировал. Очевидно что в подобных случаях общего единственно верного решения просто быть не может!


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


На самом деле если хорошо продумать архитектуру проекта, то "распихивание по всему проекту операторов условной компиляции" не такое уж ужастное/громоздкое занятие. Но вот только проблема - где взять грамотного "архитектора проекта"?


Это сообщение отредактировал(а) northener - 4.1.2013, 01:37

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

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