Forum

Hi,

I call CExtControlBar::ProfileBarStateSerialize to serialize the state of control bars.  The first time a user runs the program, this function returns false and I know to set my control bars up in the default way instead.  However, if I add a new control bar to the program, then the function returns true for previous users because they still have old serialization data, but the new control bar neither gets serialized (because it wasn’t in the old version of the data) nor does it get initialised to a default layout.  How should I handle this?  How do I reckonise after calling CExtControlBar::ProfileBarStateSerialize that a particular control bar failed to load any data?

Thanks,

Rob.

The control bar state serialization code requires exact matching between the state data and bars created in the main frame window. There are two additional subsystems which support dynamic count of bars:

- The CExtCustomizeSite class supports dynamic count of toolbars because the user can create new toolbars in the customize dialog.

- The CExtDynamicBarSite class manages dynamically allocated resizable control bars (CExtDynamicControlBar).

The states of these subsystems should be loaded before loading bar states. These subsystems should create dynamic bars first. Both subsystems can really make your application using version dependent counts of control bars and provide support for version independent bar states.

Also, even though I call SetInitDesiredSizeFloating(CSize(144, 219)) for my new control bar, it’s floating size after the first serialization (using old data that doesn’t include the new bar) is set back to (16,16), which gives me a tiny and useless control bar. Does this happen to everyone using ProfUIS?  Surely I must be doing something wrong, but what?

Finally, an assertion is hit during startup:

>    ProfUIS285nd.dll!CExtCustomizeSite::CustomizeStateSerialize(CArchive & ar={...}, bool bEnableThrowExceptions=false)  Line 10758 + 0x22 bytes    C++

But there’s no error.  A new control bar has been added since the user last ran the program, so the control bar can’t be found in the last serialisation data.  I don’t think there should be an assertion unless something has gone wrong.

Thanks,

Rob.

 

Seems a lot of the default data in a control bar is overridden with rubbish when no serialisation data is found, including the initial floating size, horizontal docking size, vertical docking size, and the bar becomes hidden.

Hello.

I want to connect a dialogue to CExtShellDialogFile

I ask for the offer of the sample program.

I ask as soon as possible.

Thanks,

We modified your project. The CExtResizableDialog class does not support scrolling. So, we created a CExtScrollContainerWnd window and then we created a CExtResizableDialog dialog inside it. Please take a look at the source code related to the new CExtScrollContainerWnd m_wndScrollContainer; property in the CNxcMainDlg class. Here is the modified version of your project:

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

Hello.

>shell list view control with some other window.

I do not want to perform changing of ShellListView.

I want to realize a screen such as CFormView.

However, cannot CFormView be realized with the Dialog form.

Therefore I intended to use CExtSplitterWnd of FOSS.

I made a sample first of all.

I got possible to display the dialogue, but am troubled because scroll bar is not displayed.

http://ifreeta.dee.cc/20090824/SampleSplit2.lzh

Dear Support,

I have a node with two children leafs, and I have my own derive cell type in both of the leafs.

I override OnClick of my cell, and I want to catch double-click, waiting for nRepCnt==2.

The problem is that if I click once on the first node, and then once on the second node, I get nRepCnt equals to 2, and I think there was a double-click, which there was not.

Please fix and let me know.

Thanks,

Ron.

We fixed this issue some time ago. The void CExtGridBaseWnd::OnLButtonDown() method should begin with the following code:

