See below, after updating to 2.84:

Please fix (there is a text there - 5678...).

We are not sure Windows XP is the source of the problem:

http://www.prof-uis.com/download/forums/tmp/xp-read-only-CExtEdit.PNG

Which XP exactly you are using? Which service pack? Which desktop theme?

Maybe it’s the theme - I use Royale... in any case, I changed it from disabled to read-only, which is better solution. Thanks anyhow.

Here is what we see with Royale:

http://www.prof-uis.com/download/forums/tmp/xp-royale-CExtEdit.PNG

But we didn’t test the Media Center. We just copied the Royale theme data into Windows XP Professional English SP3 for testing.

The read-only edit boxes use the same text color as the enabled edit boxes but they use different background colors. We guess you simply disabled some of your edit boxes instead of making them read-only:

http://www.prof-uis.com/download/forums/ProfUIS284-CExtEdit-Colors.png

I’m sorry, but this is not what I get... can you please from what sample you took this capture?

We used the Popup Menus page of the ProfUIS_Controls sample . We put an IDC_EDIT_INCREASE_PERCENT edit control in the IDD_PAGE_POPUP_MENUS dialog template resource enabled but read-only (it’s disabled by default). Then we compiled and run the ProfUIS_Controls sample on Windows Vista and we saw what’s on the screenshot.

I just downloaded v2.84 and I came across the following error: ’error C2065: ’CX_BORDER’ : undeclared identifier’.

I am using VS 2008 with the latest SP and patches.

In the file \Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc\afximpl.h I found.

 

// Note: afxData.cxBorder and afxData.cyBorder aren’t used anymore

#define AFX_CX_BORDER 1 

#define AFX_CY_BORDER 1

but no CX_BORDER

 

 

Seems like there is a bug in void CExtSplitterBaseWnd::DrawAllSplitBars( CDC* pDC, int cxInside, int cyInside )...

for( int row = 0; row < m_nRows; row++)

            {

                int cy = m_pRowInfo[row].nCurSize + 2*m_cyBorder;

                if( row == m_nRows-1 && m_bHasHScroll)

                    cy += afxData.cyHScroll - __EXT_MFC_CX_BORDER;

                OnDrawSplitter( pDC, splitBorder, CRect( x, y, x+cx, y+cy ) );

                y += cy + m_cySplitterGap - 2*m_cyBorder;

            }

 

In this case shouldn’t the __EXT_MFC_CX_BORDER be replaced with __EXT_MFC_CY_BORDER?

 

Yes, there are several usages of the CX_BORDER and CY_BORDER constants in Prof-UIS 2.84 and they should be replaced with __EXT_MFC_CX_BORDER and __EXT_MFC_CY_BORDER. We are sorry for the inconvenience.

I know that... that’s not what I was asking. I’m saying that I think one of the __EXT_MFC_CX_BORDERs should be replaced with a __EXT_MFC_CY_BORDER?  Please see the code snippet I included above. Should we make this change?

Yes, you are right, the following:

cy += afxData.cyHScroll - __EXT_MFC_CX_BORDER;

should be replaced with:

cy += afxData.cyHScroll - __EXT_MFC_CY_BORDER;

The problem is in ExtSplitterWnd, you need to use __EXT_MFC_CX_BORDER and __EXT_MFC_CY_BORDER instead of the older, CX_BORDER and CY_BORDER.  I though Foss had changed the source and fixed this a while ago, guess not.

Especially hoe to place it in

    virtual int DoMessageBox(LPCTSTR lpszPrompt, UINT nType, UINT nIDPrompt);

Of the CWinApp

Thanks,

Ron.

We have cells of type CExtGridCellDropListComboBox. When item selection is changed in the drop list, OnGridCellInputComplete was called up to the 2.84 beta version from November, but in the official release it does not work.

In the official release, it is not called, and we rely heavily on this event.

Please fix ASAP - we cannot release our version like this.

Thanks,

Ron.

This is a known and it is already fixed. Thank you. Please request the update by email.

Hello,

It’s always me ... For information, if you download the sampe Property Grid (click on image for access to the URL), and you try to change the Animation (Middle - Fast - None - ...), that does not work correctly.

• - If you select new value with the mouse (only), that does not work.


