Здравствуйте!
При выключении создаваемой программы выскакивает ошибка "Exeption in module (адрес ехе-файла) at 00014762 Access violation at address 0014762 in module(имя ехе-файла). Read of address 00000002".
Причем, ошибка появляется по нелогичным причинам. Например, в схеме есть Hub, не подключенный ни к одному из элементов. Программа работает без сбоев, если не трогать этот Hub. Если же его удалить, выскакивает ошибка.
И таких странностей много.
Может это кто-нибудь, если не объяснить, то, хотя бы прокомментировать?

Могут быть ошибки в компонентах, может быть неправильное использование компонентов (например, с параллельными потоками). Без схемы ничего невозможно ни сказать, ни исправить.

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

Проблема не в Hub. Проблема в остальной схеме, которая проявляется в зависимости от наличия хаба.

Ась

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

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

Методом, близким чуть ли не к экзорцизму, проблему удалось решить. Но при дальнейшей работе вновь наткнулся на подобную ситуацию. И вы знаете, ваше предположение оказалось верным: объект, не желающий удаляться (а был и объект, не желающий устанавливаться) переместил на задний план. Сработало.
---
Спасибо!

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

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

ОК.

Прошу прощения за резкость... Но того, кто реализовал бы Ваш сценарий, к программированию вообще подпускать нельзя.
Вы на этом настаиваете, Netspirit ???

Да мы не намного лучше, если до сих пор не заметили этой банальности.

Какой именно сценарий? "Узнавание клиентом о том, что менеджер уничтожен"?

Активизация клиент-серверных связей из деструктора.
Вы описали именно его.

Не только. Ещё "Активизация клиент-серверных связей" из пераллельного потока (Thread, MMTimer, возможно, BASS и другие компоненты, где есть потоки), в случае, если поток не останавливается перед закрытием программы (а узнать о закрытии внутри кода нельзя; только если пользователь по событию закрытия формы сам остановит работу компонента, если в нём такая возможность предусмотрена).

Кроме того, не факт, что у нас во всех клиентах-менеджерах в деструкторах это предотвращено. Например, в hiMST_UseEditCtrl.pas есть

Если не ошибаюсь, то при уничтожении менеджера перед клиентом в WndProcTabGrid клиента прилетит сообщение WM_DESTROY. В данном случае ошибки, вероятно, не будет так как и менеджер ещё существует и в клиенте сообщение WM_DESTROY никак не обрабатывается, но налицо "Активизация клиент-серверных связей из деструктора".

И да, если в процессе уничтожения менеджеры сделают клиетам что-то типа Client.NotifyDestroy(Self), а клиенты в этом методе подчистят всю работу с менеджером (без задействования внешних точек), проблем не вижу. При этом, клиент в своем Destroy() уже точно будет знать существует ли его менеджер ещё или нет, и в случае существования тоже чистить свои следы в менеджере.

Редактировалось 2 раз(а), последний 2018-05-18 12:39:53

Отсюда и вопрос, можно ли назвать Программированием -- процесс создания кода, в котором присутствуют таковые "не факты"
В неизвестном до конца количестве.

Но это все теория...
Фактического материала не вижу, который должен приводить к аналогичным рассуждениям.
Чаще, к бредовым последствиям именно бред и приводит. Кривой Codegen, к примеру...