[kami]

Win7 Aero, D2010, 9.10, скины скачаны по ссылке из архива в 9.10 – эффект наблюдается кратковременно, при анимации смены скина. В “обычном режиме” я бы даже не обратил на это внимания, т.к. доли секунды – имхо, вообще несущественно

Например – AutumnSky.asz, Beijing.asz. При активации скина Deep – эти самые скругленные края формы становятся голубыми. Визуально – при Min|restore формы такого не наблюдается.

Настройки по умолчанию SkinManager-а не менял

[kami]

в 9.04, к сожалению, посмотреть не удалось, но 9.05 – полет нормальный.

Спасибо!

[kami]

Прошу прощения за долгое молчание – не удавалось добраться до теста…

Проблема осталась и в 9.05, я все больше склоняюсь к тому, что проблема именно у меня, но…

Исходные данные:

Code:

Project DispatcherClient.exe raised exception class EAccessViolation with message 'Access violation at address 00517872 in module 'DispatcherClient.exe'. Read of address 80808088'.

Возникает после того, как отработали деструкторы всех sPageControl (их два на фрейме), я вижу это по отрабатываемым брейкпоинтам на TPageControl.Destroy.

CallStack выглядит по-прежнему:

Code:

ComCtrls.TPageControl.GetPageCount
Controls.TWinControl.MainWndProc(???)
Classes.StdWndProc(2688850,512,0,327768)
Forms.TApplication.ProcessMessage(???)

стек в багрепорте выглядит так:

Code:

main thread ($fc8):
00517872 +006 DispatcherClient.exe ComCtrls 6138 +0 TPageControl.GetPageCount
00614c37 +60f DispatcherClient.exe sPageControl TsPageControl.WndProc
779d702b +02b ntdll.dll KiUserCallbackDispatcher
0055bf70 +02c DispatcherClient.exe Controls 9540 +3 TWinControl.MainWndProc
004b4f10 +014 DispatcherClient.exe Classes 13015 +8 StdWndProc
765ccc6b +00a USER32.dll DispatchMessageW
00587339 +11d DispatcherClient.exe Forms 9760 +30 TApplication.ProcessMessage
00587366 +00a DispatcherClient.exe Forms 9782 +1 TApplication.ProcessMessages
00614c27 +5ff DispatcherClient.exe sPageControl TsPageControl.WndProc
779d702b +02b ntdll.dll KiUserCallbackDispatcher
0055bf70 +02c DispatcherClient.exe Controls 9540 +3 TWinControl.MainWndProc
004b4f10 +014 DispatcherClient.exe Classes 13015 +8 StdWndProc
765ccc6b +00a USER32.dll DispatchMessageW
00587339 +11d DispatcherClient.exe Forms 9760 +30 TApplication.ProcessMessage
0058737e +00a DispatcherClient.exe Forms 9790 +1 TApplication.HandleMessage
005876a9 +0c9 DispatcherClient.exe Forms 9927 +26 TApplication.Run
00a847f8 +06c DispatcherClient.exe DispatcherClient 138 +12 initialization
7628ee1a +010 kernel32.dll BaseThreadInitThunk

Собственно, симптомы проблемы я нивелировал тем, что спустил sPageControl, теперь табы находятся чуть ниже пункта меню “Уничтожить фрейм”. Таким образом, sPageControl не получает MOUSEMOVE в процессе уничтожения и эта ошибка не возникает.

Еще раз хочу подчеркнуть, что AV возникает только если при нажатии на пункт меню “Уничтожить фрейм” повести мышкой в сторону, а сама мышь будет находиться над одним из табов. Сам sPageControl к этому времени уже уничтожен, с WM_MOUSEMOVE и тому подобными событиями я не балуюсь (тем более – через PostMessage, что косвенно подтверждается стеком), в этом проекте такое без надобности.

Жаль, что не получилось локализовать проблему и составить демку, но…давайте будем считать проблему закрытой, все-таки хоть и “не нашими методами”, но она сведена к нулю.