void CExtGridBaseWnd::OnLButtonDown(UINT nFlags, CPoint point) 
{
      ASSERT_VALID( this );

      if( m_eMTT != __EMTT_NOTHING )
      {
            SendMessage( WM_CANCELMODE );
            if( m_eMTT != __EMTT_NOTHING )
                  return;
      } // if( m_eMTT != __EMTT_NOTHING )
UINT nRepCnt = 1;
static clock_t g_nLastClock = 0;
static HWND g_hWndLastClick = NULL;
static CPoint g_ptLastClick(-32767,-32767);
CPoint ptLastClick = point;
      ClientToScreen( &ptLastClick );
clock_t nCurrClock = ::clock();
      if(         g_hWndLastClick == m_hWnd
            &&    g_ptLastClick == ptLastClick
            )
      {
            clock_t nDiff = (clock_t)::abs( nCurrClock - g_nLastClock );
            clock_t nDoubleClickTime = (clock_t)::GetDoubleClickTime();
            if( nDiff <= nDoubleClickTime )
                  nRepCnt = 2;
      }
      g_ptLastClick = ptLastClick;
      g_hWndLastClick = m_hWnd;
      g_nLastClock = nCurrClock;

HWND hWndOwn = m_hWnd, hWndFocus = ::GetFocus();
. . .

There is only one case when a double click can be generated not for the same cell which received the first click: this can happen when grid’s scrolling position changed between clicks. Is it your case?

Dear Support,

We have a drop-list with many items, we would like to group them into a tree.

Is there any ready-to-use control in Prof-UIS that does that?

Thanks,

Ron.

Is it possible to disable a tab of ribbon bar ( the ribbon nodes in the tab  could be either enabled or disalbed ) ?  The riibbon node can be disabled, but I didn’t see any function or attribute in the ribbon bar class to disable a tab

 

Hello,

Please, take a look at the attached picture. The size of the button file is wrong (not the icon) and the background color of the Quick Acces Menu is wrong too.

The code is from FormulaGrid merged with code from RibonBar sample. How to fix them?

Best regards,

Pelli

We checked both XP and Vista. We used Prof-UIS 2.85. Is it your current version?

Hello,

Yes, 2.85 is my current version. But I think that’s not the problem, once you provided static linked binary files. The file menu is in a wrong position. I tested in more two computers and the result are the same.

 

Do you use any specific DPI settings on your desktops?

No, I use the default settings.

Pelli

We compiled the modified version of the FormulaGrid sample application with Prof-UIS 2.85 and it shows normal layout. Here is the project:

http://www.prof-uis.com/download/forums/tmp/AntonioPelliNeto-FormulaGrid-BIN.zip
http://www.prof-uis.com/download/forums/tmp/AntonioPelliNeto-FormulaGrid-SRC.zip

Please do not forget to remove the registry HKEY_CURRENT_USER\Software\Foss\FormulaGrid folder before running this sample application.

Hello,

The RibbonBar sample and FormulaGrid sample look well in my computer. But the modified FormulaGrid Application look like you seen before int the picture.

Here are the link to mainfrm (.h and .cpp) that were modified.

www.pellisistemas.com.br/downloads/mainfrm.h

www.pellisistemas.com.br/downloads/mainfrm.cpp

 

Please let us know whether this incorrect layout can be seen in the RibbonBar sample application running on your computer? Or whether it can be seen in the modified version of the FormulaGrid sample application only?

 

An example

I want this problem to work out a solution

http://www.prof-uis.com/prof-uis/tech-support/support-forum/about-malfunction-to-occur-to-execute-directx-and-direct3d-in-a-full-screen-mode-65068.aspx

Hi,

I want to be able to drag and drop items from a tree control to an MDI tab.  Calling WindowFromPoint() returns a CWnd* which I can DYNAMIC_DOWNCAST to various things, such as a CExtTabMdiWnd.  But once I have the CExtTabMdiWnd, how do I find out which tab was clicked on?  That is, how do I find the tab given a CPoint?  And how do I find out which CView that represents?  I couldn’t see any useful methods to help with this.

Thanks,

Rob.

We implemented the insertion mark in the CExtTreeCtrl control. Here is the source code update:

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

The tab items have the LPARAM user defined property. It’s the HWND handle of MDI child frame window in case of MDI tabs:

CExtTabMdiWnd * pWndMdiTabs = . . .
LONG nCurSel =  pWndMdiTabs->SelectionGet();
      if( nCurSel < 0 L )
            return . . .
HWND hWnd =  pWndMdiTabs->ItemLParamGet( nCurSel );
      ASSERT( hWnd != NULL && ::IsWindow(hWnd) );
CWnd * pWndMdiChildFrame = CWnd::FromHandlePermanent( hWnd );
CWnd * pWndViewInsideMdiChildFrame = pWndMdiChildFrame->GetDlgItem( AFX_IDW_PANE_FIRST );

The update version of the

 CExtTreeCtrl::EnableItem()</code> method repaints enabled/disabled items.
<pre>void CExtTreeCtrl::EnableItem(
      HTREEITEM hti,
      bool bEnable // = true
      )
{
      ASSERT_VALID( this );
      if( hti == NULL )
            return;
TREEITEMINFO_t & _TII = TreeItemInfoGet( hti );
      if( ( _TII.m_bDisabled && bEnable ) || ( (!_TII.m_bDisabled) && (!bEnable) ) )
            return;
      _TII.m_bDisabled = ! bEnable;
      if( GetSafeHwnd() == NULL )
            return;
CRect rcItemEntire;
      TreeItemRectGet( hti, rcItemEntire, e_tirt_entire );
      if( rcItemEntire.IsRectEmpty() )
            return;
CRect rcClient;
      GetClientRect( &rcClient );
      if(         ( rcClient.top <= rcItemEntire.top && rcItemEntire.top <= rcClient.bottom )
            ||    ( rcClient.top <= rcItemEntire.bottom && rcItemEntire.bottom <= rcClient.bottom )
            )
            InvalidateRect( &rcItemEntire );
}

The SetInsertMark() method is not implemented yet. We didn’t implemented it because Prof-UIS classes use the non-rectangular window with form of red arrows displayed over other windows to highlight the dropping target. These red arrows are used instead of any insertion marks. We can assume the SetInsertMark() method is a feature request.

Thanks, although it seems this version of EnableItem() acts a little worse than the old one.  Previously I called Invalidate() for the tree after EnableItem(), which made sure it got redrawn right.  Now even this leaves all items shown as enabled!

It may be something to do with me using this call: AutoDisableChildrenItemsSet().  I am calling EnableItem() on the root node in order to enable/disable the entire tree.  Maybe you are only invalidating the root node.  But I don’t know why my subsequent call to Invalidate() would not redraw it properly anyway.

Oh, and you didn’t answer this: "Is there an article about drag/drop with ProfUIS?".  In particular I don’t understand how to do it in conjunction with a tree control.

Thanks,

Rob.

There was a typo in the CExtTreeCtrl::EnableItem() method. We are sorry for this inconvenience. Here is the correct version:

void CExtTreeCtrl::EnableItem(
      HTREEITEM hti,
      bool bEnable // = true
      )
{
      ASSERT_VALID( this );
      if( hti == NULL )
            return;
TREEITEMINFO_t & _TII = TreeItemInfoGet( hti );
      if( ( _TII.m_bDisabled && (!bEnable) ) || ( (!_TII.m_bDisabled) && bEnable ) )
            return;
      _TII.m_bDisabled = ! bEnable;
      if( GetSafeHwnd() == NULL )
            return;
CRect rcItemEntire;
      TreeItemRectGet( hti, rcItemEntire, e_tirt_entire );
      if( rcItemEntire.IsRectEmpty() )
            return;
CRect rcClient;
      GetClientRect( &rcClient );
      if(         ( rcClient.top <= rcItemEntire.top && rcItemEntire.top <= rcClient.bottom )
            ||    ( rcClient.top <= rcItemEntire.bottom && rcItemEntire.bottom <= rcClient.bottom )
            )
            InvalidateRect( &rcItemEntire );
}

The drag-n-drop number one in Windows world is OLE drag-n-drop. It’s used in the FormEditor sample application. It’s used by customizable toolbars and menus in Prof-UIS. It’s supported by Prof-UIS grid controls starting from version 2.85 and it’s demonstrated in the FormulaGrid sample application. It’s simple. It’s convenient. It can work between threads and processes. It’s so easy so you can either use Win32 or MFC APIs. It’s equally easy to use COleDataSource / COleDropSource / COleDropTargent classes from MFC or to implement IDataSource / IDropSource / IDropTargent interfaces from Win32. The OLE drag-n-drop and clipboard support code is always in intersected. If you decided to code one of these features, then you can code both of them. Here is the theoretical basics:

http://msdn.microsoft.com/en-us/library/96826a87(VS.80).aspx

There are many articles on the Internet like these:

http://www.codeproject.com/KB/shell/dragdrop.aspx?msg=180749
http://www.codeproject.com/KB/clipboard/dragsource.aspx

Please take a look at the FormEditor sample application. It implements drag-n-drop from the toolbox control into MDI form view window. You should use the same OLE drag-n-drop in your application. It the most widely used drag-n-drop implementation because it’s simple and convenient. The MDI tabs and resizable control bar tabs in Prof-UIS support dragging-over event handling and perform tab item selection automatically.

Hello.

When there is a focus to a docking bar

class CMainFrame : public CMDIFrameWnd
				 , public CExtHookSpy

I want to do hook of key input in OnHookSpyPreTranslateMessage.

However, OnHookSpyPreTranslateMessage and CMainFrame-PreTranslateMessage are called each.

  

When there is a focus to a bar,I want you to call only OnHookSpyPreTranslateMessage.

When there is a focus to a docking bar

When I want to transmit Del Key to only CEdit,

In OnHookSpyPreTranslateMessage, I do not return false

It is not transmitted a message.

And Del Key of MainFrame side reacts.

Is not there the good method?

 

The message hooking mechanism is not what you need:

CEdit * pEdit = . . .
pEdit->SendMessage( WM_KEYDOWN, VK_DELETE );

I’m using 2.87. I’ve overrided OnTabWndClickedItemCloseButton(LONG nItemIndex) in my class derived from CExtTabPageContainerFlatWnd.

I think it used to work but after some prof-uis update now it always gives nItemIndex=1 when callback is called. (4 tabs, 1st and last has no close button).

Maybe it was caused by this fix? http://www.prof-uis.com/prof-uis/tech-support/support-forum/cexttabpagecontainerflatwnd-bug-65089.aspx#@lt;/p>

Can you check this please? Thank you.

 

An error is displayed at the time of grid making.

I do DestroyWindow of a dialog grid.

Assert is displayed when I do Create again.

 

http://ifreeta.dee.cc/20090817/SampleMuGridbugtest.lzh

 

void CSampleDialog10Dlg::OnButton11() 
{
 OnButton10();
 pSunpoInpHojyoDlg->DestroyWindow( );
 OnButton10();
}
 
static CNxfKakouEditSunpoInpHojyoDlg  *pSunpoInpHojyoDlg = NULL;
void CSampleDialog10Dlg::OnButton10() 
{
    if ( pSunpoInpHojyoDlg == NULL ){
     //pSunpoInpHojyoDlg = new CNxfKakouEditSunpoInpHojyoDlg ;
     pSunpoInpHojyoDlg = new CNxfKakouEditSunpoInpHojyoDlg ;
    }
 pSunpoInpHojyoDlg->Create(
     CNxfKakouEditSunpoInpHojyoDlg::IDD ,
	 this
 );
}

 

Hi,

I’m trying to transfer some of our old CTreeCtrl’s to the Prof-UIS CExtTreeCtrl instead.  There are two problems though.

(1) CExtTreeCtrl seems to eat some mouse events and not pass them through.  Our derived tree class required the NM_CLICK, NM_DBLCLK and NM_RCLICK notifications, but when I change the base class to CExtTreeCtrl, these notifications are no longer received.  Can this be fixed?

(2) Just a minor incompatibility: SelectItem() now requires at least two arguments, whereas it previously only required one.  I suggest you make the second argument default to true (for selection rather than deselection).  This was easy enough to work-around by deriving my own tree control and over-riding SelectItem() to provide this default second arg, but I suggest you do it in the Prof-UIS code too.

Thanks,

Rob.

I think I found another problem with CExtTreeCtrl.  It doesn’t always call OnLButtonUp() when the left button is released.  It does get called if you drag between the button down and up, or if you click to expand an item, but if you just click on an item and release without moving the mouse, then OnLButtonUp() is not called.

Thanks,

Rob.

Thank you for reporting this issue. Please update the source code for the following two methods:

bool CExtControlBar::stat_DragDetect_ImplStep(
      HWND hWnd,
      POINT pt,
      UINT nUpMessage // = WM_LBUTTONUP
      )
{
      if( hWnd == NULL || (! ::IsWindow( hWnd ) ) )
            return false;
CSize sizeDrag( ::GetSystemMetrics( SM_CXDRAG ), ::GetSystemMetrics( SM_CYDRAG ) );
CRect rc( pt.x - sizeDrag.cx, pt.y - sizeDrag.cy, pt.x + sizeDrag.cx, pt.y + sizeDrag.cy );
      ::SetCapture( hWnd );
      for( MSG _msg; ::IsWindow( hWnd ) ; )
    {
        for(      ;
                        ::IsWindow( hWnd )
                  &&    (     ::PeekMessage( &_msg, 0, WM_MOUSEFIRST, WM_MOUSELAST, PM_NOREMOVE )
                        ||    ::PeekMessage( &_msg, 0, WM_CANCELMODE, WM_CANCELMODE, PM_NOREMOVE )
                        ||    ::PeekMessage( &_msg, 0, WM_ACTIVATEAPP, WM_ACTIVATEAPP, PM_NOREMOVE )
                        )
                        ;
                        )
        {
            if(         _msg.message == nUpMessage
                        ||    _msg.message == WM_CANCELMODE
                        ||    _msg.message == WM_ACTIVATEAPP
                        )
            {
                ::ReleaseCapture();
                return false;
            }
                  ::PeekMessage( &_msg, 0, _msg.message, _msg.message, PM_REMOVE );
            if( _msg.message == WM_MOUSEMOVE )
            {
                CPoint ptMessage( LOWORD( _msg.lParam ), HIWORD( _msg.lParam ) );
                if( ! rc.PtInRect( ptMessage ) )
                {
                    ReleaseCapture();
                    return true;
                }
            }
       }
        ::WaitMessage();
    }
    return false;
}

bool CExtControlBar::stat_DoDragDetect(
      HWND hWnd,
      const POINT & ptWndClient,
      UINT nUpMessage // = WM_LBUTTONUP
      )
{
      if( hWnd == NULL || (! ::IsWindow( hWnd ) ) )
            return false;
CPoint ptScreen = ptWndClient;
      ::ClientToScreen( hWnd, &ptScreen );
      for( ; stat_DragDetect_ImplStep( hWnd, ptScreen, nUpMessage ) ; )
      {
            POINT ptCursorPos = { -32767, -32767 };
            if( ! ::GetCursorPos( &ptCursorPos ) )
                  return false;
            if(  ptScreen == ptCursorPos )
                  continue; //only drag time elapsed but mouse is not moved
            return true;
      }
      return false;
}

Something strange is still happening.  Now my OnLButtonUp callback gets called, but sometimes a drag operation starts AFTER the button up message.  Doesn’t happen if you click and hold before releasing, or if the mouse moves while the button is down, but if you just click and release quickly, the TVN_BEGINDRAG message arrives AFTER the button up message.  This causes problems of course because button-up is supposed to mark the end of the drag.

Thanks,

Rob.

More info: the button-up event is sent downstream fromCExtTreeCtrl::OnLButtonDown.  That doesn’t seem right.  Then the begin-drag event is sent after button-up.  Here’s a stack trace showing button-up being called downstream from button-down.  As I said this only happens if you tap the button quickly.

 

>    cadwind.exe!ViewTreeCtrl::OnLButtonUp(unsigned int nFlags=0, CPoint point={...})  Line 258    C++
	 mfc80d.dll!CWnd::OnWndMsg(unsigned int message=514, unsigned int wParam=0, long lParam=12058691, long * pResult=0x0013a47c)  Line 2169    C++
	 mfc80d.dll!CWnd::WindowProc(unsigned int message=514, unsigned int wParam=0, long lParam=12058691)  Line 1741 + 0x20 bytes    C++
	 ProfUIS285nd.dll!CExtTreeCtrl::WindowProc(unsigned int message=514, unsigned int wParam=0, long lParam=12058691)  Line 4500 + 0x14 bytes    C++
	 cadwind.exe!CExtNCSB_Impl<CExtTreeCtrl>::WindowProc(unsigned int message=514, unsigned int wParam=0, long lParam=12058691)  Line 1145 + 0x17 bytes    C++
	 mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x0fd84a18, HWND__ * hWnd=0x000e1752, unsigned int nMsg=514, unsigned int wParam=0, long lParam=12058691)  Line 240 + 0x1c bytes    C++
	 mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x000e1752, unsigned int nMsg=514, unsigned int wParam=0, long lParam=12058691)  Line 389    C++
	 mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x000e1752, unsigned int nMsg=514, unsigned int wParam=0, long lParam=12058691)  Line 411 + 0x15 bytes    C++
	 user32.dll!7e418734()     
	 [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]    
	 user32.dll!7e418816()     
	 user32.dll!7e4189cd()     
	 user32.dll!7e41ca67()     
	 user32.dll!7e4196c7()     
	 cadwind.exe!gr_intr(int * type=0x0013a880, int clearbuffer=0)  Line 5107 + 0xc bytes    C++
	 cadwind.exe!CheckUserAbort()  Line 491 + 0xb bytes    C++
	 cadwind.exe!CGLRenderer::DrawSurfaces(CGLRenderer::enumDrawType drawtype=drawSurfaceAll)  Line 959 + 0x5 bytes    C++
	 cadwind.exe!CGLRenderer::DrawSubwin(bool bClear=false)  Line 273    C++
	 cadwind.exe!CGLRenderer::RenderScene(bool bClear=false)  Line 2027    C++
	 cadwind.exe!CCadView::ViewDrawSubWindow(int nSubno=0, int nAction=1, bool bClear=true)  Line 366 + 0xa bytes    C++
	 cadwind.exe!CCadView::ViewDraw(int iSubno=-1, int nAction=1)  Line 122 + 0x14 bytes    C++
	 cadwind.exe!dr_update(int clear=-1, int nAction=1)  Line 465 + 0x13 bytes    C++
	 cadwind.exe!dr_update(int clear=-1)  Line 478 + 0xd bytes    C++
	 cadwind.exe!vw_ChangeView(int subno=1, int nViewNum=10)  Line 1164 + 0xb bytes    C++
	 cadwind.exe!vw_select(int * redrawn=0x0013af80, int autoselect=1, const char * viewname=0x00000000)  Line 1139 + 0xd bytes    C++
	 cadwind.exe!CDockableViewDlg::SelectView(_TREEITEM * item=0x00232350)  Line 444 + 0x10 bytes    C++
	 cadwind.exe!CDockableViewDlg::OnSelectView(tagNMHDR * pNMHDR=0x0013baf4, long * pResult=0x0013b2a4)  Line 642    C++
	 mfc80d.dll!_AfxDispatchCmdMsg(CCmdTarget * pTarget=0x0fd84898, unsigned int nID=1308, int nCode=65134, void (void)* pfn=0x00ba1e9e, void * pExtra=0x0013b17c, unsigned int nSig=60, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000)  Line 112    C++
	 mfc80d.dll!CCmdTarget::OnCmdMsg(unsigned int nID=1308, int nCode=65134, void * pExtra=0x0013b17c, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000)  Line 381 + 0x27 bytes    C++
	 mfc80d.dll!CDialog::OnCmdMsg(unsigned int nID=1308, int nCode=5176942, void * pExtra=0x0013b17c, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000)  Line 85 + 0x18 bytes    C++
	 cadwind.exe!CDockableViewDlg::OnCmdMsg(unsigned int nID=1308, int nCode=5176942, void * pExtra=0x0013b17c, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000)  Line 674    C++
	 mfc80d.dll!CWnd::OnNotify(unsigned int __formal=1308, long lParam=1293044, long * pResult=0x0013b2a4)  Line 2326    C++
	 mfc80d.dll!CWnd::OnWndMsg(unsigned int message=78, unsigned int wParam=1308, long lParam=1293044, long * pResult=0x0013b2dc)  Line 1767 + 0x2a bytes    C++
	 mfc80d.dll!CWnd::WindowProc(unsigned int message=78, unsigned int wParam=1308, long lParam=1293044)  Line 1741 + 0x20 bytes    C++
	 ProfUIS285nd.dll!CExtWS<CExtADLG<CExtResDlg>,301>::WindowProc(unsigned int message=78, unsigned int wParam=1308, long lParam=1293044)  Line 1197    C++
	 ProfUIS285nd.dll!CExtWA<CExtWS<CExtADLG<CExtResDlg>,301> >::WindowProc(unsigned int message=78, unsigned int wParam=1308, long lParam=1293044)  Line 1844 + 0x14 bytes    C++
	 ProfUIS285nd.dll!CExtResizableDialog::WindowProc(unsigned int message=78, unsigned int wParam=1308, long lParam=1293044)  Line 378 + 0x14 bytes    C++
	 mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x0fd84898, HWND__ * hWnd=0x002216d8, unsigned int nMsg=78, unsigned int wParam=1308, long lParam=1293044)  Line 240 + 0x1c bytes    C++
	 mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x002216d8, unsigned int nMsg=78, unsigned int wParam=1308, long lParam=1293044)  Line 389    C++
	 mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x002216d8, unsigned int nMsg=78, unsigned int wParam=1308, long lParam=1293044)  Line 411 + 0x15 bytes    C++
	 user32.dll!7e418734()     
	 user32.dll!7e418816()     
	 user32.dll!7e41b4c0()     
	 user32.dll!7e41b50c()     
	 ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x13 bytes    
	 user32.dll!7e4194be()     
	 user32.dll!7e41d4e4()     
	 user32.dll!7e41b903()     
	 comctl32.dll!773eab19()     
	 comctl32.dll!77407392()     
	 comctl32.dll!77407720()     
	 user32.dll!7e41bf78()     
	 comctl32.dll!7740885c()     
	 comctl32.dll!774096bd()     
	 comctl32.dll!7740af3f()     
	 mfc80d.dll!CWnd::OnWndMsg(unsigned int message=4363, unsigned int wParam=9, long lParam=2302800, long * pResult=0x0fd84a18)  Line 1866 + 0x19 bytes    C++
	 mfc80d.dll!CWnd::WindowProc(unsigned int message=4363, unsigned int wParam=9, long lParam=2302800)  Line 1742 + 0x1c bytes    C++
	 ProfUIS285nd.dll!CExtTreeCtrl::WindowProc(unsigned int message=4363, unsigned int wParam=9, long lParam=2302800)  Line 4500 + 0x14 bytes    C++
	 cadwind.exe!CExtNCSB_Impl<CExtTreeCtrl>::WindowProc(unsigned int message=4363, unsigned int wParam=9, long lParam=2302800)  Line 1145 + 0x17 bytes    C++
	 mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x0fd84a18, HWND__ * hWnd=0x000e1752, unsigned int nMsg=4363, unsigned int wParam=9, long lParam=2302800)  Line 240 + 0x1c bytes    C++
	 mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x000e1752, unsigned int nMsg=4363, unsigned int wParam=9, long lParam=2302800)  Line 389    C++
	 mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x000e1752, unsigned int nMsg=4363, unsigned int wParam=9, long lParam=2302800)  Line 411 + 0x15 bytes    C++
	 user32.dll!7e418734()     
	 user32.dll!7e418816()     
	 user32.dll!7e41b4c0()     
	 user32.dll!7e41b50c()     
	 ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x13 bytes    
	 user32.dll!7e4194be()     
	 user32.dll!7e41d890()     
	 user32.dll!7e42f3cc()     
	 mfc80d.dll!CTreeCtrl::SelectItem(_TREEITEM * hItem=0x00232350)  Line 288 + 0x44 bytes    C++
	 ProfUIS285nd.dll!CExtTreeCtrl::FocusItem(_TREEITEM * hti=0x00232350, bool bSelect=true, bool bUnselectOtherItems=true, bool bMouseClickEvent=true)  Line 5129    C++
	 ProfUIS285nd.dll!CExtTreeCtrl::OnTreeMouseClick(_TREEITEM * hti=0x00232350, unsigned long dwHitTestFlags=4, int nMouseButton=1, int nClick=0, unsigned int nMouseEventFlags=1, CPoint point={...})  Line 5545    C++
	 ProfUIS285nd.dll!CExtTreeCtrl::_OnTreeMouseClickImpl(int nMouseButton=1, int nClick=0, unsigned int nMouseEventFlags=1, CPoint point={...})  Line 5236 + 0x2e bytes    C++
