Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > Visual C++ MFC > Skin Framework
  New Posts New Posts RSS Feed - DestroyWindow() -> Run-Time Check Failure #0
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

DestroyWindow() -> Run-Time Check Failure #0

 Post Reply Post Reply
Author
Message
dbrulhart View Drop Down
Groupie
Groupie


Joined: 19 October 2006
Location: Switzerland
Status: Offline
Points: 38
Post Options Post Options   Thanks (0) Thanks(0)   Quote dbrulhart Quote  Post ReplyReply Direct Link To This Post Topic: DestroyWindow() -> Run-Time Check Failure #0
    Posted: 02 August 2007 at 1:40pm
Hi all,
 
When calling DestroyWindow() on either a CMDIChildWnd or CMDIFrameWnd (called by MFC in OnClose()) produces the following crash in CXTPSkinManagerApiHook::ThreadProcHook()
 
Error: Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call.
 
Just upgraded to toolkit 11.1.3 and observing this one. Was fine under 10.3.1.
 
An other application that I just skinned by adding only the two following lines (and nothing else at all) produces the same issue.
 

XTPSkinManager()->SetApplyOptions(xtpSkinApplyFrame | xtpSkinApplyColors | xtpSkinApplyMetrics);

XTPSkinManager()->LoadSkin(_T("d:\\XtremeToolkitPro\\Bin\\vc71\\Styles\\Vista.cjstyles"), _T("NormalBlack.ini"));

Am I missing something ?

Thanks for your help

Dominique

 
 
 
 
Back to Top
ABuenger View Drop Down
Newbie
Newbie
Avatar

Joined: 02 February 2006
Status: Offline
Points: 1075
Post Options Post Options   Thanks (0) Thanks(0)   Quote ABuenger Quote  Post ReplyReply Direct Link To This Post Posted: 02 August 2007 at 4:01pm
Is this a multithreaded app? I had several problems when the MDI main frame terminates a thread after OnClose has been called.

Codejock support
Back to Top
dbrulhart View Drop Down
Groupie
Groupie


Joined: 19 October 2006
Location: Switzerland
Status: Offline
Points: 38
Post Options Post Options   Thanks (0) Thanks(0)   Quote dbrulhart Quote  Post ReplyReply Direct Link To This Post Posted: 02 August 2007 at 4:38pm
Yes, it is a heavily multithreaded application.
 
However, what is strange is that it seems that it worked fine under 10.3.1...
 
Back to Top
Oleg View Drop Down
Admin Group
Admin Group


Joined: 21 May 2003
Location: United States
Status: Offline
Points: 11234
Post Options Post Options   Thanks (0) Thanks(0)   Quote Oleg Quote  Post ReplyReply Direct Link To This Post Posted: 03 August 2007 at 3:33am
Hello,
 
As temporary workaround you can disable auto apply new threads:
 
XTPSkinManager()->SetAutoApplyNewThreads(FALSE);
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS
Back to Top
dbrulhart View Drop Down
Groupie
Groupie


Joined: 19 October 2006
Location: Switzerland
Status: Offline
Points: 38
Post Options Post Options   Thanks (0) Thanks(0)   Quote dbrulhart Quote  Post ReplyReply Direct Link To This Post Posted: 03 August 2007 at 10:01am

Hi Oleg,

Works now. Thanks for the fix.

By temporary workaround, do you mean this will have an impact on performances (or some other impact) on multithreaded apps or we can live with this solution more or less permanently ?

Thanks again

Dominique

 

Back to Top
Oleg View Drop Down
Admin Group
Admin Group


Joined: 21 May 2003
Location: United States
Status: Offline
Points: 11234
Post Options Post Options   Thanks (0) Thanks(0)   Quote Oleg Quote  Post ReplyReply Direct Link To This Post Posted: 04 August 2007 at 2:20am
Hello,
 
Only one difference - it will skin only main thread - if you create dialogs in another threads they will be not skinned.
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS
Back to Top
dbrulhart View Drop Down
Groupie
Groupie


Joined: 19 October 2006
Location: Switzerland
Status: Offline
Points: 38
Post Options Post Options   Thanks (0) Thanks(0)   Quote dbrulhart Quote  Post ReplyReply Direct Link To This Post Posted: 07 August 2007 at 10:23am

Hi Oleg,

We have another issue/question with skinning.

We have many .exe and .dll that have to be skinned and we have many base classes derived from CMDIFrameWnd, CFrameWnd, CPropertySheet and CDialog.

What would be convenient is to call the LoadSkin in each of these classes constructors, so all would be automatic.

I've tried to check.

It seems working fine for MDI frame (there's only one per app), but I observe some refresh and flicking everytime we open any of these frame, dialog or sheet in an application already skinned.

Is it OK to call LoadSkin everytime for every window or does this eats GDI resources... or even may cause some of the performance issues related in thread #24926 ?
 
Is ther any better way ? I would like to avoid to add the LoadSkin() in every application or dll, but only once, etc... Would be much easier to have it automatic.
 
Thanks for your thoughts
 
Dominique
Back to Top
Oleg View Drop Down
Admin Group
Admin Group


Joined: 21 May 2003
Location: United States
Status: Offline
Points: 11234
Post Options Post Options   Thanks (0) Thanks(0)   Quote Oleg Quote  Post ReplyReply Direct Link To This Post Posted: 08 August 2007 at 2:16am
Hello,
 
You only need call LoadSkin  in main application.
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS
Back to Top
dbrulhart View Drop Down
Groupie
Groupie


Joined: 19 October 2006
Location: Switzerland
Status: Offline
Points: 38
Post Options Post Options   Thanks (0) Thanks(0)   Quote dbrulhart Quote  Post ReplyReply Direct Link To This Post Posted: 08 August 2007 at 5:24am

Hi Oleg,

That's what I expect, but I'm also trying to keep a generic code for all our apps based on the base classes we already have, without tweaking all apps.

Is the SkinManager dependant of the the CWnd class ? I see in your examples than you seem always call it from the CMainFrame class.
 
Would it be possible to all LoadSkin from CWinApp::InitInstance() or is it too early ?
 
Thank for your support
 
Dominique
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.04
Copyright ©2001-2021 Web Wiz Ltd.

This page was generated in 0.191 seconds.