Forum

Other windows located below a CExtRichContentScrollWnd become in-accessable when there is undisplayed horizontal content to the bottom.  Interestly, the area that becomes in-accessable is directly related the size of undisplayed scroll content.

I’ve also noticed that sometimes the scrollbars don’t work having just re-sized the control.

Dear Support,

We need a masked string in cells. We saw this class, but it does not seems to be doing anything - is it implemented? If so, how?

Thanks,

Ron.

Hi,

We need all grids to be sorted case insensitive - how do we do it?

Thanks,

Ron.

Hello,

Is it possible to invert the Expand/Collapse arrows buttons in a CExtPageNavigator pane? The pane is at the bottom of a window, so the arrows direction should be inverted. Here is a screenshot:

http://img846.imageshack.us/img846/397/arrowsr.png

So when the pane is collapsed, the arrow should be pointing up and when it is expanded, the arrows should be pointing down.

Thanks!

Sometimes it won’t scroll correctly to the bottom, having re-sized the parent window.  Your sample RichContentFeatures exhibits the same problem.

Is there a proper fix for this yet?  The temporary fix you’ve provided is very jerky when re-sizing the window & I can’t bring myself to use it.

Thanks.

 

Thanks.

I’ve noticed that since this temporary fix a horizontal scrollbar is sometimes unnecessarily drawn.

 

We are sorry, the following method should also be updated:

void CExtRichContentScrollWnd::OnSize( UINT nType, int cx, int cy )
{
    ASSERT_VALID( this );
    RcsDelayRecalcLayout();
    CExtNSB < CExtScrollWnd > :: OnSize( nType, cx, cy );
}

We reproduced this issue. Thank you. We have only a temporarily fix for it at this moment:

CRect CExtRichContentScrollWnd::OnSwRecalcLayout(
    bool bDoLayout,
    LPCRECT pRectClientSrc // = NULL
    )
{
    ASSERT_VALID( this );
CRect rcLayout = CExtScrollWnd::OnSwRecalcLayout( bDoLayout, pRectClientSrc );
    if(        GetSafeHwnd() != NULL
        &&    (    m_bRcsDelayRecalcLayout
//            ||    rcLayout != m_rcLayoutLast
            )
        )
    {
        m_rcLayoutLast = rcLayout;
        if( bDoLayout )
        {
            CExtRichContentLayout * pRCL = RcsLayoutGet();
            if( pRCL != NULL && pRCL->m_listHeap.GetCount() > 0 )
            {
                const CExtRichContentItem * pRootRCI = ( pRCL->m_listHeap.GetCount() > 0 ) ? pRCL->m_listHeap.GetHead() : NULL;
                ASSERT( pRootRCI != NULL );
                CRect _rcLayout( rcLayout );
                CSize sizeScrollBars( ::GetSystemMetrics(SM_CXVSCROLL), ::GetSystemMetrics(SM_CYHSCROLL) );
                bool bHaveScrollBarH = OnSwHasScrollBar( true ), bHaveScrollBarV = OnSwHasScrollBar( false );
                CClientDC dc( this );
                HFONT hFontRCS = OnRcsGetFont();
                CFont * pFont = ( hFontRCS != NULL ) ? CFont::FromHandle( hFontRCS ) : GetFont();
                CFont * pOldFont = dc.SelectObject( pFont );
                OnRcsPreLayoutContent( dc, _rcLayout, pFont );
                pRCL->DoLayout( dc, _rcLayout );
                OnRcsPostLayoutContent( dc, _rcLayout, pFont );
                bool bAddSBH = false, bRemoveSBH = false;
                bool bAddSBV = false, bRemoveSBV = false;
                _rcLayout = rcLayout;
                CSize sizeContent = pRootRCI->m_rcLayout.Size(), sizeLayout = _rcLayout.Size();
                if( sizeContent.cx > sizeLayout.cx )
                    bAddSBH = (! bHaveScrollBarH);
                else
                    bRemoveSBH = bHaveScrollBarH;
                if( sizeContent.cy > sizeLayout.cy )
                    bAddSBV = (! bHaveScrollBarV);
                else
                    bRemoveSBV = bHaveScrollBarV;
                if( bAddSBH || bRemoveSBH || bAddSBV || bRemoveSBV )
                {
                    if( bAddSBH )
                        OnSwEnableScrollBarCtrl( SB_HORZ, true );
                    if( bRemoveSBH )
                        OnSwEnableScrollBarCtrl( SB_HORZ, false );
                    if( bAddSBV )
                        OnSwEnableScrollBarCtrl( SB_VERT, true );
                    if( bRemoveSBV )
                        OnSwEnableScrollBarCtrl( SB_VERT, false );
                    m_bRcsDelayRecalcLayout = false;
                    OnSwUpdateScrollBars();
                    rcLayout = CExtScrollWnd::OnSwRecalcLayout( bDoLayout, pRectClientSrc );
                    _rcLayout = OnSwGetClientRect();
                    OnRcsPreLayoutContent( dc, _rcLayout, pFont );
                    pRCL->DoLayout( dc, _rcLayout );
                    OnRcsPostLayoutContent( dc, _rcLayout, pFont );
                    m_rcLayoutLast = _rcLayout;
                } // if( bAddSBH || bRemoveSBH || bAddSBV || bRemoveSBV )
                dc.SelectObject( pOldFont );
                m_bRcsDelayRecalcLayout = false;
            } // if( pRCL != NULL && pRCL->m_listHeap.GetCount() > 0 )
        } // if( bDoLayout )
    } // if( .....
    return rcLayout;
}

