Forum Replies Created
-
Posts
-
Место возникновения может быть каким угодно. Да и в любом случае для исправления бага надо как то его идентифицировать, а значит нужен минимум лог, а лучше демка.
Это случайно не ваш глюк? А то ведь были уже случаи: http://www.alphaskins.com/forum/index.php?showtopic=4639
хотелось бы раскрыть потенциал поболее, вот и думаю как бы было здорово иметь интерактивную иструкцию типа:
Есть такая фича – делается так.
Ну или что то типа того, было бы здорово по моему.
Качайте главную демку, там как раз все возможности альф показаны.Сорри за оффтоп, С днем программиста, и с днем моего рождения <img src="style_emoticons//smile.gif” style=”vertical-align:middle” emoid=”:)” border=”0″ alt=”smile.gif” />)
С днюхой!Без дебаг-информации почти ничего не видно
Опять все нормально. Предлагаю поставить триалку EurecaLog, и запостить сюда лог.
Обычно такие ошибки возникают, когда неверный код затирает чужую память. Например освободили объект, а потом обращаемся к его методам, или пишем за границы массива и т д. В таких случаях все зависит от того, какой участок памяти портится. Если там ничего важного, то все проходит гладко, а если там код какой нибудь процедуры, или важные данные, тогда получаем ошибку как на скрине. С новыми альфами распределение памяти в вашей программе изменилось, и теперь портятся как раз важные данные. Попробуйте вырезать из проекта все лишнее, но так, чтобы ошибка сохранилась. Возможно тогда бага станет виднее.
Скорее всего проблемы у вас в коде, и то что их раньше не было видно – просто совпадение. Установите себе триалку EurekaLog, так их легче будет найти.
Похоже я немного не верно понял устройство вашего приложения. Но тем не менее, у меня скомпилированный вами пример при любых действиях нормально закрывается.
У вас, как я понял, ситуация сейчас такая:
Приложение собрано без пакетов, и содержит в себе юниты, необходимые TIdUDPServer. dll-ка тоже собрана без пакетов, и потому тоже содержит в себе эти юниты. Один из этих юнитов в секции инициализации содержит действия, которые приложение должно выполнять только один раз. Но поскольку этот юнит есть и в самом приложении и в dll, то эти действия выполняются дважды.
Чтобы такой проблемы не было, нужно чтобы и приложение и dll использовали один и тот же пакет, который уже будет содержать в себе нужный юнит. Пакет будет следить за его инициализацией.
А еще бывает, внутри юнитов объявлены глобальные переменные. И в случае, когда пакеты не используются, таких переменных тоже получается две.Пакеты по сути и есть dll-ки, только экспортируют несколько специальных функций. Количество и состав пакетов, которые будут подключены извне к приложению вы можете редактировать. Думаю, будет достаточно, чтобы приложение и ваша дллка в качестве внешних использовали только пакеты инди.
Этот список не поддерживается, рекомендуется его отключить. Заменить можно например этим: http://www.alphaskins.com/forum/index.php?…ost&p=19961
Эти диалоги не стандартные дельфовые формы, а окна созданные системой. Код в VCL лишь вызывает специальную системную функцию для их показа. Самая большая проблема с этими окнами в том, что их тяжело отличить друг от друга. То есть когда скинменеджер принимает решение о скинировании такого окна, он не знает, кто это окно вызвал. Поэтому и настройка по управлению такими окнами всего одна. Но вы то знаете, когда показывается ваше окно, а когда чужое. Перед показом своего диалога вы можете включать srStdDialogs, а после показа – выключать.
У скинменеджера есть свойство SkinningRules, если в нем отключить srStdDialogs, то не будут скинится ни ваши, ни чужие диалоги.