>    ProfUIS285nd.dll!CExtTreeCtrl::OnLButtonDown(unsigned int nFlags=1, CPoint point={...})  Line 5146 + 0x18 bytes    C++
     cadwind.exe!ViewTreeCtrl::OnLButtonDown(unsigned int nFlags=1, CPoint point={...})  Line 246 + 0x17 bytes    C++
	 mfc80d.dll!CWnd::OnWndMsg(unsigned int message=513, unsigned int wParam=1, long lParam=12058691, long * pResult=0x0013c4c4)  Line 2169    C++
	 mfc80d.dll!CWnd::WindowProc(unsigned int message=513, unsigned int wParam=1, long lParam=12058691)  Line 1741 + 0x20 bytes    C++
	 ProfUIS285nd.dll!CExtTreeCtrl::WindowProc(unsigned int message=513, unsigned int wParam=1, long lParam=12058691)  Line 4500 + 0x14 bytes    C++
	 cadwind.exe!CExtNCSB_Impl<CExtTreeCtrl>::WindowProc(unsigned int message=513, unsigned int wParam=1, long lParam=12058691)  Line 1145 + 0x17 bytes    C++
	 mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x0fd84a18, HWND__ * hWnd=0x000e1752, unsigned int nMsg=513, unsigned int wParam=1, long lParam=12058691)  Line 240 + 0x1c bytes    C++
	 mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x000e1752, unsigned int nMsg=513, unsigned int wParam=1, long lParam=12058691)  Line 389    C++
	 mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x000e1752, unsigned int nMsg=513, unsigned int wParam=1, long lParam=12058691)  Line 411 + 0x15 bytes    C++
	 user32.dll!7e418734()     
	 user32.dll!7e418816()     
	 user32.dll!7e4189cd()     
	 user32.dll!7e418a10()     
	 user32.dll!7e42d99d()     
	 user32.dll!7e43c69b()     
	 mfc80d.dll!CWnd::IsDialogMessageA(tagMSG * lpMsg=0x0013cee0)  Line 198    C++
	 mfc80d.dll!CWnd::PreTranslateInput(tagMSG * lpMsg=0x0013cee0)  Line 4268    C++
	 mfc80d.dll!CDialog::PreTranslateMessage(tagMSG * pMsg=0x0013cee0)  Line 80    C++
	 ProfUIS285nd.dll!CExtWS<CExtADLG<CExtResDlg>,301>::PreTranslateMessage(tagMSG * pMsg=0x0013cee0)  Line 622    C++
	 ProfUIS285nd.dll!CExtResizableDialog::PreTranslateMessage(tagMSG * pMsg=0x0013cee0)  Line 593    C++
	 mfc80d.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop=0x00161586, tagMSG * pMsg=0x0013cee0)  Line 2882 + 0x14 bytes    C++
	 mfc80d.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x0013cee0)  Line 233 + 0x12 bytes    C++
	 mfc80d.dll!CWinThread::PreTranslateMessage(tagMSG * pMsg=0x0013cee0)  Line 773 + 0x9 bytes    C++
	 cadwind.exe!gr_event(int * type=0x0013d250, double * x=0x0013d21c, double * y=0x0013d20c, int * outside=0x0013d244, int * buttons=0x0013d238, std::basic_string<char,std::char_traits<char>,std::allocator<char> > & sReturnString="", long * returnparam=0x00000000, int UseResult=0)  Line 4087 + 0x22 bytes    C++
	 cadwind.exe!mn_get(const char * prompt=0x0013d418, const menu_def_t * menu=0x0013df60, int * mn_base=0x0013d2c0, int * item_no=0x0013d498, char * * string=0x0013d470, int * valid=0x0013d48c, int contextmenu=0, bool bWantWords=false, int default_number=-1)  Line 698 + 0x24 bytes    C++
	 cadwind.exe!mn_get(const char * prompt=0x0013d418, const menu_def_t * menu=0x0013df60, int * mn_base=0x0013d2c0, int * item_no=0x0013d498, char * * string=0x0013d470, int * valid=0x0013d48c, int contextmenu=0, bool bWantWords=false)  Line 568 + 0x27 bytes    C++
	 cadwind.exe!mn_select(const char * prompt=0x0013d418, const menu_def_t * menu=0x0013df60, int * item_no=0x0013d498, char * * string=0x0013d470, int * valid=0x0013d48c, int contextmenu=0, bool bWantWords=false)  Line 406 + 0x25 bytes    C++
	 cadwind.exe!CWinCadApp::RunTextMenuLoop(CCadApp::nRunMode Mode=ModeMODEL)  Line 1322 + 0x2c bytes    C++
	 cadwind.exe!CWinCadApp::RunModelLoop()  Line 1260    C++
	 cadwind.exe!CCadApp::RunMainLoop()  Line 325 + 0x12 bytes    C++
	 cadwind.exe!mdmain(int iargc=2, char * * argc=0x04cbe7c8)  Line 518 + 0x17 bytes    C++
	 cadwind.exe!CWinCadApp::Run()  Line 520 + 0x18 bytes    C++
	 mfc80d.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00162339, int nCmdShow=1)  Line 47 + 0xd bytes    C++
	 cadwind.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00162339, int nCmdShow=1)  Line 33    C++
	 cadwind.exe!__tmainCRTStartup()  Line 589 + 0x35 bytes    C
	 cadwind.exe!WinMainCRTStartup()  Line 414    C
	 kernel32.dll!7c816fd7()    