• - If you click on the cell and you write with keyboard F (for Fast), and Enter, it work.

Best regards.

  philippe

Hello,

This Bug in 2.84 is a really problem for us, because we must build the release of our application.

We don’t want to go back in 2.82 or 2.83. We think that modify the CExtGridCellComboBox::OnPopupListBoxSelEndOK (like in the explanation of Offer Har ... thank you Offer) is the good solution, but before make this modification, it’s really important to us to know the position of the Technical Support of Prof UIS. We don’t want to make this modification if in the next release Prof UIS don’t modify this problem or make differents modifications for solve this problem.

I wait an answer from a Prof UIS Technical Support people.

Best regards.

 philippe

We think, according to your feature request, the correct method is:

 bool CExtGridCellComboBox::OnPopupListBoxSelEndOK(
            CExtPopupInplaceListBox & wndListBox,
            CExtGridCell::TrackCellStateInfo_t & _tcsi
            )
{
            ASSERT_VALID( this );
            ASSERT( (&_tcsi.m_cell) == this );
            ASSERT_VALID( (&wndListBox) );
            ASSERT_VALID( (&_tcsi.m_wndGrid) );
            _tcsi.m_nItemNoSelEndOK = wndListBox.GetCurSel();
            _tcsi.m_bHelperSelChanged = true;
            if( (wndListBox.GetStyle()&LBS_HASSTRINGS) != 0 )
            {
                        LONG nItemCount = wndListBox.GetCount();
                        if( nItemCount > 0L )
                        {
                                    LONG nCurSel = wndListBox.GetCurSel();
                                    if( 0L <= nCurSel && nCurSel < nItemCount )
                                    {
                                                SetCurSel( nCurSel );
                                                CString strSelLbText;
                                                wndListBox.GetText( nCurSel, strSelLbText );
                                                DWORD dwStyleEx = GetStyleEx();
                                                bool bDoNotSendSelEndOkOnEqualText = ( ( dwStyleEx & __EGCS_EX_DO_NOT_NOTIFY_LB_SEL_FOR_EQUAL_TEXT ) != 0 ) ? true : false;
                                                if( bDoNotSendSelEndOkOnEqualText )
                                                {
                                                            CExtSafeString strCurrentText;
                                                            TextGet( strCurrentText );
                                                            if( strCurrentText == LPCTSTR(strSelLbText) )
                                                                        return false;
                                                }
                                                TextSet( LPCTSTR(strSelLbText) );
                                                _tcsi.m_wndGrid.OnGridCellInputComplete( *this, _tcsi.m_nColNo, _tcsi.m_nRowNo, _tcsi.m_nColType, _tcsi.m_nRowType, wndListBox.GetSafeHwnd() );
                                    } // if( 0L <= nCurSel && nCurSel < nItemCount )
                        } // if( nItemCount > 0L )
            } // if( (wndListBox.GetStyle()&LBS_HASSTRINGS) != 0 )
            return false;
}

The __EGCS_EX_DO_NOT_NOTIFY_LB_SEL_FOR_EQUAL_TEXT style was added by your feature request: do not notify about selection in popup list box if the selected text is the same as grid cell text. Your last proposal in this forum thread works with selected item index - not with text. Did you change your feature request?

Thanks for this fix.

Since I’m moving from 2.82 to 2.84, I was experiencing same bug.

Regards, Fabien.

I did not change the request... but you have a bug in 2.84.... it’s human to have bugs.

In your code, even if the text is different, the condition to exit is always true, please look at the code again...

 

Yes, but this is fixed in the improved method version in our previous answer in this thread.

OK - so there was a problem... you just provided an alternate solution to what I suggested?

Yes, we did.

I keep on getting:

<table width="730" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td width="60" valign="top" align="left" rowspan="2" id="infoIconAlign"> </td>
<td width="*" valign="center" align="left" id="mainTitleAlign">

Navigation to the webpage was canceled

</td>
</tr>
<tr>
<!-- This row is for HTTP status code, as well as the divider-->
<td align="right" class="errorCodeAndDivider" id="errorCodeAlign"> </td>
</tr>
<!-- Error Body --><!-- What you can do -->
<tr>
<td> </td>
<td valign="top" align="left" id="whatToTryAlign">