A bit more info...

RichContentFeatures.exe - based in 2.90 & downloaded from your site - works fine.

The same program re-built using a pre-release of 2.92 will quite often fail to render the last few lines when you re-size the dialog & then scroll to the bottom.

virtual bool OnGridCellButtonPressed(
		   const CExtGridCell & _cell,
		   INT nButtonType,
		   bool bMouseInsideButton, 
		   ULONG nPressedTimerCounter, 
		   const RECT & rcButton,
		   const RECT & rcCellExtra,
		   const RECT & rcCell,
		   LONG nColNo,
		   LONG nRowNo,
		   INT nColType,
		   INT nRowType)
			{
				CWnd * pWnd = GetParentOwner();
				GetParentOwner()->SendMessage(WM_ITEM_SELECTED, nColNo, nRowNo);
				return true;
			}

Event not fired on cell button click

First of all, you should know whether you need focus or selection changing event. Then you will override one of the following methods:
1) CExtGridBaseWnd::OnGbwFocusChanging() - invoked before focus changing, allows to prevent focus changing
2) CExtGridBaseWnd::OnGbwFocusChanged() - invoked after focus changed
3) CExtGridBaseWnd::OnGbwSelectionChanged() - invoked after selection changed

Thank you very much - this is what I been looking for (and for so long...)

Still cannot find the solution for event to catch the row/cell selection in the grid.

For all the years i am using ProfUIS I see that support is getting worse and worse...

Any grid cell class in Prof-UIS supports the following built-in cell parts (from left to right): icon, check/radio box, text, up-down button, drop-down button, ellipsis button. Any of built-in cell pars can be hidden. If you see anything else, then it’s implemented from scratch using custom painting. The OnGridCellButton*** methods are related to the up-down, drop-down and ellipsis cell buttons - not to the check/radio box.
You need the CExtGridCell::OnSetCheck() and/or CExtGridWnd::OnGridCellSetCheck() virtual methods.

We cannot confirm this. Please provide more details. Which cell class exactly are you using in your test?

CExtGridCellCheckBox * pCellCheckBox =
			STATIC_DOWNCAST( CExtGridCellCheckBox, m_wndGrid.GridCellGet( 0, nRowNo, 0, 0, RUNTIME_CLASS(CExtGridCellCheckBox) ) );
		ASSERT_VALID( pCellCheckBox );
		pCellCheckBox->SetCheck(0);