The call stack really shows that the WM_LBUTTONUP message is delivered when the WM_LBUTTONUP message is processes. But this is the normal situation. It occurred because some API invocations between ViewTreeCtrl::OnLButtonUp() and CExtTreeCtrl::OnLButtonDown() APIs in the call stack listing caused invocation of the message delivery.

OK, but the actual problems I’m experiencing are clearly errors.  Could you address those?

Firstly, I am receiving begin-drag events AFTER button-up events.  Standard practice is to end the drag when button-up arrives, which would mean that the drag never ends.

Secondly, resizing the window often gets "stuck", where you release the mouse button but it keeps resizing anyway, but only to make it smaller.  This frustrates me and users of our software.  I have seen the effect in your ribbon bar sample, especially in the debug build (I think just because it slows the program down), so it is not our error.  I have reported this several times over many months and never even got a reply to say whether or not you can reproduce it.

Thanks,

Rob.

Here is the latest source code for the CExtTreeCtrl class:

http://www.prof-uis.com/download/forums/tmp/ExtCommonControls-27-August-2009-for-RobertWebb.zip

Here is the latest source code for the drag-n-drop detection methods:

 bool CExtControlBar::stat_DragDetect_ImplStep(
      HWND hWnd,
      POINT pt,
      UINT nUpMessage // = WM_LBUTTONUP
      )
{
      if( hWnd == NULL || (! ::IsWindow( hWnd ) ) )
            return false;
CSize sizeDrag( ::GetSystemMetrics( SM_CXDRAG ), ::GetSystemMetrics( SM_CYDRAG ) );
CRect rc( pt.x - sizeDrag.cx, pt.y - sizeDrag.cy, pt.x + sizeDrag.cx, pt.y + sizeDrag.cy );
      ::SetCapture( hWnd );
      for( MSG _msg; ::IsWindow( hWnd ) ; )
    {
        for(      ;
                        ::IsWindow( hWnd )
                  &&    (     ::PeekMessage( &_msg, hWnd, WM_MOUSEFIRST, WM_MOUSELAST, PM_NOREMOVE )
                        ||    ::PeekMessage( &_msg, 0, WM_CANCELMODE, WM_CANCELMODE, PM_NOREMOVE )
                        ||    ::PeekMessage( &_msg, 0, WM_ACTIVATEAPP, WM_ACTIVATEAPP, PM_NOREMOVE )
                        )
                        ;
                        )
        {
            if(         _msg.message == nUpMessage
                        ||    _msg.message == WM_CANCELMODE
                        ||    _msg.message == WM_ACTIVATEAPP
                        )
            {
                ::ReleaseCapture();
                return false;
            }
                  ::PeekMessage( &_msg, hWnd, _msg.message, _msg.message, PM_REMOVE );
            if( _msg.message == WM_MOUSEMOVE )
            {
                CPoint ptMessage( LOWORD( _msg.lParam ), HIWORD( _msg.lParam ) );
                if( ! rc.PtInRect( ptMessage ) )
                {
                    ReleaseCapture();
                    return true;
                }
            }
       }
        ::WaitMessage();
    }
    return false;
}

bool CExtControlBar::stat_DoDragDetect(
      HWND hWnd,
      const POINT & ptWndClient,
      UINT nUpMessage // = WM_LBUTTONUP
      )
{
      if( hWnd == NULL || (! ::IsWindow( hWnd ) ) )
            return false;
CPoint ptScreen = ptWndClient;
      ::ClientToScreen( hWnd, &ptScreen );
      for( ; stat_DragDetect_ImplStep( hWnd, ptScreen, nUpMessage ) ; )
      {
            POINT ptCursorPos = { -32767, -32767 };
            if( ! ::GetCursorPos( &ptCursorPos ) )
                  return false;
            if(  ptScreen == ptCursorPos )
                  continue; //only drag time elapsed but mouse is not moved
            return true;
      }
      return false;
}

We made the several left and right mouse button based drag-n-dropping tests with the ProfUIS_Controls sample application. We set breakpoints at the beginning of the CExtTreeCtrl::OnLButtonUp and CExtTreeCtrl::OnRButtonUp methods in Prof-UIS source code. We used the Tree View dialog page in the ProfUIS_Controls sample application because the CPageTreeCtrl::OnBegindragTree1 and CPageTreeCtrl::OnBeginRdragTree1 methods are displaying message boxes when the TVN_BEGINDRAG and TVN_BEGINRDRAG notifications are sent. The message boxes are displayed always earlier than the debugger breaks at the set breakpoints.
It looks like we fixed the window resizing behavior. Please open the source .../Prof-UIS/Src/ExtNcFrame.cpp file and find the WM_ENTERSIZEMOVE text in it. There are two cases. Both code snippets are looking very similar. You will find the following lines in both cases:

::SendMessage( hWnd, WM_ENTERSIZEMOVE, 0L, 0L );

Then you will find the following nested code statements a bit closer from the line above in the both cases:

                   bool bStop = false;
                        for( ; ! bStop ; )
                        {
                              ::WaitMessage();
                              MSG msg;
                              // Process all the messages in the message queue
                              while( PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE ) )
                              {
                                    switch( msg.message )
                                    {

The switch( msg.message ) statement contains the following in both cases:

                               case WM_MOUSEMOVE:
                                          ::PeekMessage( &msg, NULL, 0, 0, PM_REMOVE );
                                          if( msg.hwnd == hWnd )
                                          {
                                                while( ::PeekMessage( &msg, hWnd, WM_MOUSEMOVE, WM_MOUSEMOVE, PM_REMOVE ) );

The while( ::PeekMessage( &msg, hWnd, WM_MOUSEMOVE, WM_MOUSEMOVE, PM_REMOVE ) ); line of code should be simply commented/removed in both cases.

Thanks for the code updates.  Unfortunately it doesn’t seem to fix anything.  I still get the window frame resizing after the mouse button is up, and clicking quickly on tree items can still cause the up-event to be sent before the begin-drag event.

I have worked around the tree problem by setting a flag on mouse-down and clearing it again on mouse-up, then checking that the flag is set in my begin-drag handler.  If it’s not set, then the drag is disallowed.  I also override OnCaptureChanged() in case my capture was lost while the button was down, meaning I might miss the mouse-up event.

You could do a similar thing I imagine to fix both the tree and frame-resizing problems.  Aside from the persistant resizing, we also have problems with the frame moving and resizing briefly after releasing the mouse button (to end a move or resize).  Our users have to move the mouse slowly to avoid this.  I often want to resize the window and quickly move the mouse elsewhere after letting go.  This can cause the window to follow my mouse back across the screen before stopping.  Very annoying.  In this case, I think it probably just handles one extra mouse-move event AFTER the mouse-up event.  Maybe it is similar to the other problem, with a mouse-move and mouse-up event being handled below mouse-down in the stack, meaning that mouse-down hasn’t finished being processed before the next mouse-move.  Or maybe you are polling the mouse position in mouse-up instead of using the position sent with the event?  That always causes problems.

Rob.

We solved this issue in Prof-UIS 2.87. Please drop us an e-mail to the support mail box at this web site so we will provide you with the FTP download for the latest Prof-UIS version.

I’m using 2.8.7 now and don’t see any difference.  I haven’t tested the tree stuff since I now have a work-around that works anyway, so maybe that was fixed.  But I still have the problem of the window resizing getting stuck, and now also sometimes moving the whole window gets stuck.  By stuck I mean that the operation continues to occur after the mouse button has been released.  It seems to have lost mouse-capture though, so the resizing only starts up again when you move the mouse back inside the window.  It’s quite difficult to get out of this situation when it happens.  Even clicking doesn’t always fix it.

Getting stuck moving the window is a new one, but that may be due to stuff I’m doing which slows down redraws in the view.  The ProfUIS problems seem worst when the view takes some time to redraw.  You could probably simulate it by putting a one-second sleep in your MDI ribbon bar sample in the redraw/resize.  Getting stuck moving the window happens as follows: I click on the title bar to bring the window to the front (when another window was previously obscuring part of our window).  Then, although I just did a quick click and release with no intention of moving the window, the window moves and follows the mouse anyway.

Along with the highly CPU-intensive and slow ribbon bar, these are probably the two most frustrating issues.  If it’s similar to the issue with tree control events arriving out of order, you could probably fix these by setting a flag on button-down and clearing it on button-up, then testing before any kind of drag operation (ie resizing or moving) and not doing it unless the flag is set.

Rob.

This problem of getting messages out of order reminds me of some of the more fundamental problems with ProfUIS.  For example, I’ve often seen the problem where ProfUIS doesn’t realise when you stop resizing the main window.  That is, you click on the resizable border, drag it to change the size, then release, but sometimes it keeps resizing anyway.  Well, sort of.  When it gets stuck in this state, you can move the mouse around outside the window without it resizing, but as soon as you move the mouse inside the window, the window starts resizing smaller again.  Very frustrating and hard to escape from.  I’ve seen it in our software on multiple machines, and also in ProfUIS’s own ribbon bar samples.  I think it’s made worse if the app does other computationally expensive stuff, so it isn’t usually noticable in the ProfUIS samples, although I have seen it several times when running the debug version of the ribbon bar sample.  Maybe the debug version is enough slower to make the effect more prevalent.  As for our software, it happens all the time.  This strikes me as similar because if you get your mouse events out of order, then you can miss the button-up event that should have stopped the window resizing.  Could this all be related?

Thanks,

Rob.

I noticed another problem with CExtTreeCtrl.  The TVN_ITEMEXPANDED notification is not sent when the user expands or collapses an item in the tree.  I’m using the Vista icons if that makes a difference.   I presume TVN_ITEMEXPANDING is also missing, although I didn’t test that.

Note: the TVN_ITEMEXPANDED notification IS sent when ExpandItem() is called in the code, but not when the user manually expands/collapses an item.

Thanks,

Rob.

Thank you for reporting this issue. Please update the source code for the following method:

BOOL CExtTreeCtrl::Expand( HTREEITEM hti, UINT nCode )
{
      ASSERT_VALID( this );
HWND hWndOwn = m_hWnd;
      if( hWndOwn == NULL || ( ! ::IsWindow( hWndOwn ) ) )
            return FALSE;
      if( hti == TVI_ROOT )
      {
            hti = GetRootItem();
            if( hti == NULL )
                  return FALSE;
      }
HWND hWndParent = ::GetParent( m_hWnd );
UINT nOwnID = GetDlgCtrlID();
CExtSafeString strItemText;
NM_TREEVIEW _data;
      ::memset( &_data, 0, sizeof(NM_TREEVIEW) );
      _data.hdr.hwndFrom = m_hWnd;
      _data.hdr.idFrom = nOwnID;
      _data.hdr.code = TVN_ITEMEXPANDING;
      _data.action = nCode;
      _data.itemOld.mask = TVIF_CHILDREN|TVIF_HANDLE|TVIF_PARAM|TVIF_STATE;
      _data.itemOld.hItem = hti;
      GetItem( &_data.itemOld );
      strItemText = GetItemText( hti );
      _data.itemOld.cchTextMax = INT(strItemText.GetLength());
      _data.itemOld.pszText = strItemText.IsEmpty() ? _T("") : LPTSTR(LPCTSTR(strItemText));
      _data.itemOld.mask |= TVIF_TEXT;
      ::memcpy( &_data.itemNew, &_data.itemOld, sizeof(TVITEM) );
      if( ! ::GetCursorPos( &_data.ptDrag ) )
            _data.ptDrag.x = _data.ptDrag.y = 0;
      if( ::SendMessage( hWndParent, WM_NOTIFY, WPARAM(nOwnID), LPARAM(&_data) ) != 0 )
            return TRUE;

      if( ! CTreeCtrl::Expand( hti, nCode ) )
            return FALSE;

      ::memset( &_data, 0, sizeof(NM_TREEVIEW) );
      _data.hdr.hwndFrom = m_hWnd;
      _data.hdr.idFrom = nOwnID;
      _data.hdr.code = TVN_ITEMEXPANDED;
      _data.action = nCode;
      _data.itemOld.mask = TVIF_CHILDREN|TVIF_HANDLE|TVIF_PARAM|TVIF_STATE;
      _data.itemOld.hItem = hti;
      GetItem( &_data.itemOld );
      strItemText = GetItemText( hti );
      _data.itemOld.cchTextMax = INT(strItemText.GetLength());
      _data.itemOld.pszText = strItemText.IsEmpty() ? _T("") : LPTSTR(LPCTSTR(strItemText));
      _data.itemOld.mask |= TVIF_TEXT;
      ::memcpy( &_data.itemNew, &_data.itemOld, sizeof(TVITEM) );
      if( ! ::GetCursorPos( &_data.ptDrag ) )
            _data.ptDrag.x = _data.ptDrag.y = 0;
      ::SendMessage( hWndParent, WM_NOTIFY, WPARAM(nOwnID), LPARAM(&_data) );

      return TRUE;
}

The WM_CREATE message cannot be handled by any dialog controls. The dialog template loading code creates all the dialog’s child windows. Then MFC subclasses them. Please use the PreSubclassWindow() virtual method.

The CExtTreeCtrl control does not support themed scroll bars. The CExtListCtrl does not supports them either. But the CExtNCSB template class can skin scroll bars of common controls. This means you should use the following class:

//
// In .H file:
//

class CAdvTreeCtrl : public CExtNCSB < CExtTreeCtrl >
{
public:
      DECLARE_DYNCREATE( CAdvTreeCtrl );
      CAdvTreeCtrl();
      virtual ~CAdvTreeCtrl();

      //{{AFX_VIRTUAL(CAdvTreeCtrl)
      protected:
      virtual void PreSubclassWindow();
      //}}AFX_VIRTUAL

protected:
      //{{AFX_MSG(CAdvTreeCtrl)
      //}}AFX_MSG
      DECLARE_MESSAGE_MAP()
};


//
// In .CPP file:
//

IMPLEMENT_DYNCREATE( CAdvTreeCtrl, CExtTreeCtrl );

CAdvTreeCtrl::CAdvTreeCtrl()
      : CExtNCSB < CExtTreeCtrl > ( true )
{
}

CAdvTreeCtrl::~CAdvTreeCtrl()
{
}

BEGIN_MESSAGE_MAP( CAdvTreeCtrl, CExtTreeCtrl )
      //{{AFX_MSG_MAP(CAdvTreeCtrl)
      //}}AFX_MSG_MAP
END_MESSAGE_MAP()

void CAdvTreeCtrl::PreSubclassWindow()
{
      CExtNCSB < CExtTreeCtrl > :: PreSubclassWindow();
      //
      // TO-DO: put your tree control initialization code here
      //
} 

Thanks.

One remaining problem with CExtTreeCtrl is that SelectItem() now seems to leave the previous item selected as well, even though the tree has multiple selection disabled.  Surely when multi-select is disabled, SelectItem() should deselect any other items before doing the selection?  Otherwise it’s incompatible with CTreeCtrl.

I notice the new method FocusItem(), which allows all other items to be deselected.  I’ll try that, although I’m not sure what additional side-effects giving focus to an item might have beyond just selecting it.

Thanks,

Rob.

Thank you for reporting this issue. Please update the source code for the CExtTreeCtrl::SelectItem() method:

void CExtTreeCtrl::SelectItem(
      HTREEITEM hti,
      bool bSelect, // = true
      bool bSubtract // = false
      )
{
      ASSERT_VALID( this );
      if( hti == NULL )
            return;
TREEITEMINFO_t & _TII = TreeItemInfoGet( hti );
      if( bSelect && bSubtract && _TII.m_bSelected )
            _TII.m_bSelected = false;
      else
            _TII.m_bSelected = bSelect;
      if( _TII.m_bSelected && (! MultipleSelectionGet() ) )
      {
            CList < HTREEITEM, HTREEITEM > _listSelectedItems;
            GetSelectedItemsList( _listSelectedItems );
            POSITION pos = _listSelectedItems.GetHeadPosition();
            for( ; pos != NULL; )
            {
                  HTREEITEM htiSel = _listSelectedItems.GetNext( pos );
                  if( htiSel == hti )
                        continue;
                  TREEITEMINFO_t & _TII_Sel = TreeItemInfoGet( htiSel );
                  _TII_Sel.m_bSelected = false;
            }
      }
}

Thanks.  There still seem to be some issues though:

(1) After calling SelectItem() the tree is not redrawn, so the old selection appears to remain selected until it redraws for another reason.

(2) The focus rectangle is still visible around the previously selected item.  What is this for?  Is it at all relevant in a single-selection tree?  It’s visually confusing to have one item highlighted and another with a rectangle around it in a tree that only allows a single item to be selected.

Thanks,

Rob.

Here is the updated CExtTreeCtrl::SelectItem() method:

 void CExtTreeCtrl::SelectItem(
      HTREEITEM hti,
      bool bSelect, // = true
      bool bSubtract // = false
      )
{
      ASSERT_VALID( this );
      if( hti == NULL )
            return;
HWND hWndOwn = GetSafeHwnd();
TREEITEMINFO_t & _TII = TreeItemInfoGet( hti );
bool bWasSelected =  _TII.m_bSelected;
      if( bSelect && bSubtract && _TII.m_bSelected )
            _TII.m_bSelected = false;
      else
            _TII.m_bSelected = bSelect;
CList < HTREEITEM, HTREEITEM > _listInvalidateItems;
      if( _TII.m_bSelected && (! MultipleSelectionGet() ) )
      {
            CList < HTREEITEM, HTREEITEM > _listSelectedItems;
            GetSelectedItemsList( _listSelectedItems );
            POSITION pos = _listSelectedItems.GetHeadPosition();
            for( ; pos != NULL; )
            {
                  HTREEITEM htiSel = _listSelectedItems.GetNext( pos );
                  if( htiSel == hti )
                        continue;
                  TREEITEMINFO_t & _TII_Sel = TreeItemInfoGet( htiSel );
                  _TII_Sel.m_bSelected = false;
                  if( hWndOwn != NULL )
                        _listInvalidateItems.AddTail( htiSel );
            }
      }
      if( hWndOwn == NULL || (! IsWindowVisible() ) )
            return;
      if( ( bWasSelected && (!_TII.m_bSelected) ) || ( (!bWasSelected) && _TII.m_bSelected ) )
            _listInvalidateItems.AddTail( hti );
POSITION pos = _listInvalidateItems.GetHeadPosition();
      if( pos == NULL )
            return;
CRect rcClient, rcItemEntire;
      GetClientRect( &rcClient );
      for( ; pos != NULL; )
      {
            HTREEITEM htiRedraw = _listInvalidateItems.GetNext( pos );
            TreeItemRectGet( htiRedraw, rcItemEntire, e_tirt_entire );
            if( rcItemEntire.IsRectEmpty() )
                  continue;
            if(         ( rcClient.top <= rcItemEntire.top && rcItemEntire.top <= rcClient.bottom )
                  ||    ( rcClient.top <= rcItemEntire.bottom && rcItemEntire.bottom <= rcClient.bottom )
                  )
                  InvalidateRect( &rcItemEntire );
      }
}

Now it repaints changed selection. But we cannot make it exactly similar to the CTreeCtrl::SelectItem() method because the focus and selection are two different features in the CExtTreeCtrl control.
We did several other improvements in the tree control:
http://www.prof-uis.com/download/forums/tmp/UpdatedExtTreeCtrl-For-RobertWebb.zip

We implemented the NM_KEYDOWN, NM_CLICK, NM_DBLCLK, NM_RCLICK and NM_RDBLCLK notifications in the CExtTreeCtrl control. We made the true flag the default value of the bool bSelect parameter in the CExtTreeCtrl::SelectItem() method. Here is the source code update:

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

Thanks.  There’s a compile error though:

..\Src\ExtControlsCommon.cpp(5077) : error C2660: ’CExtControlBar::stat_DoDragDetect’ : function does not take 3 arguments

Do I need the new version of ExtControlBar.cpp/h too?

Thanks,

Rob.

The CExtControlBar::stat_DoDragDetect() static method is a better version of the DragDetect() Win32 API. Now this static method supports drag-n-drop starting detection by any mouse button - not only by left mouse button:

       static bool stat_DragDetect_ImplStep(
            HWND hWnd,
            POINT pt,
            UINT nUpMessage = WM_LBUTTONUP
            );
      static bool stat_DoDragDetect(
            HWND hWnd,
            const POINT & ptWndClient,
            UINT nUpMessage = WM_LBUTTONUP
            );


bool CExtControlBar::stat_DragDetect_ImplStep(
      HWND hWnd,
      POINT pt,
      UINT nUpMessage // = WM_LBUTTONUP
      )
{
      if( hWnd == NULL || (! ::IsWindow( hWnd ) ) )
            return false;
CSize sizeDrag( ::GetSystemMetrics( SM_CXDRAG ), ::GetSystemMetrics( SM_CYDRAG ) );
CRect rc( pt.x - sizeDrag.cx, pt.y - sizeDrag.cy, pt.x + sizeDrag.cx, pt.y + sizeDrag.cy );
      ::SetCapture( hWnd );
      for( MSG _msg; ::IsWindow( hWnd ) ; )
    {
        for( ; ::IsWindow( hWnd ) && ::PeekMessage( &_msg, 0, WM_MOUSEFIRST, WM_MOUSELAST, PM_REMOVE ) ; )
        {
            if(         _msg.message == nUpMessage
                        ||    _msg.message == WM_CANCELMODE
                        ||    _msg.message == WM_ACTIVATEAPP
                        )
            {
                ::ReleaseCapture();
                return false;
            }
            if( _msg.message == WM_MOUSEMOVE )
            {
                CPoint ptMessage( LOWORD( _msg.lParam ), HIWORD( _msg.lParam ) );
                if( ! rc.PtInRect( ptMessage ) )
                {
                    ReleaseCapture();
                    return true;
                }
            }
        }
        ::WaitMessage();
    }
    return false;
}

bool CExtControlBar::stat_DoDragDetect(
      HWND hWnd,
      const POINT & ptWndClient,
      UINT nUpMessage // = WM_LBUTTONUP
      )
{
      if( hWnd == NULL || (! ::IsWindow( hWnd ) ) )
            return false;
CPoint ptScreen = ptWndClient;
      ::ClientToScreen( hWnd, &ptScreen );
      for( ; stat_DragDetect_ImplStep( hWnd, ptScreen, nUpMessage ) ; )
      {
            POINT ptCursorPos = { -32767, -32767 };
            if( ! ::GetCursorPos( &ptCursorPos ) )
                  return false;
            if(  ptScreen == ptCursorPos )
                  continue; //only drag time elapsed but mouse is not moved
            return true;
      }
      return false;
}

Does Prof-UIS compile with Windows Server 2003 Platform SDK (the latest Platform SDK comptiable with Visual C++ 6.0)?

My Visual C++ 6.0 project was statically linked to Prof-UIs 2.85 and compiled without any problems. But it does not complie when I started using the Window Platform SDK in my project. The errors are: 

Compiling...

StdAfx.cpp

   Prof-UIS multiple monitor support:

      built-in

   Automatically linking with Prof-UIS library: ProfUIS285ymd.lib

      (Professional User Interface Suite)

c:\program files\microsoft visual studio\vc98\include\transact.h(226) : error C2059: syntax error : ’constant’

c:\program files\microsoft visual studio\vc98\include\transact.h(271) : error C2143: syntax error : missing ’;’ before ’}’

c:\program files\microsoft visual studio\vc98\include\oledb.h(17149) : error C2143: syntax error : missing ’;’ before ’}’

c:\program files\microsoft visual studio\vc98\include\oledb.h(17149) : error C2143: syntax error : missing ’;’ before ’}’