What you can try:

</td>
</tr>
<!-- refresh page -->
<tr>
<td> </td>
<td valign="center" align="left" id="refreshPageAlign">
<h4>
<table>
<tbody>
<tr>
<td valign="top"></td>
<td valign="top">Retype the address.<noscript id="refreshPage"></noscript></td>
</tr>
</tbody>
</table>
</h4>
</td>
</tr>
</tbody>
</table>

On the right panel - no matter what topic I choose.

Does not work:

1. Tried on to different machiens - same problem

2. Tried to run the chm file of 2.83 on the same machine - does work

It seems you have a preoblem in the released help file...

Please try http://www.prof-uis.com/download/help/profuishelp.zip We have just checked it.

Yep - this one works - thanks.

We suspect you tried to open the chm file that is located on some network resource even mapped to the local disk. This will not work. HTML Help 1.1 does not support this. Please copy both Prof-UIS chm and chi files to a local drive. If it is not the case, just let us know.

Hi,

I need to have a grid with 2000 rows and ~10 columns. Will it perform well, or do I need to think of some work-around?

Thanks,

Ron.

I need to sort a grid by several columns - First column A, secodary sort by column B etc etc, each one can be ascending or descending.

Thanks,

Ron.

When I create a dialog based application, and let the MFC wizard add the About option, then replaced CDialog with CExtNCW<CExtResizableDialog>, the About MyAppName... command is disabled. This code was generated by the wizard, and works well bofre to replacement of the CDialog - please cehck & fix.

Thanks,

Ron.

Hi,

Is there a way to make the CExtColorDlg remember its previous size/location and

which colour model was previously used?  Currently it looks nice, but would be

annoying to use in practice if the user had to re-establish these every time

the dialog was opened.

I’d also like a way to set these choices initially.

Thanks,

Rob.

It’s possible if you create a custom CExtColorDlg-derived class and adjust the required parameters in its OnInitDialog() virtual method. It’s also possible without coding your own color dialog class. You should save the registry parameters for your color dialog before invoking it.

[I’m quoting your reply "old-school" as I’m having so much trouble getting this forum to format things how I want]

> It’s possible if you create a custom CExtColorDlg-derived class and adjust the required parameters in its OnInitDialog() virtual method.

I gave it a go, but easier said than done.  What I want is to set the initial default only, ie first use, after which the values should be loaded from the registry.  So I presume I should set these BEFORE calling the base class’s OnInitDialog()?  I tried that with the following results:

Simply doing "m_wndColorCtrl = CExtColorCtrl::MODE_HSL_ROLLER;" in OnInitDialog, before calling the base, leads to an assertion.  Apparently the "=" operator is overridden and expects the window to be up and ready.

To change the default window size I tried the following:

    // Use a wider default window size.
    WINDOWPLACEMENT wp;
    ::memset(&wp, 0, sizeof(WINDOWPLACEMENT));
    wp.length = sizeof(WINDOWPLACEMENT);
    if (CExtControlBar::stat_GetWindowPlacement(m_hWnd, wp))
    {
        RECT &rc = wp.rcNormalPosition;
        rc.right += 400;
        CExtControlBar::stat_SetWindowPlacement(m_hWnd, wp);
    }

It does make the window the right size, but the contents have not been resized to match, and any resizing after that leaves the big extra space on the right empty.

> It’s also possible without coding your own color dialog class. You should save the registry parameters for your color dialog before invoking it.

I don’t like the idea of messing with the registry for this.  Best solution would be for ProfUIS to provide a way to set these defaults to begin with.

Thanks,

Rob.

You should invoke parent’s OnInitDialiog() virtual method first. It contains important initialization code and control anchoring code. But it also contains dialog position loading code. So, you may need to load position of your color dialog manually after invoking parent’s OnInitDialiog() virtual method.

But if I set the mode/position after calling OnInitDialog(), how do I know whether the values were loaded from the registry?  I only want to set the default, but my default should be overridden by a registry settings.  Conceptually it makes sense to set these before calling the base’s OnInitDialog().

I could get the values before, call OnInitDialog(), then check whether the values changed.  If so, then they were loaded from the registry and I should leave them untouched.  However if not, then I can’t be sure that the values weren’t in the registry.  This is how I’m doing it at the moment, which means if the user chooses the "basic colors" mode, which is the original Prof-UIS default, then my code will see that as no change and it will be switched to my default instead.

The obvious solution is to initially set the mode to an impossible value, so that we can be sure it can’t also appear in the registry.  Then a change definitely indicates that it came from the registry.  However, the m_eMode member of CExtColorCtrl is private, so I can’t access it in order to change it.  In fact, if I could, I could just set it before calling OnInitDialog() and everything would work.

All the same problems with position too.

I suppose you will tell me to look in the registry myself to see whether the key exists, and I guess that’s what I’ll do, but this could all be made much simpler if CExtColorDlg supported a couple of extra methods, like SetDefaultColorMode(), SetDefaultWindowSize() and SetDefaultWindowPos().  Or passing these as args to the constructor might be easier.  Doing this with the colour mode in particular would be very easy, so it’s tempting to hack the ProfUIS code, but not possible at my end of the code.

Thanks,

Rob.

Here is the updated source code for the CExtColorDlg class:

http://www.prof-uis.com/download/forums/UpdatedColorDialog285.zip

It’s not present in 2.84, but will be in 2.85. We added the following properties into the CExtColorDlg class:

   CExtSafeString m_strSection, m_strEntryDialogPosition, m_strEntryColorModelSelection;

The m_strSection property is the registry key name used for storing both dialog position and color model index.
The m_strEntryDialogPosition property is the registry variable name for storing the dialog position.
The m_strEntryColorModelSelection property is the registry variable name for storing the color model index.
We modified the following method in the ProfUIS_Controls sample application:

LRESULT CPagePopupMenus::OnColorSelectCustom(WPARAM wParam, LPARAM lParam)
{
            wParam;
            if(                     lParam == ID_COLOR_CTRL_8X5
                        ||           lParam == ID_COLOR_CTRL_8X2
                        ||           lParam == ID_COLOR_CTRL_GRAYSCALE
                        ||           lParam == ID_COLOR_CTRL_HLS
                        )
            {
                        COLORREF clrNew;
                        CExtColorDlg dlgColor;
                        dlgColor.m_strSection = _T("ColorDialog");
                        dlgColor.m_strEntryDialogPosition = _T("Position");
                        dlgColor.m_strEntryColorModelSelection = _T("ColorModel");
                        if( dlgColor.DoModal() != IDOK )
                                    return 0;
                        clrNew = dlgColor.m_clrNew;
                        OnColorChangedFinally( (WPARAM)clrNew, lParam );
            }
            return 0;
}

The context menu displayed over the Popup Menu page in the ProfUIS_Controls sample application has several color popup sub menus. These color sub menus allow you to display color selection dialogs which have persistent dialog position and color model index.

Dear Support Team,

We are using Prof’UIS for years now and we are using 2.82 release for a while now.
I planned to migrate to 2.84 beginning of next year.

One of my customer call me with a very weird bug : he couldn’t enter a . (dot) by pressing Shift and ; key (French keyboard of laptop and normal French Keyboard as well) !
Dot is ok when entering it with the keypad. All others keys are ok as well, with or without Shift pressed !

I tried to debug as deeper as I can ; but I’m a bit stuck to follow correctly the problem (even if I am using 2 monitors).

Are you aware of this problem ?
Any tips ?
Any reasons ?

Does this problem exists with 2.83 and/or 2.84 ?

Thanks for your support.
Best regards,
Fabien.

Dear Support,

I tried the reverse tests as yours (english profile with a french keyboard) and I’m getting the normal "<" on the key i’m supposed to get a dot with french profile.

Is this bug related to the fact that it’s normal behavior for keypad (Shift + dot produce a special event) ?
I remember that you re not sending this event with "normal" keyboard and with my key stroke.

Hope this helps for removing this nasty bug.

Regards,
Fabien.