Hi,

I would like to know if it is be possible to keep a Header Cell selected as soon as a cell of its column has the focus in a ReportGrid? I would like something like implemented in the tab ’Products (highlighting)’ of the ’SimpleGrid’ project.

I have tried to add the ’__EGBS_EX_FI_HIGHLIGHT_COLUMNS | __EGBS_EX_FO_HIGHLIGHT_COLUMNS’ extended style but I didn’t succeed to keep my header cell selected.

Regards, Cedric.

1. If one opens on the same machine the Prof Studio example and Microsoft’s Visual Studio, the docking windows in the latter auto-hide smoothly while Prof Studio exhibits a rather jerky move where the redraws are obvious. I am comparing here some equivalent cases: take for example the solution explorer windows. Could you please fix this issue?

2. If one resizes the main frame in all the MDI examples there are some redundant operation performed by the ProfUIS framwork that result in obvious flickering. More precisely, the docking child windows are rendered in some intermediate positions that create a rather un-professional look. Please note I reported this twice in the past three months, I emailed you a detailed example and yet received no reply.

I am trying this again (including an associated e-mail) hoping in a response, especially that others seem to raise the same questions about the library.

Thank you,

Bogdan.

All CExtShell dialogs are extremely slow in comparison with standard dialogs. This is not acceptable to wait over 5 seconds for dialog to appear. Please suggest the way to accelerate dialogs load

1) and 2) is not the case, 3 - questionable and standard dialog is not slow. So, this is definitely a bug you need to fix ASAP.  In current way it working it is not acceptable at all

This is a known issue:

1) Sometimes it occurs on a computer where a diskette drive is present. Shell APIs are slow on particular computers with diskette drives. This issue is not resolved yet.

2) A folder contains 5000 files or more. Current version of shell controls scan all files at once. Background scanning is not supported. Please use file type filters to reduce the number of displayed shell items.

3) Particular network paths pointing to particular computers work extremely slow. But this is typically the same for Windows shell dialogs.

2) ... Why should we implement this questionable workaround ?

Seems to me that you background processing of the files can address all problems.

It would be nice to have shell dialogs in the chosen skin of the application, but if you can’t or won’t fix them, why bother supplying them at all?

 

1) and 2) is not the case, 3 - questionable and standard dialog is not slow. So, this is definitely a bug you need to fix ASAP.  In current way it working it is not acceptable at all

I have a number of outstanding support issues which are yet resolved, infact, some requests have been ignored.

Would someone please respond.

Any news on the (Show All) bug?

Thanks

 

This is a bug, not a feature request.  I have sent you a test project ... my findings are:

1. CExtGridWnd - dynamic filters - not suitable for editing as only visible row values are added to the Value Filters list so there is no way to un-filter hidden rows.

2. CExtGridWnd - static filters updated using UpdateStaticFilterValueForOuterRow(-1) - incorrectly ticks (Show All)

3. CExtTreeGridWnd - dynamic filters -  incorrectly ticks (Show All)

4. CExtTreeGridWnd - static filters updated using UpdateStaticFilterValueForOuterRow(-1) - incorrectly ticks (Show All)

 

Would someone please look into this, thanks.

 

The CExtTreeGridWnd and CExtGridWnd filters are different. The CExtTreeGridWnd constantly provides access to all the HTREEITEM row handles regardless of their hidden state. The CExtGridWnd control hides its hidden rows inside inner row range of data provider and hidden rows are inaccessible. You can use any of these controls. We can assume your note about hidden rows in CExtGridWnd control is a feature request.

I meant a new project ... I’ll sent it together with a long outstanding issue regarding header value filters not working correctly.

Thanks

 

To fix the check combo box flickering, please update the source code for the following method:

void CExtCheckComboBox::_OnDrawComboImpl(
    bool bPressed,
    bool bHover,
    CDC * pDC // = NULL
    )
{
    if( pDC != NULL && AnimationClient_StatePaint( *pDC ) )
        return;
CRect rcClient;
    GetClientRect( &rcClient );
bool bCallReleaseDC = false;
    if( pDC == NULL )
    {
        pDC = GetDC();
        ASSERT( pDC != NULL );
        bCallReleaseDC = true;
    }
DRAWITEMSTRUCT dis;
    ::memset( &dis, 0, sizeof( DRAWITEMSTRUCT ) );
    dis.CtlType = ODT_LISTBOX;
    dis.CtlID = GetDlgCtrlID();
    dis.itemID = UINT(-1);
    //dis.hDC = pDC->GetSafeHdc();
CRect rc( rcClient );
    rc.DeflateRect(
        3,
        3,
        3 + ::GetSystemMetrics( SM_CXVSCROLL ), // + PmBridge_GetPM()->GetDropDownButtonWidth(),
        3
        );
    ::CopyRect( &dis.rcItem, &rc );
    dis.itemAction = ODA_DRAWENTIRE;
    dis.hwndItem = GetSafeHwnd();
    if( ::GetFocus() == m_hWnd )
        dis.itemState |= ODS_FOCUS|ODS_SELECTED;
    { // block for memory dc
        CExtMemoryDC dc(
            pDC,
            &rcClient,
            CExtMemoryDC::MDCOPT_TO_MEMORY | CExtMemoryDC::MDCOPT_FILL_BITS | CExtMemoryDC::MDCOPT_RTL_COMPATIBILITY
            );
        dis.hDC = dc.GetSafeHdc();
        SendMessage( WM_DRAWITEM, (WPARAM)GetDlgCtrlID(), (LPARAM)&dis );
        CExtComboBox::_OnDrawComboImpl( bPressed, bHover, &dc );
    } // block for memory dc
    if( bCallReleaseDC )
        ReleaseDC( pDC );
}

The static value filter was designed for non-editable grid controls. Your grid control is programmaticaly editable. So, if you switch to dynamic value filters, the problem should be gone.

The header filter code you’ve posted is identical to the existing code (2.92)

My CExtCheckComboBox objects are owner draw = variable, has strings = true and they flicker when you move the mouse over them.  I have created a simple test dialog and they still flicker.

If you mean the ComboBoxTest test project you sent us - the combo boxes there are not owner draw and the CComboBoxTestDlg::DoCheck() method makes them behaving extremely slow. If you mean some new project, then please send it to us.

Thanks, you had me worried for a while there :)

 

I  hope they’re not experiencing problems, maybe they’re all working hard readying the next release!

The thought of having to move to another UI after 9 months of development is an unpleasant one to say the least :(

Come on technical support ... do your thing :)

 

 

We are sorry for the delays with this reply. The best fitting can be improved by implementing the following virtual method in theCExtGridCellHeaderFilter class:

    virtual INT OnCalcButtonExtent(
        INT nButtonType, // e_button_type_t
        const CExtGridWnd & wndGrid,
        CDC & dc,
        LONG nVisibleColNo,
        LONG nVisibleRowNo,
        LONG nColNo,
        LONG nRowNo,
        INT nColType,
        INT nRowType,
        DWORD dwAreaFlags,
        DWORD dwHelperPaintFlags
        ) const;

