[OldGrumpy]

Hi again,

I found a strange bug once more. I attached a demo project that shows a little of the problems that occur. I am using a settings dialog in my application and added code to have a list of available skins there, including switching skins on the fly. After one or two changes, my app crashes with an access violation due to access to a non-existant object, the call stack is almost empty at that time so I can't figure out what's happening there without much effort.

So I made up a simple test application to check if that behaviour is due to my code or the skin code, and voila, the test app behaves strange, too – just not that strange as my big app does, but definitely wrong. Here is what happens on my machines:

Run the included exe or build the project. Create a folder C:Skins and put some skins in it for use by the app. Run the app. Click the “Settings” button. The Settings dialog should appear over the main dialog, covering most of it. Now use the mouse wheel to switch to a new skin. In most cases, the result here is a mixture of both forms. E.g. I see the caption “Form27” which belongs to the main form, and its outer shape, PLUS the combobox from the Settings form but also the Settings button from the main form. The combobox still has the focus and I'm still able to switch controls. Hiding the app and restoring its windows seems to cure this.

Next thing I'll do is trying to compile a debug version of the controls to find out if I can get any more details about the crash in my app.

[attachment=3278:Skin_Sel…_Problem.rar]

P.S. Here is the relevant call stack from such a crash:

QUOTE

:7c812afb kernel32.RaiseException + 0x52
:00404e94 NotifyNonDelphiException + $1C
:7c91327a ntdll.RtlConvertUlongToLargeInteger + 0x3c
Graphics.TBitmap.GetCanvas
sScrollBox.TsScrollBox.WMNCPaint((133, 1, 0, 0))
Controls.TControl.WndProc((133, 1, 0, 0, 1, 0, 0, 0, 0, 0))
Controls.TWinControl.WndProc((133, 1, 0, 0, 1, 0, 0, 0, 0, 0))
sScrollBox.TsScrollBox.WndProc((133, 1, 0, 0, 1, 0, 0, 0, 0, 0))
acSBUtils.TacMainWnd.CallPrevWndProc(725270,133,1,0)
acSBUtils.TacScrollWnd.acWndProc((133, 1, 0, 0, 1, 0, 0, 0, 0, 0))
Controls.TWinControl.MainWndProc((133, 1, 0, 0, 1, 0, 0, 0, 0, 0))
Classes.StdWndProc(725270,133,1,0)
:7e368734 USER32.GetDC + 0x6d
:7e37bdf1 ; C:WINDOWSsystem32USER32.dll
:7e378ea0 ; C:WINDOWSsystem32USER32.dll
:7e378eec ; C:WINDOWSsystem32USER32.dll
:7c91e473 ntdll.KiUserCallbackDispatcher + 0x13
acSBUtils.TacMainWnd.CallPrevWndProc(725270,15,0,0)
acSBUtils.TacScrollWnd.acWndProc((15, 0, 0, 0, 0, 0, 0, 0, 0, 0))
Controls.TWinControl.MainWndProc((15, 0, 0, 0, 0, 0, 0, 0, 0, 0))
Classes.StdWndProc(725270,15,0,0)
:7e368734 USER32.GetDC + 0x6d
:7e368816 ; C:WINDOWSsystem32USER32.dll
:7e378ea0 ; C:WINDOWSsystem32USER32.dll
:7e378eec ; C:WINDOWSsystem32USER32.dll
:7c91e473 ntdll.KiUserCallbackDispatcher + 0x13
sSkinManager.TsSkinManager.RepaintForms
sSkinManager.TsSkinManager.SendNewSkin(True)
sSkinManager.TsSkinManager.SetSkinName('BlueGlass')
settings.Tgensettingsdlg.cbbSelectSkinChange($7FE21050)

P.P.S. The crash occurs from sScrollbox.pas line 326, a call to BitBltBorder with FCommonData.FCacheBmp.Canvas.Handle as a parameter, FCacheBmp is nil at that time. Any idea where that could occur from?

[Support]

Mixture occurs when animating working seems. You can try to disable animation and look…
And thank you for the demo, I'll research it soon.

[OldGrumpy]

Meanwhile I did some more research and I think there are two independent bugs. One is demonstrated in the sample project, the other one occurs in my main app only.

I am not sure how the second bug is triggered but it has definitely to do with switching skins. When I switch skins in my main app (done from a secondary dialog, not the main dialog like in the Alphaskin demo), the secondary dialog is visible but not modal. Immediately after switching the skin some repaint occurs and during that TsScrollBox.WMNCPaint() is called at a time where FCommonData.FCacheBmp is nil. This isn't checked and there is another branch in that function that explicitly sets it to nil… So I guess we're facing some kind of race condition. I set a breakpoint at that line (line 326) with the condition set to only break when FCacheBmp is nil. It doesn't break there until the skin is switched at runtime, and everytime after that again. So I guess something goes wrong during switching the skin.

[Support]

Thank you for additional information.
Your second form (where skin is selected) must have not a skinning?
If SkinProvider is placed there then I do not see a problem…
In the your application this form haven't TsSkinProvider component too?

[OldGrumpy]

QUOTE (Support @ May 25 2009, 02:32 PM)

Thank you for additional information.
Your second form (where skin is selected) must have not a skinning?
If SkinProvider is placed there then I do not see a problem…
In the your application this form haven't TsSkinProvider component too?

The second form is skinned, too. It has the same skin as the main form. Do I understand this right, each form needs a TsSkinProvider placed on it? My app looks basically like this:

TMainForm (has TsSkinManager and TsSkinProvider on it)
TSettingsForm (has no Manager and no Provider)

CODE

TSettingsForm.sCombobox1OnChange(Sender : TObject);
Begin
  TMainForm.sSkinManager1.SkinName:=sCombobox1.Items[sCombobox1.ItemIndex];
End;

All Forms look skinned properly, i just noticed that something makes the sScrollbox code break as mentioned before. The breakpoint I set in line 326 is never triggered before changing the skin from the SettingsDlg, and gets triggered again and again afterwards. This makes me think that something caused that the two code branches are no longer synchronized properly. I added code to create a bitmap if it is missing, but I fear this could create a resource leak instead. I haven't had time to debug everything thoroughly. I could not reproduce this effect with code changes to the demo application, though. There has to be a very complex connection…

[Support]

Thank you, I'm in researching and problem will be solved soon.

[Author]

Posts