[kami]

'Support' wrote:

А исходники пакета есть? Они нужны для дебага.

Увы – нет, иначе в багрепорте было бы видно номера строк в AC-компонентах. Да и проблему я бы указывал бы тогда точнее, а если бы получилось – то и первопричину 🙂

[kami]

'Support' wrote:

основная проблема – в создании тестового приложения с ошибкой.

Пытаюсь сделать его с момента обнаружения. Увы – не получается даже приблизиться к воспроизведению ошибки.

Поэтому и говорю – готов на что угодно 🙂 , включая удаленный доступ + средства безвозвратного удаления файлов и т.п.

[kami]

Господа, спасайте.

на v9.04 – то же самое.

Я в упор не понимаю, какие могут прилетать сообщения в уже уничтоженный sPageControl, но закономерность я выявил:

визуально – всё то же самое: sPageControl, главное меню при нажатии перекрывает табы.

Если нажать на пункт меню, который вызывает “отложенное” уничтожение фрейма с sPageControl, то возникает Access violation at address 005288B2 in module '….exe'. Read of address 80808088.

Стек в Delphi выглядит по прежнему:

Code:

ComCtrls.TPageControl.GetPageCount // вот здесь окно LocalVariables показывает, что Self = nil.
Controls.TWinControl.MainWndProc(???)
Classes.StdWndProc(723664, 512, 0, 589869);// WM_MOUSEMOVE
Forms.TApplication.ProcessMessage(???)

багрепорт:

Code:

main thread ($234):
005288b2 +006 ….exe ComCtrls 6138 +0 TPageControl.GetPageCount
00625ca5 +5f5 ….exe sPageControl TsPageControl.WndProc
006b0bc8 +194 ….exe sSkinProvider TsSkinProvider.AC_WMNCHitTest
004c5f50 +014 ….exe Classes 13015 +8 StdWndProc
0056cfb0 +02c ….exe Controls 9540 +3 TWinControl.MainWndProc
004c5f50 +014 ….exe Classes 13015 +8 StdWndProc
7767cc6b +00a USER32.dll DispatchMessageW
00598379 +11d ….exe Forms 9760 +30 TApplication.ProcessMessage
005983be +00a ….exe Forms 9790 +1 TApplication.HandleMessage
005986e9 +0c9 ….exe Forms 9927 +26 TApplication.Run
00a948c8 +06c ….exe DispatcherClient 138 +12 initialization
7721ee1a +010 kernel32.dll BaseThreadInitThunk

Если мышка при нажатии на пункт меню не двигается – всё отлично. Если сдвинулась хоть на пиксель – AV.

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

[kami]

Вот еще из двух багрепортов, они точно с 9.03b на борту:

Code:

0051788e +006 …exe ComCtrls 6138 +0 TPageControl.GetPageCount
00614af1 +5f5 …exe sPageControl TsPageControl.WndProc
76eb702b +02b ntdll.dll KiUserCallbackDispatcher
0055bf8c +02c …exe Controls 9540 +3 TWinControl.MainWndProc
004b4f2c +014 …exe Classes 13015 +8 StdWndProc
7686cc6b +00a USER32.dll DispatchMessageW
00587355 +11d …exe Forms 9760 +30 TApplication.ProcessMessage
0058739a +00a …exe Forms 9790 +1 TApplication.HandleMessage
005876c5 +0c9 …exe Forms 9927 +26 TApplication.Run
00a877d0 +06c …exe DispatcherClient 138 +12 initialization
764cee1a +010 kernel32.dll BaseThreadInitThunk

Code:

0051788e +006 …exe ComCtrls 6138 +0 TPageControl.GetPageCount
00614af1 +5f5 …exe sPageControl TsPageControl.WndProc
76eb702b +02b ntdll.dll KiUserCallbackDispatcher
0055bf8c +02c …exe Controls 9540 +3 TWinControl.MainWndProc
004b4f2c +014 …exe Classes 13015 +8 StdWndProc
7686cc6b +00a USER32.dll DispatchMessageW
00587355 +11d …exe Forms 9760 +30 TApplication.ProcessMessage
00587382 +00a …exe Forms 9782 +1 TApplication.ProcessMessages
00614ae1 +5e5 …exe sPageControl TsPageControl.WndProc
76eb702b +02b ntdll.dll KiUserCallbackDispatcher
0055bf8c +02c …exe Controls 9540 +3 TWinControl.MainWndProc
004b4f2c +014 …exe Classes 13015 +8 StdWndProc
7686cc6b +00a USER32.dll DispatchMessageW
00587355 +11d …exe Forms 9760 +30 TApplication.ProcessMessage
0058739a +00a …exe Forms 9790 +1 TApplication.HandleMessage
005876c5 +0c9 …exe Forms 9927 +26 TApplication.Run
00a877d0 +06c …exe DispatcherClient 138 +12 initialization
764cee1a +010 kernel32.dll BaseThreadInitThunk

[kami]

Простите – забыл вложить вложение 🙂

[kami]

'TCount' wrote:

Вроде как должен этот баг быть исправлен в версии 9.04.

Если невтерпеж, могу посоветовать загружать глифы программно (с диска или ресурсов), это работает.

Втерпеж, подожду. Этот способ оставим на крайний случай 🙂

Спасибо.

[kami]

ну так Delphi ругается не на sStrings.pas, а на то, что нет доступа на запись в папку C:Program Files…

Обычное явление для ОС Vista или Seven – в них права на запись в системные папки даются только после повышения прав доступа.

Задайте в опциях проекта папку для вывода DCU (не знаю, как в D10, а в D7 она на закладке DirectoriesConditionals, параметр Unit Output Directory). Только задайте не в системной папке типа Windows, Program Files, etc…

[kami]

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

Спасибо.

[kami]

Прошу прощения, что-то картинки некрасиво приаттачились, и исправить не удается…

Фу-ты…

Не понимаю, почему раньше не получалось, но сейчас этот код

Code:

for i := 0 to ComponentCount – 1 do
if Components is TPopupMenu then
sFrameAdapter.SkinData.SkinManager.SkinableMenus.HookPopupMenu(TPopupMenu(Components), sFrameAdapter.SkinData.SkinManager.Active);

работает на ура…

Корректно ли так писать? (само собой – с проверками на возможный nil)

Подождем до завтра, для закрепления эффекта на другом компьютере…

[kami]

'Support' wrote:

Попробуйте задать последнему меню какой-нибудь ImageList. Изменится что-то?

Задал.

картинка из “неправильного” фрейма:

[attachment=4541:кадр.jpg]

картинка из “правильного” фрейма:

[attachment=4542:кадр_2.jpg]

итог – “фон” левой части не тот…

'Support' wrote:

Не может ли быть так, что для элементов меню заданы иконки с маленькой шириной?

нет, иконки для меню не используются вообще.

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

P.S. Смена скина в runtime устраняет эту маленькую недостатку 🙂

[kami]

Здравствуйте.

'Support' wrote:

При создании MenuItems в рантайме попробуйте вызвать sSkinManager1.SkinableMenus.HookPopupMenu(pm, sSkinManager1.Active), это должно решить проблему…

СПАСИБО огромное! Да, проблема решилась и в тестовом и реальном проектах. Правда, юниты, в которых создавались popupmenu не должны были знать о SkinManager и главной форме, но это уже дело десятое.

'Support' wrote:

Я запускал приложеный Exe, но ошибка не возникла, попробую позже под Вистой.

Да, на тестовой XP выполняется без ошибок, как я писал выше. На Win7 протестировать не могу – не владею ей 🙁 Посему, будем считать что проблема была только на Vista.

Если поможет, могу выложить видеофайл возникновения ошибки (и пропадания “левой” части меню) из Delphi и без нее. (правда, либо в exe, либо в непонятном формате – беглым поиском был найден только UVScreenCamera)

[Author]

Posts