Updated from 17.3 to 18.2 - Dialog App freezes
Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=23511
Printed Date: 23 December 2024 at 6:26am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: Updated from 17.3 to 18.2 - Dialog App freezes
Posted By: MacW
Subject: Updated from 17.3 to 18.2 - Dialog App freezes
Date Posted: 29 November 2017 at 1:24pm
|
I've just installed the 18.2 and re-compiled my Dialog-based MFC app. This app has been successfully compiled and used with late 16 and all 17 editions of XTPro. Running it with 18.2 has these effects: The app dialog shows up, but is only partially drawn. The app is not responding, it seems to hang in some infinite internal redraw loop (?). 1. In Instance (before the dialog is opened) I initialize the SkinManager XTPSkinManager()->SetAutoApplyNewThreads(FALSE); XTPSkinManager()->SetAutoApplyNewWindows(TRUE); XTPSkinManager()->LoadSkin(T("styles\\Office2010.cjstyles"), _T("NormalSilver.ini")); This always worked, the app is skinned etc. But now it freezes. If I comment out line 3 (LoadSkin) the app is no longer skinned but works fine. 2. I tried to move the LoadSkin into the Dialog class, which is derived from CXTPDialogBase<CXTResizeDialog>. This prevented the freeze, but also caused the dialog to become unstyled as soon as I resize the dialog by dragging the lower right edge. And, the dialog frame always stays in the same size, but the contents of the window move outside the dialog: see image below.  Where do I even start looking for something this weird? The only chance for shipping my app now is either going back to CJ 17.3 and asking for a refund or get a solution fast. |
Replies:
Posted By: olebed
Date Posted: 29 November 2017 at 9:16pm
|
Hello MacW, Please create support ticket with description, screenshots and sample application. Regards, Oleksandr Lebed |
Posted By: MacW
Date Posted: 30 November 2017 at 3:53pm
|
Can this be a concurrently issue or something? When problem happens if happens always in some kind of infinite loop inside the 'hook' functions XTP runs everywhere. A synthetic small example app does not show the problem, tried that already. Like so often. A real app which message handlers, command handlers, XTP markup processing, buttons and other controls shows the problem. After several hours of digging it seems that the xtpSkinApplyFrame option is causing the problem. When I exclude it from the skin manager, no problems anymore. Apparently. Still testing. I swapped back to XTP 17.3 for testing and the problem is gone. The only change is the XTP version. My main app, which also uses the skin framwork does not show this behavior (thankfully). |
Posted By: olebed
Date Posted: 30 November 2017 at 6:24pm
| In such cases we can use remote debugging with TeamViewer. SkinFramework is sophisticated library and to find reason of some issues I even search revision after which issue happens. |
Posted By: rdhd
Date Posted: 04 December 2017 at 4:34pm
|
Hi Mac, You tried moving the code to OnInitDialog()? OnShowWindow()? When locked up, what does the TaskManager details view show for cpu usage for your app? If caught in some looping scenario, you should see the cpu grinding away. If you debug break a few times when locked up, are you always in the same code? Can you step thru code or when you "step" using the debugger does the debugger just act like you hit continue? Once you break, you can examine all the threads and see if they are all waiting on some object. But the main thread is the one you want to observe and see what, if anything, is happening. |