It looks we fixed this issue. We added two lines of code into the CExtGridWnd::OnGbwBeginEdit() method:

                                                   if(                     ( bCtrl && (!bShift) && int(msg.wParam) == int( _T(’X’) ) )
                                                                        ||           ( (!bCtrl) && bShift && int(msg.wParam) == VK_DELETE )
                                                                        )
                                                            {
                                                                        if( ::DispatchMessage( &msg ) == 0 ) // THE FOLLOWING LINE WAS ADDED
                                                                                    continue; // THE FOLLOWING LINE WAS ADDED
                                                                        LRESULT lResult = 0L;
                                                                        g_pEditCell->OnInplaceControlWindowProc(
                                                                                    lResult,
                                                                                    msg.message,
                                                                                    msg.wParam,
                                                                                    msg.lParam,
                                                                                    msg.hwnd,
                                                                                    *this,
                                                                                    nVisibleColNo,
                                                                                    nVisibleRowNo,
                                                                                    nColNo,
                                                                                    nRowNo,
                                                                                    nColType,
                                                                                    nRowType,
                                                                                    rcCellExtra,
                                                                                    rcCell,
                                                                                    rcInplaceControl
                                                                                    );
                                                                        ::PeekMessage(&msg,NULL,msg.message,msg.message,PM_REMOVE);
                                                                        if( msg.message == WM_KEYDOWN )
                                                                        {
                                                                                    if( ( g_pEditCell->GetStyle() & __EGCS_READ_ONLY ) == 0 )
                                                                                                ::SendMessage( msg.hwnd, WM_CUT, 0, 0 );
                                                                                    else
                                                                                                ::SendMessage( msg.hwnd, WM_COPY, 0, 0 );
                                                                        }
                                                                        continue;
                                                            }

Brilliant fix !

Weird bug, wasn’t it ?

Wishing you all a very Happy Holiday Season.

Best regards, Fabien.

First of all, we wish you a Happy New Year too!

The . (dot) key located near the N key is the real surprise when the French keyboard layout is on. The WM_KEYDOWN message for this key in the French layout has the VK_DELETE key code in the WPARAM parameter. That is why our grid interpreted Shift+dot combination as cutting to clipboard command. But, if we let the window procedure of edit common control to handle this key combination, then we will know that there is something pressed but not the Shift+Delete. We don’t know the way to detect whether the dot or Delete key is pressed because both have the VK_DELETE key code in the French keyboard layout. We suspect this surprise is brought by some compatibility issue with some old French specific keyboard devices. It looks like the edit common control has some hard coded solution of this situation.

Dear All,

No need to speak french and fortunately I have a spare DELL laptop QWERTY keyboard at Office :-)

 

Your first step is correct.

The 2nd and 3rd are incorrect because I was speaking about my french Keyboard, not about yours (by the way, it was normal to get a m and a M).

 

The key I’m talking is the 2nd to the right of Letter N (in same row).

The 2nd key at the right of letter N is composed by a ; without shifting enabled and with a . with shifting enabled.

 

The problem experienced is that it’s the only key we couldn’t get when shifted in SimpleGrids sample !

 

Best regards, Fabien.

We are sorry for the delay with this reply. Very unfortunately we don’t have people in our team who speak French so we need your help with this. What we tried is as follows:

1) Added hte French/France keyboard layout and selected it for the running NOTEPAD.EXE application.

2) Pressed the ; key without shift and we saw a small letter m in the notepad application.

3) Tried to press the ; key with shift and we saw a big letter M in the notepad application.

4) We run the SimpleGrids sample application, selected the Products grid and repeated steps 2 and 3 in cell editors in this grid and result was the same - m and M.

We did this experiment with v.2.84 on Windows Vista. We used simple English keyboard. We didn’t see letter A. Please let us know what we did incorrectly.

We are sorry for the delay with this reply. Very unfortunately we don’t have people in our team who speak French so we need your help with this. What we tried is as follows:

1) Added hte French/France keyboard layout and selected it for the running NOTEPAD.EXE application.

2) Pressed the ; key without shift and we saw a small letter m in the notepad application.

3) Tried to press the ; key with shift and we saw a big letter M in the notepad application.

4) We run the SimpleGrids sample application, selected the Products grid and repeated steps 2 and 3 in cell editors in this grid and result was the same - m and M.

We did this experiment with v.2.84 on Windows Vista. We used simple English keyboard. We didn’t see letter A. Please let us know what we did incorrectly.

When is the 2.84 new date?

We are settinf our time-tables around it... please let us know when we’ll be getting it...

Thanks.

Hi,