INT CExtGridCellHeaderFilter::OnCalcButtonExtent(
    INT nButtonType, // e_button_type_t
    const CExtGridWnd & wndGrid,
    CDC & dc,
    LONG nVisibleColNo,
    LONG nVisibleRowNo,
    LONG nColNo,
    LONG nRowNo,
    INT nColType,
    INT nRowType,
    DWORD dwAreaFlags,
    DWORD dwHelperPaintFlags
    ) const
{
    __EXT_DEBUG_GRID_ASSERT_VALID( this );
    if( ( dwHelperPaintFlags & __EGCPF_SIMPLIFIED_RENDERING_TARGET ) != 0 )
        return 0;
    if(        nButtonType == INT(__EBTT_DROPDOWN)
        &&    ( dwHelperPaintFlags & __EGCPF_REPORT_GROUP_AREA ) != 0
        )
        return 0;
INT nExtent = CExtGridCellHeader::OnCalcButtonExtent( nButtonType, wndGrid, dc, nVisibleColNo, nVisibleRowNo, nColNo, nRowNo, nColType, nRowType, dwAreaFlags, dwHelperPaintFlags );
    if(        nButtonType == INT(__EBTT_DROPDOWN)
        &&    nExtent > 0
        )
        nExtent += 6;
    return nExtent;
}

Please check the combo box dialog items in the dialog template resource editor for all the CExtCheckComboBox subclassed objects. Your combo boxes must be ownerdraw fixed or variable. They also should have the HasStrings option set on. This will guarantee all the flicker effects are gone.