c:\program files\microsoft visual studio\vc98\include\oledb.h(17149) : error C2143: syntax error : missing ’;’ before ’}’

Any suggestions?

Regards

Robert

This is the easiest solution. The Prof-UIS source code does not need to be modified in this case. Then you can include only newer headers the new Platform SDK into your project. But this solution is not always can be applied. The Platform SDKs are often funny. For instance, the OLE automation APIs often contain the same functions with the same names but with larger parameter counts. This will require modification of Prof-UIS source code. We can make Prof-UIS compatible with Platform SDK 2003, but it will become incompatible with all the supported Visual C++ versions without installing appropriate Platform SDK additionally. We already did similar work several times by customer requests. The fix is simple but it can be different for different Platform SDKs. Only the ...\Prof-UIS\Include\Prof-UIS.h file needs to be modified. In some cases there is enough to add the #include < atlbase.h > line of code. In other cases we need to include particular Platform SDK header files. For instance, you encountered error in the transact.h file. This means you should try to include this file into the ...\Prof-UIS\Include\Prof-UIS.h file. If this does not solves problem, then you should find other Platform SDK’s header files which include the transact.h file and try to include other files into the ...\Prof-UIS\Include\Prof-UIS.h file.

This is the easiest solution. The Prof-UIS source code does not need to be modified in this case. Then you can include only newer headers the new Platform SDK into your project. But this solution is not always can be applied. The Platform SDKs are often funny. For instance, the OLE automation APIs often contain the same functions with the same names but with larger parameter counts. This will require modification of Prof-UIS source code. We can make Prof-UIS compatible with Platform SDK 2003, but it will become incompatible with all the supported Visual C++ versions without installing appropriate Platform SDK additionally. We already did similar work several times by customer requests. The fix is simple but it can be different for different Platform SDKs. Only the ...\Prof-UIS\Include\Prof-UIS.h file needs to be modified. In some cases there is enough to add the #include < atlbase.h > line of code. In other cases we need to include particular Platform SDK header files. For instance, you encountered error in the transact.h file. This means you should try to include this file into the ...\Prof-UIS\Include\Prof-UIS.h file. If this does not solves problem, then you should find other Platform SDK’s header files which include the transact.h file and try to include other files into the ...\Prof-UIS\Include\Prof-UIS.h file.

