Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > Visual C++ MFC > Toolkit Pro
  New Posts New Posts RSS Feed - Updated from 17.3 to 18.2 - Dialog App freezes
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Updated from 17.3 to 18.2 - Dialog App freezes

 Post Reply Post Reply
Author
Message
MacW View Drop Down
Senior Member
Senior Member


Joined: 26 June 2007
Status: Offline
Points: 250
Post Options Post Options   Thanks (0) Thanks(0)   Quote MacW Quote  Post ReplyReply Direct Link To This Post Topic: Updated from 17.3 to 18.2 - Dialog App freezes
    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.





Back to Top
olebed View Drop Down
Admin Group
Admin Group
Avatar

Joined: 01 July 2014
Location: Ukraine
Status: Offline
Points: 830
Post Options Post Options   Thanks (0) Thanks(0)   Quote olebed Quote  Post ReplyReply Direct Link To This Post Posted: 29 November 2017 at 9:16pm
Hello MacW,

 Please create support ticket with description, screenshots and sample application.

Regards,
 Oleksandr Lebed
Back to Top
MacW View Drop Down
Senior Member
Senior Member


Joined: 26 June 2007
Status: Offline
Points: 250
Post Options Post Options   Thanks (0) Thanks(0)   Quote MacW Quote  Post ReplyReply Direct Link To This Post 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).
Back to Top
olebed View Drop Down
Admin Group
Admin Group
Avatar

Joined: 01 July 2014
Location: Ukraine
Status: Offline
Points: 830
Post Options Post Options   Thanks (0) Thanks(0)   Quote olebed Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 593
Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down



This page was generated in 0.094 seconds.