We would like to provide an extra level of customization for our users, by allowing them to create new toolbar buttons which execute commands using our scripting language.

Although Prof-UIS’s customization allows users to create new toolbars and drag commands onto them, there’s no way to add to the list of commands itself.  This is what we would need, with the user supplying commands from our scripting language to be executed when the button is pushed.

Any thoughts on the best way to implement this?  Is there any way to integrate such a system into the existing customization dialog box?  Even if the feature to create new commands was not available within the customization dialog itself, it would still be nice to see these user-commands, once created, appear within the customization list and be able to drag them onto toolbars etc.

I imagine each new command will need a new resource ID.  But if the IDs are auto-generated as new commands are created, then a given command could end up with a different ID depending on what order commands were created.  Maybe this isn’t an issue, but seems like it could somehow be a problem, maybe when restoring toolbar state from the registry.  If user provides an ID, then there could be clashes between scripts from different users who chose the same ID, so I think they need to be auto-generated.

Also, the user will need to provide their own toolbar bitmaps somehow.

Thanks,

Rob.

Hello.

When I change a tab of MDI of figure 1.

(figure1)

Display such as figure 2 is performed only during several seconds.

(figure2)

　

Please revise it.

Had better I send a sample source to you?

We are sorry but we didn’t receive the e-mail with your source code yet.

 

I retransmited an E-mail.

Download http is listed. 

Hello.

The drawing of the MDI frame is abnormally a moment when I change MDI-TAB.

This is the malfunction that did not happen in Prof2.83.

I e-mailed the source.

 

 

I am trying to have a thin frame around my CExtLabel in an CExtNCW<CExtResizableDialog> dialog.

I tried like this: CExtWRB<CExtLabel>, with no luck.

