Print Page | Close Window

Suspected Errors of Version 18.0.1

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=23409
Printed Date: 23 December 2024 at 10:41am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com


Topic: Suspected Errors of Version 18.0.1
Posted By: jychoe
Subject: Suspected Errors of Version 18.0.1
Date 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.



Replies:
Posted By: olebed
Date Posted: 09 August 2017 at 8:56am
Hello Pete Choe,

Thank you for information!

Item 4 we have already fixed ( http://forum.codejock.com/forum_posts.asp?TID=23410" rel="nofollow - see this topic ).
Also I have fixed item 6.3
About other - we need more time to investigation.

Regards,
 Oleksandr Lebed


Posted By: jychoe
Date Posted: 09 August 2017 at 9:02pm
Thank you, Oleksandr

Please figure out if the other suspected items should be fixed.

Cheers




Posted By: astoyan
Date Posted: 10 August 2017 at 12:34am
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


Posted By: jychoe
Date Posted: 10 August 2017 at 10:49pm

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.

http://forum.codejock.com/forum_posts.asp?TID=23406&title=on-toolkit-v1801s-change-with-widgets-border" rel="nofollow - http://forum.codejock.com/forum_posts.asp?TID=23406&title=on-toolkit-v1801s-change-with-widgets-border

Regards



Print Page | Close Window

Forum Software by Web Wiz Forums® version 12.04 - http://www.webwizforums.com
Copyright ©2001-2021 Web Wiz Ltd. - https://www.webwiz.net