Есть кусок кода, который в таймере проверяет живы ли формы, указатели на которые сохранены в списке.
Проверка при помощи 
.
Если myFormP указывает на прибитую ранее форму, то возникает исключение:
Access violation at address 32AB2EA1 in module 'CC32100MT.DLL'. Read of address 00000017

Вопросы:
1. В чем причина исключения?
Я же не меняю данные, а просто пытаюсь узнать проходит ли приведение типов.
2. Чем грозит это исключение, если не побороть причину?
Сейчас dynamic_cast завернут в try ... catch. Работает. Но кто его знает чем это может обернуться...
3. Как правильно выполнять данную операцию?
Если применение dynamic_cast в этом случае недопустимо, то зачем же он вообще нужен. Хочю работаю, хочю не работаю.

Это сообщение отредактировал(а) ZVano - 15.4.2011, 12:09

ты обращаешься по невалидному указателю. dynamic_cast лезет в виртуальную таблицу (myFormP->v_fptr), а т.к. myFormP указывает не пойми куда, то и брать оттуда данные нельзя


это не есть правильно, потому, что try ... catch должен ловить пользовательские исключения, а не исключения обращения к несуществующей памяти.


Наврное для других случаев... http://lmgtfy.com/?q=dynamic_cast&l=1

Как ты думаешь, может стоило задать вопрос: "Как мне правильно сделать проверку живы ли формы ?", приведя при этом код создания, удаления и добавления форм в список ?

Возможно, ты прав. Но мне хотелось разобраться в причинах.
Предварительный анализ показал, что нужно воспользоваться API
IsBadCodePtr -  Определяет, имеет ли процесс права чтения памяти по указанному адресу
IsBadReadPtr - Определет, имеет ли процесс права чтения памяти по указанному диапазону адресов.
IsBadStringPtr - Определяет, может ли процесс использовать переданный указатель как указатель на ANSI-строку (заканчивающуюся символом с кодом 0). 
Функция проверяет, имеет ли процесс доступ к фрагменту памяти, который начинается от заданного указателя, и длина которого определяется первым вхождением символа с кодом 0, но не больше заданного количества символов.
 IsBadWritePtr - Определет, имеет ли процесс права записи в память по указанному диапазону адресов.
IsBadHugeReadPtr
IsBadHugeWritePtr

Копаю дальше...

Этот код не работает. Срабатывает "Форма жива" несмотря на то, что она совсем-совсем дохлая.


Таким образом универсальный способ проверки валидности указателей на произвольные данные не найден. Поиск продолжается.



Неуниверсальный способ (для форм) такой:

Код проверен и работает.
frmMain - главная форма с MDIChild окнами.
pagesForm - TTabControl в Objects которого хранятся указатели на MDIChild формы.
TabClose - пользовательский метод, закрывающий таб с указаным индексом.

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

Это сообщение отредактировал(а) ZVano - 15.4.2011, 15:58

Это, конечно, правильно и хорошо, но IMHO ты не туда смотришь...
причину я тебе рассказал, а вот обходить её "слева и справа" неправильно. Лучше сделать так, чтобы этой ситуации никогда не было, а именно после удаления формы занулить указатель и вместо dynamic_cast проверять указатель на 0.

Топикстартер наверное очередной дэльфист

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

У каждого варианта свои достоинства и недостатки.
Я выбрал 2й вариант и это мое IMXO. 


Так и есть.

borisbn - ихмо тебе уже все сказал, добавить нечего.

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



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

[ЯУОТЕ]не проще повесить обработчик на событие закрытия окна/вкладки/да чего угодно, и там вызывать [/ЯУОТЕ]


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


Блин. Сам флуд развожу  :-Д  Если есть интерес, можем обсудить этот вопрос в отдельной теме.

PS: Всем спасибо за участие в теме.

Это сообщение отредактировал(а) ZVano - 15.4.2011, 18:37

Отнюдь. Вы пытаетесь проверять валидность определенного класса окон. Для этого достаточно, что бы валидностью себя озадачились сами окна.

Хотя при таком подходе возможен сбой, если новая форма (созданная по new) ляжет на место старой (удаленной). Указатель на нее будет тем же, а вот <form ptr> может подразумеваться из 'прошлой жизни'   Это решается специальным полем в форме, со сквозным номером (ну и сохранение его вместе с <form ptr>)

Обсуждение плюсов\минусов различных подходов предлагаю обсуждать тут