I debugged the code, and I see that WM_NCPAINT is captured in the CExtWRB class, but for some reason this condition happens, so the function exits before it gets to draw anything:

        case WM_NCPAINT:
            {
                CRect rcInBarWnd, rcInBarClient;
                GetWindowRect( &rcInBarWnd );
                GetClientRect( &rcInBarClient );
                ClientToScreen( &rcInBarClient );
                if( rcInBarWnd == rcInBarClient )
                    return 0;

Why does this happen?

Is this the right way? If not, what is?

All label windows were created by the dialog template loading code and only later subclassed with the CExtWRB-based classes. So the CExtWRB template had no chance to re-compute non-client area of label windows. Please re-compute non-client area of all your CExtWRB-based labels manually. This can be done in the dialog’s OnInitDialog() virtual method:

CExtLabel & wndLabel = . . .
            wndLabel.SetWindowPos( NULL, 0, 0, 0, 0, SWP_NOMOVE|SWP_NOSIZE|SWP_NOZORDER|SWP_NOOWNERZORDER|SWP_FRAMECHANGED );

Would like to add that WM_NCCALCSIZE of CExtWRB is never called - maybe it can explain the problem...? why isn’t it called?

Hello.

The scroll of the grid which I made in a multiplex tab is abnormal.

Please teach a solution.

This is fixed in 2.84, you can download from http://www.prof-uis.com/download/mfc.aspx.#@lt;/p>

 

Hello.

I develop it in Prof2.83 now.

I ask for a revision with 2.83.

Thanks,

 

Even Prof2.84 does not work well.

 

Hello.

Can CExtControlBar exclude the dialog that I assigned once?

 

You can send us your sample project to the support mail box at this web site.

What do you mean by exclude You can destroy your dialog window anytime you need and you can create a new window as a child of a control bar.

A  CExtGridCellCheckBox in a  CExtGridWnd which has a __EGBS_SFB_NONE style becomes selected when the CheckBox is clicked.



This can be reproduced in the SimpleGrids application. Add “SiwModifyStyle(__EGBS_SFB_NONE, __EGBS_SFB_CELLS|__EGBS_SFB_FULL_ROWS|__EGBS_SFB_FULL_COLUMNS, true);” to CdemoGrid::_InitDemoTable_Products() after all other SiwModifyStyle/SiwModifyStyleEx/BseModifyStyle calls. Executing the application, Products Tab, Discontinued Column, Clicking the whitespace of a cell doesn’t select the cell. Enabling  or Disabling a CheckBox does.



A possible solution would be to handle the __EGBS_SFB_NONE style in CextGridCellCheckBox::OnClick(). The same code can be also found in other CextGridCell OnClick methods.



Will a fix for this item be included in the next release of Prof-UIS (2.8.4)?

When I run v283 MDI sample on Vista ( with desktop set to Vista theme, and use prof-ui office 2007 theme ) , part of the status bar is covered by the task bar. I can see that status bar goes 8 pixels below the task bar. This doesn’t happen to Native xp or VS2005/2008 theme.

Is this fixe in v284 ?

Thanks

Yes, we fixed this. The following ZIP file contains several samples compiled with v.2.84:

http://www.prof-uis.com/download/forums/tmp/MdiFlickerFreeTests284.zip

from another thread, looks like v284 should be released on Dec 15, 2008, but I don’t find anything from the website. Is it possible to provide us a daily build ?

Sorry for the delay. v.2.84 is officially released.

Dear Support,

Our company has been using your product Prof-UIS library for three years without any serious problems. But when we moved from the version 2.8.0 to 2.8.3 we realized that the performance of our product has decreased dramatically. The load on the processor in some conditions has increased up to 1000%, and it takes a long time to receive user interface (UI) response to the user’s actions.

Having analyzed the library code, we discovered that in the version  2.8.3  the implementation of the classes that we use (CExtComboBox, CExtTabPageContainerWnd)  has been modified. Using the inheritance and overloading of the virtual methods _CreateHelper() we exclude the subscription to the notification messages HookSpyRegister(). In that way we managed to improve the performance of our product. But unfortunately we couldn’t reach the level of efficiency of the product made on the base of the library version 2.8.0. Probably, we couldn’t do so for the following reasons:

In particular, the widely used class CExtDynamicBarSite includes CExtTabPageContainerWnd class and doesn’t have constructor which allows to create an object of this class (CExtTabPageContainerWnd) with disabled notification messages (excluded HookSpyRegister() subscription). Besides, we didn’t do detailed research regarding the implementation of the classes CExtToolControlBar and CExtMenuControlBar but it’s possible that these classes have been modified too, and such changes in the process of repainting of objects by timer (and others) might have affected the performance as well.

Please could you give us some advice on how to achieve an acceptable level of performance (as in the version 2.8.0)?

Thank you in advance for your assistance.

We solved many performance issues in Prof-UIS 2.84. The CExtHookSpy interface was re-coded and now installs only requested hook callbacks. I.e. if some class requires keyboard hooking, then only keyboard callback function is installed. This maximally reduces time which process spends for hook functions invocation. The timer based animations are used by ribbon controls, scroll bars, buttons, check boxes, radio buttons and some other simple controls. These animations are also available in toolbars. But by default toolbars does not use any animations for their buttons. We think current performance of Prof-UIS 2.84 is same as 2.80. We can provide you with pre-release 2.84 download.

Dear Support,

I have a grid when each row have a number cell header on the left side.

I want that the row, or the first editable cell in the row will be selected when the number cell is pressed. Cuurently when I hover over the number cell, the cursor changes to a left pointing arrow, and clicks are ignored.

This is how I initialize this cell:

    CExtGridCellHeader* pCellHeader = (CExtGridCellHeader*)GridCellGetOuterAtLeft(0, nRowCountIndex, RUNTIME_CLASS(CExtGridCellHeader));
    
    if (NULL==pCellHeader)
    {
        return -1;
    }

    pCellHeader->ModifyStyle(
        __EGCS_HDR_FOCUS_ARROW_RESERVE_SPACE|
        __EGCS_HDR_FOCUS_ARROW_DISPLAY|
        __EGCS_HDR_ROW_COLUMN_NUMBER|
        __EGCS_TA_HORZ_RIGHT);

Thanks,

Ron.

A click on a header cell can be used for sorting rows/columns or selecting them. We thing you should simply apply the __EGBS_SF_SELECT_OUTER_ROWS style with the grid’s SiwModifyStyle() method.

I have this flag set, and still, when clicking the row header cell nothing happens. I sort my rows by clicking the column headers, I don’t need to sort columns, the row header is used to give each row a serial number to identify the rows, so I would like it that when the number is pressed, the first cell in the row will be selected.