How to properly enable a ribbon edit control

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   We have added a CXTPControlEdit to our ribbon. We set the control ID and in our OnCmdMsg handler we set the enable flag on the cmd UI object to TRUE. But we find our control is disabled.

After debugging I found that the command bars object calls UpdateDialogControls. While walking the child windows the code finds the edit control created by the CXTPEditControl (the m_pEdit member that is the actual windows edit control). Then the routine calls GetDlgCtrlID and sets that in a cmd UI object and calls OnCmdMsg.

Our OnCmdMsg simply sees the "m_pOther" object as a generic CWnd and of course the ID passed in is unknown to us (we disable any unknown IDs by default). Hence I have no real way to determine what I have and whether it should be enabled or not.

So I am wondering what is the best way to handle controls/windows on the ribbon for update UI purposes. After creating the CXTPControlEdit object should we get the m_pEdit member and call SetDlgCtrlID to something we would recognize (probably the same value we set on the CXTPControlEdit object)? It looks like I can set the control ID to zero too.

Or is there some other method I have overlooked that lets us talk to the generic CXTPControl class where I can set the dialog control ID of the underlying object? Something else I should do?

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 867	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Topic: How to properly enable a ribbon edit control Posted: 15 February 2011 at 6:27pm
	We have added a CXTPControlEdit to our ribbon. We set the control ID and in our OnCmdMsg handler we set the enable flag on the cmd UI object to TRUE. But we find our control is disabled. After debugging I found that the command bars object calls UpdateDialogControls. While walking the child windows the code finds the edit control created by the CXTPEditControl (the m_pEdit member that is the actual windows edit control). Then the routine calls GetDlgCtrlID and sets that in a cmd UI object and calls OnCmdMsg. Our OnCmdMsg simply sees the "m_pOther" object as a generic CWnd and of course the ID passed in is unknown to us (we disable any unknown IDs by default). Hence I have no real way to determine what I have and whether it should be enabled or not. So I am wondering what is the best way to handle controls/windows on the ribbon for update UI purposes. After creating the CXTPControlEdit object should we get the m_pEdit member and call SetDlgCtrlID to something we would recognize (probably the same value we set on the CXTPControlEdit object)? It looks like I can set the control ID to zero too. Or is there some other method I have overlooked that lets us talk to the generic CXTPControl class where I can set the dialog control ID of the underlying object? Something else I should do?

Oleg Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 21 May 2003 Location: United States Status: Offline Points: 11234	Post Options Post Reply Quote Oleg Report Post Thanks(0) Quote Reply Posted: 16 February 2011 at 1:58am
	Hello, Thanks a lot for such detailed description. I guess its about Visual Studio 2010 ? It has very strange feature (I'd call it even bug) - if we create window with Create method and parameter nID = 0, only Visual Studio 2010 assign some non zero ID instead of 0. // Weird VC2010 only code: { if ((cs.hMenu == NULL) && (cs.style & WS_CHILD)) { cs.hMenu = (HMENU)(UINT_PTR)this; } } I will check all such places in CommandBars and set Windows ID to zero after Create. Thanks for help.
	Oleg, Support Team CODEJOCK SOFTWARE SOLUTIONS

Oleg Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 21 May 2003 Location: United States Status: Offline Points: 11234	Post Options Post Reply Quote Oleg Report Post Thanks(0) Quote Reply Posted: 16 February 2011 at 2:09am
	Just to be sure it will work for you, please in BOOL CXTPCommandBarEditCtrl::CreateEdit(DWORD dwStyle, CWnd* pParentWnd) add line SetDlgCtrlID(0); and build toolkit. Its fixed problem ?
	Oleg, Support Team CODEJOCK SOFTWARE SOLUTIONS

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 867	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 16 February 2011 at 10:02am
	I'll give that a shot. I don't see why it would not work. I thought I could get the underlying edit control from the CXTPControlEdit after we create the latter. But I see the CEdit is created well after we create the CJ control. So a code change in CJ makes more sense. This is odd though. I have just stepped thru all the code where you create the "RichEdit20W" control. I get to CWnd::Create and there I see the nID passed in is used to init the hMenu of the create struct passed to PreCreateWindow. Sure enough Microsoft has changed the code in PrecreateWindow where they added this: if ((cs.hMenu == NULL) && (cs.style & WS_CHILD)) { cs.hMenu = (HMENU)(UINT_PTR)this; } This explains what I saw in OnCmdMsg. The ID looked like a pointer and now I see it is. I think I'll ping Microsoft on this and ask why they made the change. Also we happen to disable unknown IDs when they come thru our OnCmdMsg (we have a reason ...). So until we moved to VS 2010, we didn't have this problem. We also moved to a new CJ so we didn't know what the root cause of the disabled controls was. Friend said MS "broke CodeJock" on purpose!

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 867	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 16 February 2011 at 1:47pm
	Oleg, I made the following quick-and-dirty change as suggested. Works like a charm. Thanks for the quick reply. Will you have something in an update anytime soon? BOOL CXTPCommandBarEditCtrl::CreateEdit(DWORD dwStyle, CWnd* pParentWnd) { if (GetRichEditContext().m_hInstance) { BOOL bResult = CWnd::Create(GetRichEditContext().m_strClassName, 0, dwStyle, CRect(0, 0, 0, 0), pParentWnd, 0); SendMessage(EM_SETEVENTMASK, 0, ENM_CHANGE); SendMessage(EM_SETTEXTMODE, TM_PLAINTEXT \| TM_SINGLELEVELUNDO); if( bResult ) SetDlgCtrlID(0); return bResult; } BOOL bRet = Create(dwStyle, CRect(0, 0, 0, 0), pParentWnd, 0); if( bRet ) { SetDlgCtrlID(0); } return bRet; }

Oleg Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 21 May 2003 Location: United States Status: Offline Points: 11234	Post Options Post Reply Quote Oleg Report Post Thanks(0) Quote Reply Posted: 16 February 2011 at 2:16pm
	:) Actually just found some complains about this new "feature". http://connect.microsoft.com/VisualStudio/feedback/details/632178/cwnd-precreatewindow-change-causing-problems Don't see any reason why Microsoft added it
	Oleg, Support Team CODEJOCK SOFTWARE SOLUTIONS

Oleg Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 21 May 2003 Location: United States Status: Offline Points: 11234	Post Options Post Reply Quote Oleg Report Post Thanks(0) Quote Reply Posted: 16 February 2011 at 2:17pm
	Hi, Yes, we are preparing 15.0.2 with collection of small fixes.
	Oleg, Support Team CODEJOCK SOFTWARE SOLUTIONS

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 867	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 16 February 2011 at 3:30pm
	Thanks Oleg. I went to the MS connect article. The original complaint was "rejected" because MS could not duplicate it! I added my two cents worth. I also opened a support case with Microsoft since I rarely get any satisfaction with "connect".

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 867	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 15 March 2011 at 9:24am
	Oleg, Microsoft finally got back to me. This is an intended change we have to live with: Hi RD – I found that this was indeed a by-design change to improve managed native interop scenarios. I’m told there is a TRACE statement in CWnd::Create which attempts to alert you of the problem. Now, with this change, any dialog control must have an ID other than zero in order for GetDlgItem to work correctly. I hope that helps. I’m requesting the forum post be updated with more information.

Oleg Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 21 May 2003 Location: United States Status: Offline Points: 11234	Post Options Post Reply Quote Oleg Report Post Thanks(0) Quote Reply Posted: 16 March 2011 at 4:45am
	thanks for sharing, will hold in mind this feature.
	Oleg, Support Team CODEJOCK SOFTWARE SOLUTIONS