CFileDialog and SkinManager

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   We're trying out the v17 Beta3 and having all kinds of issues.
We have opened several Bug Issues but seem to be at a stalemate...

The samples seem to work rather nicely using CFileDialog and the like...however when we put the SkinManager into our app...it seems to have several issues.  

The dlg.doModal() for CFileDialog either fails to pop up (resource issue??), have rendering issues (lots of icons in the CFileDialog are missing).  

When we try to switch Skins the software always crashes on exit with assertions from the cleanup of the Hooks (from SkinManager).  

The only thing we are doing is calls to like:
      XTPSkinManager()->LoadSkin(_T(""), _T(""));  // no skin/theme - native Windows

OR

   XTPSkinManager()->LoadSkin(m_sSkinsPath + skins[nSkin].pszPath, skins[nSkin].pszIni);

With the skins we copied from v17 beta Styles folder and the code from the SkinDMISample...
Anybody having similar issues?  

PS: we've only been successful with the Skin Manger if we  use
      XTPSkinManager()->LoadSkin(_T(""), _T(""));  // no skin/theme - native Windows

Very frustrating...

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
guiuser1 Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 17 November 2015 Status: Offline Points: 34	Post Options Post Reply Quote guiuser1 Report Post Thanks(0) Quote Reply Topic: CFileDialog and SkinManager Posted: 04 December 2015 at 12:17pm
	We're trying out the v17 Beta3 and having all kinds of issues. We have opened several Bug Issues but seem to be at a stalemate... The samples seem to work rather nicely using CFileDialog and the like...however when we put the SkinManager into our app...it seems to have several issues. The dlg.doModal() for CFileDialog either fails to pop up (resource issue??), have rendering issues (lots of icons in the CFileDialog are missing). When we try to switch Skins the software always crashes on exit with assertions from the cleanup of the Hooks (from SkinManager). The only thing we are doing is calls to like: XTPSkinManager()->LoadSkin(_T(""), _T("")); // no skin/theme - native Windows OR XTPSkinManager()->LoadSkin(m_sSkinsPath + skins[nSkin].pszPath, skins[nSkin].pszIni); With the skins we copied from v17 beta Styles folder and the code from the SkinDMISample... Anybody having similar issues? PS: we've only been successful with the Skin Manger if we use XTPSkinManager()->LoadSkin(_T(""), _T("")); // no skin/theme - native Windows Very frustrating...

guiuser1 Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 17 November 2015 Status: Offline Points: 34	Post Options Post Reply Quote guiuser1 Report Post Thanks(0) Quote Reply Posted: 08 December 2015 at 2:54pm
	Still on v17 Beta 3....we moved up to Visual Studio 2013 (VC12) and things are working a lot better. We still get an exception during the exit but the skins are flopping as they should. VC12 is using Windows SDK 7.1A since we are still supporting XP...

Arnoutdv Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 29 September 2010 Status: Offline Points: 38	Post Options Post Reply Quote Arnoutdv Report Post Thanks(0) Quote Reply Posted: 10 December 2015 at 4:32am
	Sorry, but I can't be of any help. I can only confirm that when using the UNICODE versions of the SkinFrameWork OCX in combination with CommandBars OCX (either using version 16.3.0 or 16.4.1), my application experiences sudden "Application Stopped Working" failures. My application is created using VB6.
	VB6 SP6, SuitePro 16.3.0 / 18.2.0, Win10/64

guiuser1 Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 17 November 2015 Status: Offline Points: 34	Post Options Post Reply Quote guiuser1 Report Post Thanks(0) Quote Reply Posted: 10 December 2015 at 9:58am
	We actually have no need for unicode versions since our client base is what it is (niche products). We do not see a need to move, except for the fact that newer Visual Studio (VS2013/VC12) versions attempt to force the issue. MS did a poor job on that...but that's another story... We have been using non-Unicode versions...although in our testing, that does not seem to matter.