However after scrolling as the user does a mouse down, the menu moves and either no command starts or the wrong command starts. I experimented with this but found no real consistency. Waiting a long time before mousing down doesn't help. It is almost as if the system doesn't realize the menu has scrolled and is trying to pick some control it thinks is under the mouse instead of the control under the mouse (plus the "jump" on mouse down before the menu closes is disconcerting).

 

How do I fix this or turn it off until it is predictable and functional?

 

I uploaded an avi. You may need the camtasia codec extension for Windows Media player to work. This seems to depend on the exact layout of the menus.

Hi,

Thanks. Unfortunately I can't catch it with our sample - maybe you have something special like update captions in Update handler for this Popup or something. Please try reproduce with our sample and attach to debug.

 

One thing I noticed was different between the sample and our popup is the items on our popup have multiple lines of text on some of the items. I tried modifying the sample by adding elements to the main menu and then to one of the popups. On the popup items I lengthened the text. But two things happened. First the popup stretched way out (ours seems to be a fixed length and that may be the key). Second, since the popup kept streching on the sample I added some bigger strings so that the popup finally wrapped some of the text and one of my biggest strings took enough space that two lines of text wasn't enough. The thrid line was clipped off. Still it did not repro.

 

I am guessing that our layout will have to be duplicated exactly. But I don't know what all is involved on creating the system menu. Especially making the popup have a maximum/fixed width as I don't work on the code involved in laying out our UI.

 

I was hoping the avi file might give you some clues as to what may be happening. Is there any particular place I can set a breakpoint in the CJ source code so that after I scroll and do the mouse down I can step thru the code and see what causes the menu to move during the mouse event? That seems to be key. In my testing I don't always even see the menu move. It is almost as if the exact mouse point has an effect.

 

Alternatively if I can turn off the scroll feature to go back to what the previous versions did our product design group may be able to live with that. I'd rather give a shot at debugging in the CJ code first if you can direct me where to start.

Yes, I see it in avi.

Please set breakpoint in CXTPPopupBar::OnRecalcLayout maybe its called in some update event and it reset scrolling.

 

What I have found is that there is a disconnect between the control found in OnLButtonDown and OnLButtonUp. Since the control is on a popup, CXTPControlButton::OnClick does nothing. That call comes via CXTPCommandBar::OnLButtonDown.

 

In CXTPCommandBar::OnLbuttonDown, I always find the control returned from the first line (m_pControls->HitTest) is the control I am over when I click the mouse down. But as I noted, the OnClick routine does not start the command.

 

If I break in CXTPCommandBar::OnLButtonUp, I find that the control returned can be a different control from the one I click on. I see that when I mouse down, the popup redisplays and when I let the mouse up, the control under the mouse can be a different contro (due to the scroll)l.

 

I have been unable to determine when the display changes. I have a lot of problems with breakpoints as when one is tripped, the popup decides to go away. So I only get one breakpoint shot at a time trying to find the cause.

 

I have also found that we have a number of items on the popup that are not visible. These are not the itmes made non-visible because they have scrolled out of sight. Perhaps this is the difference between the sample and our app.

 

Since breaking at OnRecalclayout did not work, how about telling me where the "bottom scroll arrow" is displayed. I see that when I scroll down the arrow undisplays. Then when I mouse down over a control I see a scroll up occurs and the bottom scroll arrow is redisplayed. I need to set a break when the scroll up occurs or the bottom scroll arrow is displayed. Perhaps that will lead me to find the issue. The event sequence is 1) MouseDown 2) Popup scrolls 3) MouseUp.

 

By the way, I did find that if I mouse down and don't mouse up before the window scrolls again, if I hold the mouse down, move over the bottom scroll arrow and let the controls move and then move right back where I did the mouse down and then let the mouse up, the correct control is found.

 

That allowed me to get the scroll to the point where I do a mouse down on a control AFTER scrolling to the last control. This break point trips during idle processing. That is, the mouse is being held down and we send the WM_IDLEUPDATECMDUI message thru the system. The stack looks like this:

 

  ToolkitPro1341vc100UD.dll!CXTPPopupBar::AdjustScrolling(tagSIZE * lpSize, int bDown, int bInvalidate)  Line 766 C++
  ToolkitPro1341vc100UD.dll!CXTPPopupBar::CalculatePopupRect(CPoint ptPopup, CSize sz)  Line 669 C++
  ToolkitPro1341vc100UD.dll!CXTPPopupBar::OnRecalcLayout()  Line 322 + 0x52 bytes C++
  ToolkitPro1341vc100UD.dll!CXTPCommandBar::OnIdleUpdateCmdUI(unsigned int __formal, unsigned int __formal)  Line 608 + 0x12 bytes C++
  mfc100ud.dll!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult)  Line 2330 + 0x11 bytes C++

 

So I wonder if the update UI call is causing the scrolling as I have found the "btnUp" structure is given a rect (which triggers the paint manager to draw the arrow (I found that code after the last post).

 

We have an "IsIdleMessage" function. Perhaps I should add mouse down to the list of events that should NOT trigger idle processing? That sounds dangerous to me (the MFC version doesn't filter that message).

 

I have found one other bit of interesting info. If I use the keyboard to navigate to the popup, I have never been able to repro the issue. That is, when I mouse down, the popup never scrolls. I don't know what the connection, if any, is to idle processing. One thing for sure, my breakpoint based on the count is not tripped when I use the keyboard to get the popup to pop. Our IsIdleMessage function doesn't tag key events.

 

I am assuming the breakpoint I tripped duing the idle processing is an indication that the window has scrolled even if the display has yet to occur. Nor do I understand why the mouse down (plus idle processing while the mouse is held down) would cause the popup to think it should be scrolling.

 

Any ideals what to look for next?