Suspected Errors of Version 18.0.1 |
Post Reply |
Author | |
jychoe
Groupie Joined: 05 February 2016 Location: Korea Status: Offline Points: 13 |
Post Options
Thanks(1)
Posted: 09 August 2017 at 2:54am |
Hi I would like to report some of seemingly defects that are present in version 18.01.
1. warning C4819 1.1) In Source/Common/XTPEnableAdvancedWarnings.h Line 132 Col 53 1.2) In Source/Common/XTPVersion.h Line 61 Col 43 1.3) In Source/Controls/Combo/XTPFontComboBox.h Line 329 Col 20 1.4) In Source/FlowGraph/XTPFlowGraphNodeCustom.h Line 85 Col 56 2. Compile Error In Source/CommandBars/XTPPaintManager.h Line 1454 Below members are omitted. CXTPFont m_xtpFontRegular; CXTPFont m_xtpFontRegularBold; CXTPFont m_xtpFontVert; CXTPFont m_xtpFontVertBold; 3. Debug Build GdiPlus 3.1) In Source/GraphicLibrary/GdiPlus/GdiPlusBase.h 3.2) When using static linking debug new & delete for GdiPlus are also missing.
void* (operator new)(size_t nSize,
LPCSTR /*lpszFileName*/, int /*nLine*/) { return DllExports::GdipAlloc(nSize); } void operator delete(void* p, LPCSTR /*lpszFileName*/, int /*nLine*/) { DllExports::GdipFree(p); } 4. (fixed) CXTPSystemVersion::GetComCtlVersion() Error dwVersion conditional statement seems to have error. DWORD CXTPSystemVersion::GetComCtlVersion() const { static DWORD dwVersion = 0; if (0 != dwVersion) -> think this should be if (0 == dwVersion) { dwVersion = CXTPModuleHandle(_T("comctl32.dll")).GetVersion(); if (0 == dwVersion) dwVersion = MAKELONG(0, 4); // Old ComCtl32 had version 4.0 } return dwVersion; } 5. Strange behavior with m_xtpBrushWindow 5.1) when m_xtpBrushWindow uses cached brush that was formerly created from m_xtpBrushTheme (color and type are same) 5.2) For multi line edit control, whose edit region is set from application, or IP address edit control, white color border is being drawn in editing region instead of the color that was set as skin's COLOR_WINDOW. 5.3) when m_xtpBrushWindow is not a cached brush, but additionally created HBRUSH, then it displays as expected. 6. Skin doesn't get reflected in some cases, these cases were actually normally working cases with former version. 6.1) LoadSkin succeeds but, in some Windows 7 PC set skin doesn't get reflected. 6.2) This gets fixed if USER32.dll is added as ExcludeModule in CXTPSkinManagerApiHook::CXTPSkinManagerApiHook() as below. ExcludeModule(_T("SHLWAPI.DLL"),
TRUE); ExcludeModule(_T("COMCTL32.DLL"), TRUE); ExcludeModule(_T("KERNEL32.DLL"), FALSE); ExcludeModule(_T("USER32.DLL"), FALSE); ///< Here. ExcludeModule(_T("GDI32.DLL"), FALSE); ExcludeModule(_T("WININET.DLL"), FALSE); ExcludeModule(_T("MSCTF.DLL"), FALSE); ExcludeModule(_T("ACLAYERS.DLL"), FALSE); 6.3) (fixed) In CXTPSkinManagerApiFunction::ReplaceInOneModule(), even when bReplaced is true, bAtLeastOneReplaced should be TRUE. if (bFound) { ... { ... bAtLeastOneReplaced = TRUE; } } else if (bReplaced) { bAtLeastOneReplaced = TRUE; } I wish this report leads to productive discussions, or solutions. Maybe someone is out there having the same trouble i just had. Cheers.
|
|
olebed
Admin Group Joined: 01 July 2014 Location: Ukraine Status: Offline Points: 841 |
Post Options
Thanks(1)
|
Hello Pete Choe, Thank you for information! Item 4 we have already fixed (see this topic).
Also I have fixed item 6.3 About other - we need more time to investigation. Regards, Oleksandr Lebed |
|
jychoe
Groupie Joined: 05 February 2016 Location: Korea Status: Offline Points: 13 |
Post Options
Thanks(0)
|
Thank you, Oleksandr
Please figure out if the other suspected items should be fixed. Cheers |
|
astoyan
Admin Group Joined: 24 August 2013 Status: Offline Points: 304 |
Post Options
Thanks(0)
|
Hi Pete, Thank you for reporting all those issues, while some of them has been fixed and others are in progress, there are some that requires clarification. First of all, which compiler and configurations did you use? Did you use any additional code analysis tools or enabled any special all all VC compiler warnings? Let me comment some of your findings: 1. warning C4819 in In Source/Controls/Combo/XTPFontComboBox.h Line 329 Col 20 This line contains a comment, and word "Item" starts at the specified location, however it does not contain any non-ANSI characters 2. Compile Error ... We wouldn't be able to even build installers if the file did not compile, and the compilation of the build was tested in all common VC compilers, moreover no user has reported this compilation error. What kind of error did you get? 3. Debug Build GdiPlus ... As mentioned above, the build was thoroughly tested and no user has reported this kind of issue too. Can you please explain what do you mean by missing operators and how it affects you compilation or linking? 5. Strange behavior with m_xtpBrushWindow ... m_xtpBrushWindow gets created in just one place and it's created from COLORREF (m_xtpBrushWindow.CreateSolidBrush(m_clrTheme[COLOR_WINDOW]). Can you please explain what m_xtpBrushTheme has to do about it? Regards, Alexander
|
|
jychoe
Groupie Joined: 05 February 2016 Location: Korea Status: Offline Points: 13 |
Post Options
Thanks(0)
|
Hi Alexander, Thank you for kind reponses. Replying your questions: 1. In file, XTPFontComboBox.h's line #329, commented description is shown // ? Item 1 sorts before item 2. the ? above triggers warning. I know its just trivial thing, however.. 2. Followed by XTP_SUBSTITUTE_GDI_MEMBER_WITH_CACHED macros there is m_xtpFontRegular as cachedMemberName macro argument, however it was declared at nowhere. Thus I had to add it to build. 3. I was talking situation when below defines are used with MFC headers. GdiPlus needs additional new & delete overloads to comply with this. # Ifdef _DEBUG # Define new DEBUG_NEW # Endif 5. Yes as you mentioned m_xtpBrushWindow gets created in just one place. But, if there's previously created brush with same color then it looks for previously created cached brush, and creates indirectly, actually it's technically not creating. m_xtpBrushTheme's cached brushes get created preceding creation of m_xtpBrushWindow, thus when creating m_xtpBrushWindow it looks for previously created and cached brushes. In my use case, m_xtpBrushWindow looks for the same colored brush which was previously created and cached when creation of m_xtpBrushThemes' brushes was performed. It is expected to grab the brush according to the desired color, however unwanted color brush gets used when drawing some part of widget. This phenomena is described in my former report, of which the link is as below. Regards
|
|
Post Reply | |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |