forum.clarionlife.net

Старое приложение (C6.3), локальная сборка (один exe файл), решил переделать в приложение с dll (C10). Глобальные данные пытаюсь перенести в dct, чтобы были видны для всех dll, но как быть с глобальными данными которые остались в приложении? После переброски в dct, они в приложении присутствуют, но не поддаются удалению Замкнутый круг Прошу Вашей помощи

Как вариант выгрузить в TXA, грохнуть там всё лишнее и загрузить TXA в пустое APP.

gopstop2007 писал(а): но не поддаются удалению

Вот этого не понял. Как так не поддаются удалению?
Такое по идее может быть только в случае если их шаблон добавляет. При удалении таких глобальных переменных, шаблон при компиляции, опять их добавит. Но в таком случае нужно c шаблонами разбираться. Кого из них в главную DLL переносить.

gopstop2007 писал(а): Старое приложение (C6.3), локальная сборка (один exe файл), решил переделать в приложение с dll (C10).

Здесь конечно лучше бы решать задачу по частям.
Сначала трансформировать приложение в Multi-DLL, а потом перенести его из C63 в C10.
Оба процесса имеют свои нюансы, и непонятно где проблема ...

gopstop2007 писал(а): чтобы были видны для всех dll

Здесь не все так просто. Есть ограничения на использование данных с атрибутом THREAD.
Посмотри в справке раздел "Clarion 6 Migration Tips -> General Rules regarding your data and the new Thread Model" и далее.
Лучше всего разобраться с данными и разделить их как текст (кнопка DATA) между основным EXE и DLL.

Admin писал(а): Вот этого не понял. Как так не поддаются удалению?

Удалить то дает, но если выйти и зайти снова в апп видишь снова "удаленные" данные

Игорь Столяров писал(а):
Здесь конечно лучше бы решать задачу по частям.
Сначала трансформировать приложение в Multi-DLL, а потом перенести его из C63 в C10.
Оба процесса имеют свои нюансы, и непонятно где проблема ...

Я так и сделал . Но так как данным процессом занялся в первый раз то сразу столкнулся с многими вещами с которыми не сталкивался до сего момента. Например удивило, что данные не переносятся копированием, если в описании есть скобки ()

Здесь не все так просто. Есть ограничения на использование данных с атрибутом THREAD.

Спасибо почитаю

Дед Пахом писал(а): Как вариант выгрузить в TXA, грохнуть там всё лишнее и загрузить TXA в пустое APP.

Спасибо, я так понимаю, единственное решение . Ох и нелегкая работа тянуть бегемота из болота... Хотя подожду может еще кто чего предложит

gopstop2007 писал(а): но если выйти и зайти снова в апп видишь снова "удаленные" данные

То же самое, если удалить описание файла БД - он будет заново создан по описанию в DCT.

Ты используешь описание Global Data в DCT не по назначению. Эта возможность предназначена, для
проектов, которые состоят из большого кол-ва мелких Local EXE файлов, и в которых должен быть
ОДИНАКОВЫЙ набор таблиц БД и глобальных данных. В этом случае их описании выносится в DCT.

Для Multi-DLL эта схема не может работать в принципе. Потому, что если, например в DLL переменная
описана и под нее выделяется память, то в EXE обращение к этой переменной уже должно не выделять
память, а обращаться к области памяти выделенной в DLL. И поэтому описание в EXE и DLL одной и той
же переменной для общего использование будет разным. (см. атрибут EXTERNAL)
Ну это если совсем упрощенно объяснять.

Ну это если совсем упрощенно объяснять.

Спасибо за информацию, но для меня не всё понятно Например есть глобальная очередь, которая используется в 80-90% dll-ках и как это должно выглядеть?

gopstop2007 писал(а):

Ну это если совсем упрощенно объяснять.

Спасибо за информацию, но для меня не всё понятно Например есть глобальная очередь, которая используется в 80-90% dll-ках и как это должно выглядеть?

Заранее извиняюсь, если сейчас буду писать тривиальные вещи. Но что бы все прояснить:

MultiDLL проект - это не произвольный набор DLL файлов + EXE.
Поэтому просто "порезать" большой EXE на несколько DLL + EXE не получится.
Проект должен быть структурирован и более того, эта структура обязательно должна быть иерархической (не сетевой).
Т.е. нельзя, что бы из DLL 1 вызывался метод из DLL 2 и наоборот. Потому что при сборке каждого DLL будет требоваться
LIB файл с описанием методов в другом DLL (это можно обойти, но это уже совсем другая история).
Это относится как коду (вызов процедур), так и к данным.

Теперь конкретно по вопросу. Если есть некая структура данных, то она должна быть описана в DLL самого низкого уровня.
В DLL (или EXE) более высокого уровня эта же структура описывается с атрибутом EXTERNAL с указанием модуля в котором
она описана на нижнем уровне. Но это в теории.
Здесь еще есть зависимость от того имеет ли структура данных атрибут THEREAD.
Посмотри раздел справки "EXTERNAL - Thread Considerations" - в принципе все описано.

Игорь Столяров писал(а):Здесь еще есть зависимость от того имеет ли структура данных атрибут THEREAD.
Посмотри раздел справки "EXTERNAL - Thread Considerations" - в принципе все описано.

Я так и использовал в C6.3, но потом заметил, что если эти данные использовать в dct в Globals , отпадает необходимость "дублировать" данные в dll с атрибутом EXTERNAL. Не буду утверждать, что мое решение верно и поэтому интересовался последствиями данного решения

Эти вещи разруливаются на уровне шаблонов. В заглавной dll делаются обычные декларации глобалов (таблиц или переменных из dct), в других dll/exe в шаблонах ставится флажок, что глобалы объявлены в другой dll и декларации создаются с атрибутом external. Тредность без разницы, ее надо при работе учитывать.

gopstop2007 писал(а): Не буду утверждать, что мое решение верно

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

finsoftrz писал(а): Эти вещи разруливаются на уровне шаблонов. В заглавной dll делаются обычные декларации глобалов (таблиц или переменных из dct), в других dll/exe в шаблонах ставится флажок, что глобалы объявлены в другой dll и декларации создаются с атрибутом external. Тредность без разницы, ее надо при работе учитывать.

Абсолютно верно ! Но есть настоятельные рекомендации не использовать составные структуры EXTERNAL без атрибута THREAD.
(т.е. данные к которым есть доступ из всех потоков в MultiDLL). Наверно по тому, что она будет использовать STATIC память ...

Я использую несколько глобальных очередей, объявленных в словаре, без thread. Только для внутрисистемных нужд. Работа с ними оформлена в специальные процедуры и использует критические секции плюс глобальный флажок (для надежности). Тестировал жестко, проблем нет.
В общем случае, конечно, использования глобалов без thread нужно избегать.

Да, потому что если использовать Global Queue для пользовательских данных (с неконтролируемым объемом) - это чревато проблемами.
Но мы решаем этот вопрос по другому.
Структура данных (QUEUE) "заперта" внутри DLL, но ее данные можно использовать с помощью методов, которые
вызываются уже из этого DLL другими модулями. Причина еще в том, что в Clarion есть система семафоров для
избегания конфликтов как раз при использовании таких данных и ее удобно использовать при обращении за данными
GLOBAL QUEUE через методы работы с ней, а не напрямую.