That’s not a solution. I need to use the Windows SDK in my project thus have to keep the Platform SDK include folders before Visual C++ include folders. Otherwise, my project will not compile. 

I tried to open the ProfUISLIB_600.dsw and build the Prof-Uis static lib manually (without using integration wizard) and had the same errors. Does that mean Prof-Uis can not work with Windows Platfrom SDK?

It will compile ok if you move the Platform SDK include folders to the bottom of the include folders list in you Visual C++ settings.

Hi

How is it possible to label a CExtBarButton or a CExtBarColorButton so that it would i.e diaplay "Pattern:" or "Color:" left of it?

Thanks - Peter

Hi,

I have embedded a CExtZoomScrollBar in a CMainFrame’s status bar. The CMainFrame is derived from CExtNCW<CFrameWnd> and it’s status bar from CExtStatusControlBar. The result looks great and is just what I want but I am not getting any ON_WM_HSCROLL messages via the CMainFrame’s message map.

I derived the code from your ZoomScrollBar example. I noticed that in the example you embed the CExtZoomScollBar in a ChildView’s status bar. 

I replaced

CMainFrame * pMainFrame = _GetMainFrame();

with

CMainFrame * pMainFrame = this;

Could this be the cause of the problem?

Your help with this is much appreciated.

Rgds,

Martin Ashton

Hello.

The background color of the point of the red arrow is dark.

It is hard to look.

I want to display it with a bright color.

 

Or can you change it by the setting of this place?

Hi

I’m facing a big problem trying to include the RibbonNodeFile in the Formula Grid Sample. I tried everything including copying the example from RibbonBars, but it didn’t work. I’m moving from CodeJock to Prof-UIS, but the help really didn’t help me.

Pelli

Hello,

Thank you for the information. It worked.

Best regards,

Pelli

Hello.

My program became gigantic.

It is necessary to appoint /Zm500.

If there is not optional appointment, it is not possible for build.

However, I appoint /Zm1000 and build.

Then the following build error comes.

Fatal Error C1060

http://msdn.microsoft.com/ja-jp/library/cc396351.aspx

The memory capacity of the PC.

Main memory 1GB.

Virtual memory 8GB.

Why does this happen?

I do not understand causes well.