I guess their sales are going down so they don’t want or cannot fix bugs as they used to :(

In http://www.prof-uis.com/prof-uis/tech-support/support-forum/documentation-about-skinning-67109.aspx you say that you have a skin editor on your TODO list.

Is there any news on that front?

As you sell a skinning library, I still feel that you are obliged to your customers to provide a skin editor or at least complete documentation about the skin xml format.

 

Completely agree. We need customization for the skins and there is no fiormat documentation or editor available

I want to show a context menu when the user right clicks in the tab strip. Adding a button to the strip is a possible alternative method.

Please create your own tabs class derived from CExtTWPC < CExtTabFlatWnd > and handle the WM_RBUTTONDOWN message in it:

class CYourFlatTabWnd : public CExtTWPC < CExtTabFlatWnd >
{
protected:
    virtual LRESULT WindowProc( UINT message, WPARAM wParam, LPARAM lParam )
    {
        switch( message )
        {
        case WM_RBUTTONDOWN:
            {
                CPoint point( LOWORD(lParam), HIWORD(lParam) );
                int nTabItemIndex = ItemHitTest( point );
                if( nTabItemIndex < 0 )
                    return 0L; // not on tab item
. . . . . . . .
            }
        return 0L;
        }
        return CExtTWPC < CExtTabFlatWnd > :: WindowProc( message, wParam, lParam );
    }
};

Then you should override the <codeOnTabWndGetTabImpl()</code> virtual method so that the flat tab page container can use that tab control:

class CExtTabPageContainerFlatWnd : public CExtTabPageContainerWnd
{
public:
    virtual CExtTabWnd* OnTabWndGetTabImpl()
    {
        return new CYourFlatTabWnd;
    }
};    

This change worked, thanks.

We were using ProfUIS version 2.54 and have recently upgraded to the latest version 2.91.I built all the static and dll targets of 2.91 on VS2008.

We have derived our class from CExtTabPageContainerOneNoteWnd & then have overridden OnCreate(LPCREATESTRUCT lpCreateStruct) which has been implemented as :-

int classname::OnCreate(LPCREATESTRUCT lpCreateStruct)

{

 if( CExtTabPageContainerOneNoteWnd::OnCreate(lpCreateStruct) == -1 )

  return -1;

 OrientationSet( __ETWS_ORIENT_LEFT );

 CCreateContext* pContext = NULL;

 if (lpCreateStruct != NULL)

  pContext = (CCreateContext*)lpCreateStruct->lpCreateParams;

 CString strTabname = "Tab One";

 if( ! m_view1->Create(NULL,_T(""),WS_CHILD | WS_VISIBLE,CRect(20,20,1,1), this,ID_VIEW1, pContext))

 {

  ASSERT( FALSE );

  return -1;

 }

 if( ! PageInsert(m_view1->GetSafeHwnd(),strTabname))

 {

  ASSERT( FALSE );

  return -1;

 }

 if( ! m_View2->Create(NULL,_T(""),WS_CHILD | WS_VISIBLE,CRect(30,30,1,1),this,ID_VIEW2, pContext))

 {

  ASSERT( FALSE );

  return -1;

 }

 strTabname  = "Tab Two";

 if( ! PageInsert(m_View2->GetSafeHwnd(),strTabname))

 {

  ASSERT( FALSE );

  return -1;

 }

}

Here, m_view1 & m_view2 are instances of classes derived from CView class.

The above code creates tab which are aligned vertically. The problem is that if the text to be displayed is in a language other than English, the text gets trimmed and "..." is displayed in the end.

For example, "Tab Two" is displayed like "Tab T...". Moreover, the problem occurs irrespective of tab alignment, i.e, it occurs even if the tabs are aligned horizontally.

Please suggest.

 

Setting CExtRichContentLayout::g_bUseWin32ForPlainText to true during app initialization didn’t work for us.

 

 

Please let us know whether the issue disappears if you invoke the following line of code during your app initialization:

CExtRichContentLayout::g_bUseWin32ForPlainText = true;

Setting CExtRichContentLayout::g_bUseWin32ForPlainText to true in app initialization is not working.

I would like to reiterate that the problem is not occuring for English language. I can see a lot of instances in the code where elipses are getting added to the text. We would like to EXCLUDE this logic for tabs. 

Since, our release is coming closer, it seems as if we might have to delay the release due to this critical issue which can affect our customers. In case, you are not able to reproduce the issue OR any inputs are required from our side, we can schedule a telephonic call or live meeting to discuss those in detail as we need to resolve this asap.

Moreover, I already have shared a sample app couple of months back to reproduce the issue. You can use the same to reproduce and fix the problem.

Is someone looking into this?

 We tried copying the files ExtRichContent.h and ExtRichContent.cpp from 2.92 to 2.91 & rebuild the project (both MBCS & MBCS-RDE) but it didn’t work.

Moreover, we also tried using using 2.92 dlls with our product but it was crashoing our application. Please suggest.

If you come across with any crashes or compilation problems, please provide us with the content of Output and Call Stack windows in your Visual Studio. We also would like to ask to to do one small experiment. Please invoke the CExtRichContentLayout::g_bUseWin32ForPlainText = false; line of code during your app initialization and let us know whether this fixes text on tab items?

Sorry, we mean CExtRichContentLayout::g_bUseWin32ForPlainText = true; line of code.

I tried downloading the source code of 2.92 from the following link:-

http://www.prof-uis.com/download/mfc.aspx

Clicking on " Prof-UIS v.2.92 (36.00Mb) Source code and documentation " link didn’t work. Can you please suggest appropriate link from where we can download the source code of 2.92

 

We cannot confirm that the links are not active if you login using your username. The user PBBISAGENT should be able to download the software. Please try it again. In any case, please send a request to support@prof-uis.com to get our ftp address so you can always download any Prof-UIS version via ftp.

We have recently moved to ProfUI 2.91 version and cannot upgrade to 2.92 as we are having a release scheduled & there is no time to test as well. Can you please provide us the fix asap so that we can incorporate that fix in our code & build the libraries.

2.92 is a minor release. If you don’t want to update, you can get only the ExtRichContent.h and ExtRichContent.cpp files from 2.92 and put it into 2.91

Hi Support,

  This has been more than 2 months that there is not reply from Technical Support. I am not sure where is the technical support for the Prof UI? Is there any existance or not?

I am really very unhappy with the support and thinking of moving away from Prof UI by looking at the responses. There is no contact points, no email coming from support. I need answer to my queries ASAP.

 

Thanks

Pankaj

We fixed this rarely occurred text measurement issue in Prof-UIS 2.92.

I have sent sample aplication which loads Japanese strings from a resource dll (Cannot share resource dll as it is project specific).  The Japanese string gets trimmed and ".." is appended at the end.  Also, please note that the bug is reproducible on a Japanese environment.

We received your e-mail and replied it.

Could you please send us this modified version of the TabbedBars sample application?

I opened TabbedBars_900.vcproj using VS 2008 and did the following changes in CChildView::OnCreate() :-

1. Used CString::LoadString() to load Japanese text from a resource dll.

2. Passed that string to PageInsert()

Observed that for larger text, ".." was getting added to the tab text

Please suggest.

 

Any updates on this? Will appreciate if you can provide the fix asap.

Hi

i have set m_bAutoMenuEnable = FALSE in my mainframe’s constructor, so that my menu items that have no ON_COMMAND handler are displayed as enabled and not grayed.

When using Profuis menus and Toolbox in particular (CExtToolBoxWnd) the menuitems are grayed no matter what the m_bAutoMenuEnable is.

Is there a m_bAutoMenuEnable equivalent in ProfUis?

If not, how can i overcome this problem?

Thanx in advance.

Hi

I am planning to use NSIS to create an installer to my application, I see that I can skin it using skincrafer plugin, but I want to know if I can use profuis to skin it so I don’t have to manage two type of skinning (I’ll use the same xml et images for the installer and the application)

Thank you

It seems you don’t have time to fix bug I’ve reported so I did it by myself, you could check it (btw the same problem with decimal separator is also in CExtEditSystemNumber):

long double CExtEditSystemCurrency::LongDoubleGet() const
{
 //return CExtEditSystemCurrency::LongDoubleGet();
ASSERT_VALID(
CExtSafeString str = _GetNumericText( m_pEditWithBehaviorWnd->TextGet(),
str.Replace(m_strCurrencySymbol,_T(this );false );"")); //rrr
str.Trim();//rrr
 if( str.IsEmpty()
//rrr || str == _T(".")
|| str == LPCTSTR(m_strDecimalPoint)
|| ( str.GetLength() == 1 && m_strDecimalPoint.GetLength() > 0 && str[0] == m_strDecimalPoint[0] )
)
 
 
LCID _LCID = LANG_USER_DEFAULT;
 
_LCID = g_ResourceManager->GetLangIdDesired();
 
COleCurrency _oleCurrency;
VERIFY( _oleCurrency.ParseCurrency( LPCTSTR(str), 0, _LCID ) );
 
 
 
}return 0.0;if( g_ResourceManager->IsCustomLangAllowed() )long double lfVal = ((long double)_oleCurrency.m_cur.int64) / ((long double)10000.0);return lfVal;

 

 

We need to know exactly which Decima symbol and Digit grouping symbol are specified in the locale settings on your computer? They should be be equal to each other.

Here is the screenshot. I’ve set just "Format: Slovak", other settings are untouched:
http://img708.imageshack.us/i/97820163.png/

We are sorry but we re-checked the CExtEditSystemCurrency editor control using the <span class="newgreen">ProfUIS_Controls</code> sample application and it works. Please provide more details about why you decided to fix it?

I’ve tried ProfUIS_Controls now. When I set windows language format to "Slovak", currency edit shows "0 $". I click behind the "0", I press comma, then 4 for example and it asserts.
I don’t know why sample is not calling CExtEditSystemCurrency::LongDoubleGet() which I’ve modified. It calls CExtEditSystemNumber::LongDoubleGetBase() which is also buggy.
It converts string using _GetNumericText() which changes comma to dot, then it is parsing string with dot as decimal separator using user’s locale (set to Slovak, which is using COMMA as separator), that’s why it fails.
For currency parsing I’ve added removal of currency symbol to allow using of CExtEditSystemCurrency with different currency symbol, than current system’s currency.
In CExtEditSystemCurrency::LongDoubleGet() you are comparing string with str == _T(".") although the string is in user’s locale format which can use different decimal separator ("." can be thousands separator for example)