Subject |
Author |
Date |
|
Robert Webb
|
Jul 14, 2008 - 8:38 PM
|
Hi, I just asked in the general forum about populating a ribbon bar group from a toolbar, but I’d also like to know how to pull an individual button out of a toolbar resource for use on a ribbon bar button. Any ideas? Any sample code? Thanks,
Rob.
|
|
Robert Webb
|
Aug 28, 2008 - 7:13 PM
|
Sorry, maybe I didn’t explain myself very well. Currently I have toolbars. I want to move to a ribbon bar. There are two issues: (1) To get something up and running quickly I’d like a way to automatically fill ribbon groups with buttons from existing toolbar resources, rather than manually writing the code to create all those buttons separately. The new MFC 9 feature pack provides this functionality (as does BCG and CodeJock). They allow the buttons to wrap at points where there were separators in the original toolbar too.
(2) Also, my button images are all in strips, as required for toolbars, and we may allow the user to choose between ribbon bar and menu/toolbar styles, so I’d like to keep them that way. Thus when adding buttons to a ribbon bar, I’d like to be able to pull their images out of these strips rather than splitting all those strips into separate bitmaps. Is there a convenient way to do this?
Thanks,
Rob.
|
|
Technical Support
|
Sep 1, 2008 - 11:14 AM
|
We could add some functions for loading ribbon pages from toolbars but we didn’t do that because in fact a ribbon button contains more properties than a toolbar button:
1) Two icons (big and small).
2) Advanced tooltip.
3) Behavior rules.
We could create a function which fills a ribbon page with buttons using toolbar and/or menu resources, but button properties would be initialized only partially. You would have to access particular buttons manually and provide them with required properties. This code would be very similar to ribbon initialization from scratch. You should be agree with us: a ribbon bar and toolbars/menus are quite different controls.
You can use your toolbars "as is". You can create a new command profile in the command manager (g_CmdManager->ProfileSetup( . . . ) ) and update it from all your existing toolbar and menu resources (g_CmdManager->UpdateFromMenu( . . . ) , g_CmdManager->UpdateFromToolBar( . . . ) ). As a result, you get a fully initialized command profile in the command manager which contains a set of command descriptions and a set of ready to use command icons. The g_CmdManager->CmdGetPtr( . . . ) code returns a pointer to the CExtCmdItem object with all the text properties gathered from the menu resources and string tables. The g_CmdManager->CmdGetIconPtr( . . . ) code returns the CExtCmdIcon object which has a command image in the CExtCmdIcon::m_bmpNormal property. This image can be used for initializing a ribbon node. So, the command manager can split all your resources into individual command descriptions and command icons. These resources can be used for initializing the properties of ribbon nodes.
|
|
Robert Webb
|
Sep 8, 2008 - 7:01 PM
|
Thanks, I have this working now, and am pulling the toolbar icons out of the command manager as you suggest. It seems the command manager can only store one icon size for each command though, so I still needed to get the large icons from elsewhere. I already had toolbar bitmaps at two different sizes. I managed to use standard Windows calls to load the larger bitmaps and extract individual icons for ribbon bar buttons. Rob.
|
|
Technical Support
|
Sep 9, 2008 - 12:07 PM
|
Yes, only one icon per command is supported. But this is not a big problem. For instance, if you need a File/Open command displaying a small 16x16 icon in menu and a big 32x32 icon in toolbar, then you should use two command identifiers: first in the menu and second in the toolbar. These commands should be handled/updated by the same methods in some of your classes.
|
|
Technical Support
|
Jul 15, 2008 - 1:34 PM
|
The CExtRibbonBar control is very extended version of the customizable toolbar control. I.e. ribbon bar is based on both CExtToolControlBar and CExtCustomizeSite classes. It’s possible to create ribbon elements inside customizable (and even non-customizable) toolbar, but most of ribbon buttons are performing event notifications via virtual methods of CExtRibbonBar and CExtRibbonPage classes. Besides toolbar control does not perform ribbon specific layout calculations of its buttons. We can assume your message as feature request. We suspect you need the CExtRibbonPage control demostrated in the RibbonPage sample application but it should behave like re-dockable toolbar.
|
|
Kevin Eshbach
|
Jul 14, 2008 - 4:00 PM
|
Can you tell me what function I need to use programatically to get the menu bar to automatically hide itself when docked or floating? Also, after hiding the menu bar I need to not have itself magically appear when I switch to another application and come back to it. How do I turn off this behavior? Kevin Eshbach
|
|
Technical Support
|
Jul 15, 2008 - 11:17 AM
|
The CExtMenuControlBar::TranslateMainFrameMessage() method shows menu bar automatically when the VK_MENU key is pressed (ALT key). You can modify the CMainFrame::PreTranslateMessage() method in your project and not invoke menu bar’s CExtMenuControlBar::TranslateMainFrameMessage() method for WM_KEY*** messages when the main frame window is not active. You also can handle the WM_ACTIVATE message in your main frame class and show or hide menu bar depending on the acitve state of the main frame window. Please note, if your main frame class is based on the CExtNCW template class, then the WM_ACTIVATE message should be handled in the WindowProc virtual method.
|
|
Jeremy Richards
|
Jul 14, 2008 - 2:50 PM
|
I am in a situation where I need to hide the child window of a CExtControlBar at times. Normally this isn’t a problem, just call ShowWindow(SW_HIDE) on the child and it is hidden. However, if control bar is an auto hide control bar then this doesn’t work -- I can neither hide nor disable the child (or perhaps when I pop open the control bar the child is reshown and reenabled automatically). Is there anything that can be done about this?
|
|
Technical Support
|
Jul 15, 2008 - 10:53 AM
|
First of all, you should hide CExtControlBar window using the following code:
CExtControlBar * pBar = . . .
CFrameWnd * pMainFrame = . . .
if( pBar->AutoHideModeGet() )
pBar->AutoHideModeSet( false, false, true, true );
else
pMainFrame->ShowControlBar( FALSE, FALSE );
If the CExtControlBar::m_bAppearInDockSiteControlBarPopupMenu property is set to false then control bar’s command will not appear in all built-in menus displayed by Prof-UIS over frame window areas:
pBar->m_bAppearInDockSiteControlBarPopupMenu = false;
|
|
Jeremy Richards
|
Jul 15, 2008 - 11:43 AM
|
I think you may have misunderstood my problem. My issue is not with hiding CExtControlBars themselves (they are behaving fine), the problem is when I want to hide the CHILD of the CExtControlBar. In certain circumstances, I want to hide the child window (a CDialog in this case), while leaving the CExtControlBar itself visible (actually my CExtControlBar derrived class has an OnPaint handler, which draws a default background when the child is hidden). Now for docked, floating or tabbed control bars the behavior is fine. However, with autohidden ones, the child is being reshown. (i.e. someone is calling child->ShowWindow(SW_SHOW) or similar and it is not me.
|
|
Technical Support
|
Jul 15, 2008 - 1:25 PM
|
We suppose you have CExtControlBar window and some child window inside it which should be hidden sometimes. Let us suppose this child window is CTreeCtrl window. You should create some CWnd -based container window as child of CExtControlBar window and create CTreeCtrl window as child of container window. The container window should do the following: - Move its child window to fit entire container’s client area.
- Paint it’s cient area with some background and text message over it like There is no data to show in this view.
- Set focus to visible child window if focus set to container window.
So, the container window should handle WM_SIZE , WM_PAINT and WM_SETFOCUS messages. As result, if the CTreeCtrl window is visible, then user works with it. If the CTreeCtrl window is hidden, then user see empty window with helper message. This UI layout is exactly the same as Document Outline resizable control bar window in Visual Studio .NET / 2005 / 2008. Please note, such container window may also need to route invocations of OnCmdMsg() and PreTranslateMessage() virtual methods into the same virtual methods of its child CTreeCtrl window.
|
|
Jeremy Richards
|
Jul 15, 2008 - 2:21 PM
|
Thank you. I finally figured this out. I was hoping to not have to go that route, but I just got it implemented. It wasn’t obvious though -- it took digging through the auto hide code and realizing that the child window was actually getting its parent reassigned to realize that my initial approach wasn’t going to work. I have the later approach working now and it does what I need though.
|
|
Michele Cillo
|
Jul 11, 2008 - 11:09 AM
|
Hi support,
I found the problem in subject. My configuration is: Visual Studio 2003
MDI Application with CExtTabMdiOneNoteWnd tab page manager
ProfUIS 2.84 prerelease (with CExtResizableDialog focus fix)
When I switch to one of the Office 2007 Styles and open a new Child Window the print preview toolbar isn’t here. If I activate another child window and after return on the former, magically the toolbar reappears.
P.S. I oveloaded CExtPPVW_Printable::OnInitializePrintPreviewToolBar();for adding more buttons to toolbar, calling parent version of course: void CSuiteReportPrintViewSimple::OnInitializePrintPreviewToolBar()
{
CExtPPVW_Printable::OnInitializePrintPreviewToolBar();
...
}
All other styles work fine.
|
|
Michele Cillo
|
Jul 14, 2008 - 4:57 AM
|
Hi, after your answer I investigated more carefully this bug, and I found that MDIChildWnd style assignment in its PreCreateWindow generated it. For clarity my styles were BOOL CSuiteChildFrame::PreCreateWindow(CREATESTRUCT& cs)
{
cs.style = WS_CHILD | WS_VISIBLE | WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU
| FWS_ADDTOTITLE | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_MAXIMIZE;
return _CSuiteChildFrameBase::PreCreateWindow(cs);
} where typedef CExtNCW < CMDIChildWnd > _CSuiteChildFrameBase;
class SUITEDLGLIB_EXPORT CSuiteChildFrame : public _CSuiteChildFrameBase
{
...
}; If I change code in BOOL CSuiteChildFrame::PreCreateWindow(CREATESTRUCT& cs)
{
// cs.style = WS_CHILD | WS_VISIBLE | WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU
// | FWS_ADDTOTITLE | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_MAXIMIZE;
return _CSuiteChildFrameBase::PreCreateWindow(cs);
} all works fine. Sorry for the inconvenience and thanks for the great support. Good work
|
|
Technical Support
|
Jul 12, 2008 - 9:16 AM
|
There is not enough information in your message for reproducing the problem. We tried to run DrawCli sample application, invoke print-preview mode and switch different paint managers. We didn’t detected any problems with toolbar. Is it possible to reproduce toolbar problem in the DrawCli sample application if you put your code snippets into it?
|
|
Malcolm D
|
Jul 11, 2008 - 12:29 AM
|
Hi, I’m trying to fit a ribbon bar into an existing project. There are already various toolbars, some of which will remain. Currently, when I create a ribbon bar, following the sample code, other toolbars seem to be docked first. In the sample, it is not possible to dock the Theme Switcher toolbar above the ribbon bar, nor vertically along side the ribbon bar (only below it). I can’t see any code in the demo that enforces this, but in my own project toolbars happily dock above it and along side it vertically. The window’s title bar, which can be used to drag the window around, ends up part-way down the window with toolbars above it. Very odd. Any thoughts about all this? I’m also getting a lot of failed ASSERTions at the moment, eg in CExtToolControlBar::OnCustomizeRegisterBar() because it’s getting called twice somehow. I’ll look at it some more, but just thought I’d mention it in case you had any thoughts. Thanks, Rob.
|
|
Robert Webb
|
Jul 14, 2008 - 2:15 AM
|
Actually I thought I was creating it first, but turned out there was another base class below CMainFrame which was creating other stuff first. Your suggestion pointed me in the right direction. Thanks,
Rob.
|
|
Technical Support
|
Jul 12, 2008 - 9:37 AM
|
Please note: position of any non-re-dockable control bar depends on its Z-order. If you create two non-re-dockable bars near the same side of the frame window, then first will be closer to outer frame border and second will be closer to center. The ribbon bar control should be created before any other control bars. This will allow ribbon to occupy part of the parent frame window which is closest to caption. We guess this is the main problem in your project. It would be also helpful to take a look at main frame’s source code to find any additional issues and provide you with more comments.
|
|
tera t
|
Jul 10, 2008 - 7:45 PM
|
Hello. Depending on a theme,
I cannot understand an input place.
With a red frame line, cannot you display it?
|
|
tera t
|
Aug 19, 2008 - 2:42 AM
|
|
|
Technical Support
|
Aug 20, 2008 - 11:29 AM
|
If you need an edit control with a thin solid border, you can achieve that with the CExtFlatEdit class from the Prof-UIS_Controls sample.
|
|
Wang Hui Qing
|
Jul 10, 2008 - 2:00 AM
|
Hi Tech Support, I’m new user to your product and now trying to build a demo to get self familiar with your product. I get CChildView class inherited from CextGridWnd in a MDI Doc/View like: class CSampleWorkspace01View : public CExtPPVW <CExtTreeGridWnd> And I try to follow the sample code of SimpleGrids and find the print & print preview button/menu item are always greyed. As I can see from SimpleGrids code there is actually nothing specially to be done to get print/print preview work except inherit from CExtPPVW temple class. Anything else I’m missing? Btw: I also find the document not so detailed, to just give example: CExtPPVW and OnGetPrintableDocTitle() are used in the sample code, but there is nowhere in documents you can find any reference..
|
|
Wang Hui Qing
|
Jul 11, 2008 - 1:08 AM
|
Dear Tech Support, I follow your advice, however, print/print review still not work (icon/menu greyed). Following is the code snippet of CChildFrame and CView class, please take a look and help if anything wrong, thanks class CChildFrame : public CExtNCW < CMDIChildWnd >
{ ... } BOOL CChildFrame::OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo)
{
CMainFrame *pFrame =
(CMainFrame*)AfxGetApp()->m_pMainWnd;
// Get the active MDI child window.
CChildFrame *pChild =
(CChildFrame *) pFrame->GetActiveFrame();
// or CMDIChildWnd *pChild = pFrame->MDIGetActive();
// Get the active view attached to the active MDI child
// window.
CSART_SampleWorkspace01View *pView = (CSART_SampleWorkspace01View *) pChild->GetActiveView();
if( pView != NULL )
{
if( pView->OnCmdMsg(nID, nCode, pExtra, pHandlerInfo) )
return TRUE;
}
return CExtNCW < CMDIChildWnd >:: OnCmdMsg( nID, nCode, pExtra, pHandlerInfo );
} class CSART_SampleWorkspace01View : public CExtPPVW <CExtTreeGridWnd>
{
... } BOOL CSART_SampleWorkspace01View::OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo)
{
return CExtPPVW < CExtTreeGridWnd > :: OnCmdMsg( nID,nCode,pExtra,pHandlerInfo );
}
|
|
Technical Support
|
Jul 12, 2008 - 9:26 AM
|
The CChildFrame::OnCmdMsg() method contains a lot of code but does nothing because the main frame’s OnCmdMsg() method automatically invokes OnCmdMsg() method of active MDI child frame. The last method invokes OnCmdMsg() method of view window inside MDI child frame. So, the CChildFrame::OnCmdMsg() method can be simply removed. Please compare all the OnCmdMsg() and PreTranslateMessage() virtual methods in your project with the same methods in the DrawCli sample application where printing/previewing works OK.
|
|
Wang Hui Qing
|
Jul 13, 2008 - 7:29 PM
|
Dear Tech Support, I check DrawCli and follow those codes in OnCmdMsg() and PreTranslateMessage(), but still yet to get printing/previewing works... The difference between my program and DrawCli lies in that the CView class in mine inherit from CExtTreeGridWnd. In my program seems ID_FILE_PRINT/ID_FILE_PRINT_PREVIEW cannot be automatically captured and handled by CExtPPVW. Change to another way, can you tell me which methods in CExtPPVW can I call explicitly to handle print/preview msg? Thanks.
|
|
Technical Support
|
Jul 14, 2008 - 8:21 AM
|
The CExtPPVW < CExtTreeGridWnd > :: OnCmdMsg() method handles and updates all the ID_FILE_PRINT_***** commands. If the OnCmdMsg() virtual method of your tree grid view is invoked and there are no problems with command routing in your project, then all the printing commands should be invoked correctly.
Please note: some changes in C++ source code require complete rebuilding of your Visual C++ project. For instance, if you have compiled your project at least once and then changed default parameter value in some parameter of some function or method, then you need complete rebuild to make code generator using new default parameter value. This is well known issue which is related to any Visual C++ version including good old Visual C++ 6.0. There are several similar issues related to changing base class type and especially template based class types.
|
|
Wang Hui Qing
|
Jul 14, 2008 - 7:41 PM
|
still no luck... I’ve sent you the source code of my project, please kindly take a look at it. Thanks.
|
|
Technical Support
|
Jul 18, 2008 - 1:14 PM
|
We have answered your e-mail and described you detailed step-by-step instructions of how to fix all the issues in your project. We are sorry for the delay. We are very overloaded with e-mail support.
|
|
Technical Support
|
Jul 10, 2008 - 12:49 PM
|
The CExtPPVW template class implements the OnCmdMsg() virtual method which handles and updates the standard ID_FILE_PRINT_***** commands. That is why they work automatically in most cases. The only thing you may need is to invoke the OnCmdMsg() method of your tree grid window from the OnCmdMsg() method of some other window in your application. I.e. you should implement command routing for your tree grid window in your project. If your tree grid window is the main view window in SDI project, then the main frame window should do command routing to your tree grid window. If your tree grid window is the view window inside MDI child frame window in MDI project, then the MDI child frame window should do command routing to your tree grid window. If your tree grid window has any other special location in any type of project (if it’s child of control bar, child of some dialog etc.) then you also should implement appropriate command routing invocations.
The CExtPPVW template class was designed for providing printing/previewing APIs similar to same APIs MFC view windows (CView and derived from it). The documentation for the CExtPPVW template class is unfortunately incomplete because we are still not finished development of printing/previewing subsystem.
|
|
Wang Hui Qing
|
Jul 16, 2008 - 7:28 PM
|
Dear Tech Support, It’s been two days since I sent you the email for the above issue, no response? Really appreciate you can take a look at it. Thanks.
|
|
Technical Support
|
Jul 18, 2008 - 1:14 PM
|
We have answered your e-mail and described you detailed step-by-step instructions of how to fix all the issues in your project. We are sorry for the delay. We are very overloaded with e-mail support.
|
|
howard liu
|
Jul 10, 2008 - 1:18 AM
|
Hi, I have a frame window appearing through the click of one of the menu items in my application. This frame window has several controls and a close/cancel button. When i click this close/cancel button the frame window as well as the application gets closed. Ideally this should only close the frame window and not the application. This is happening after the prof-ui implementation over the frame window. Is there a procedure from prof-ui to destroy / close only the frame window Thanks, Howard
|
|
Technical Support
|
Jul 10, 2008 - 1:46 PM
|
The skinned desktop windows are working exactly in the same way as default looking desktop windows. Click on the "X" button in window caption causes sending of the WM_SYSCOMMAND message with SC_CLOSE value in WPARAM . The default window procedure handles this message and sends WM_CLOSE message which notifies window that it should destroy itself. If you want only hide your window without destroying it, then you should handle the WM_CLOSE message and make window hiding itself without delivering WM_CLOSE message to parent class method/default window procedure.
The main thread/application class in MFC runs message loop until the main window exist. When the main window is destroyed, the application stop running thread message loop and exits. It’s not cleanly described in your message which window in your application is main. We need more details.
|
|
Kevin Eshbach
|
Jul 9, 2008 - 12:35 PM
|
Is there a public method I can call in CExtPopupMenuWnd to have CExtPopupMenuWnd::MENUITEMDATA::SetNoCmdUI set with a value of false for all items in a menu. I have a context menu with popup menus that I need to use MFC’s builtin Command UI handler mechanism for enabling/disabling menu items. I can derive a class from CExtPopupMenuWnd to get access to the m_items_all member variable of the top level menu, but then I have no way of updating any child menus because they aren’t using my derived class.
Kevin Eshbach
|
|
Technical Support
|
Jul 9, 2008 - 2:03 PM
|
The CExtPopupMenuWnd menus are using MFC command updating mechanism by default. But if you set the bNoRefToCmdMngr parameter to false in invocation of the CExtPopupMenuWnd::LoadMenu() or CExtPopupMenuWnd::UpdateFromMenu() methods or insert menu items via the CExtPopupMenuWnd::ItemInsertCommand() method then initialized menu command items will not be based on the command manager and will not use MFC’s command updating mechanism. You can also access data of each menu item like you described in your message for modifying its settings and behavior. So, please check how you initialize your popup menus.
|
|
Christophe SAPHAR
|
Jul 9, 2008 - 10:18 AM
|
I have a CExtNCW<CMDIChildWnd> window containing several docked CExtControlBar. When CMDIChildWnd is resized, CExtControlBar are not resized but moved, sticked to docking side of their mother window. I tried to resize them in order to automatically adapt their size to the main window’s by various ways without success.
Can someone help me ?
|
|
Technical Support
|
Jul 9, 2008 - 1:34 PM
|
There is not enough information in your message to find out what may be wrong. Could you at least show us some screen shots demonstrating the problem and the source code of your MDI child frame class?
|
|
David Skok
|
Jul 8, 2008 - 2:33 PM
|
Scroll bar controls (up,down,thumb) do not work in ScrollItemWnd children (eg. any grid control) when the left/right mouse buttons are swapped in windows control panel. That is, the mouse can no longer be used to drag the thumb control or clicked on the up/down in the scroll bars. Keyboard still works of course.
|
|
Technical Support
|
Jul 9, 2008 - 12:42 PM
|
Thank you for reporting this issue. It is fixed. Please update the source code for the following method: void CExtScrollBar::ScrollBar_TrackMouseLButtonDown(
MSG * pMSG
)
{
ASSERT_VALID( this );
if( ! m_bCompleteRepaint )
return;
CPoint point( short(LOWORD(DWORD(pMSG->lParam))), short(HIWORD(DWORD(pMSG->lParam))) );
CExtPopupMenuTipWnd * pATTW =
OnAdvancedPopupMenuTipWndGet();
CExtPaintManager::PAINTSCROLLBARDATA _psbd( this );
_psbd.AdjustHT( point );
if( (! m_bProcessingHover)
|| m_bProcessingClick
|| (! _psbd.m_bEnabled )
|| _psbd.m_eSBMHT == CExtPaintManager::__ESBMHT_NOWHERE
)
{
if( _psbd.m_eSBMHT == CExtPaintManager::__ESBMHT_NOWHERE
|| (! _psbd.m_bEnabled )
)
{
if( pATTW != NULL )
pATTW->Hide();
SendMessage( WM_CANCELMODE );
Invalidate();
UpdateWindow();
return;
}
}
if( ! m_bPopupInactiveLightMode )
ActivateTopParent();
bool bAnimationLocked = AnimationClient_CacheGeneratorIsLocked();
if( ! bAnimationLocked )
{
AnimationClient_CacheGeneratorLock();
AnimationClient_CacheNextStateMinInfo( false, __EAPT_BY_PRESSED_STATE_TURNED_ON );
}
if( m_bEnableHookSpy )
HookSpyUnregister();
m_nSBMHT = INT(_psbd.m_eSBMHT);
m_bProcessingClick = m_bProcessingHover = true;
m_bProcessingOutClick = false;
if( ! bAnimationLocked )
{
AnimationClient_CacheNextStateMinInfo( true, __EAPT_BY_PRESSED_STATE_TURNED_ON );
AnimationClient_CacheGeneratorUnlock();
}
Invalidate();
UpdateWindow();
if( pATTW != NULL )
OnAdvancedPopupMenuTipWndDisplay( *pATTW, m_nSBMHT, true );
INT nScrollPosStart = _psbd.m_DSI.nPos, nScrollPos = _psbd.m_DSI.nPos;
m_nHelperTrackPos = _psbd.m_DSI.nPos;
m_bHelperHaveTrackPos = true;
CRect rcArea = _psbd.GetAreaRectHT();
const UINT nTimerID_zero_start = 401;
const UINT nTimerID_1st_slow = 402;
const UINT nTimerEllapse_1st_slow = 400;
const UINT nTimerID_2nd_fast = 403;
const UINT nTimerEllapse_2nd_fast = 100;
HWND hWndOwn = GetSafeHwnd();
ASSERT( hWndOwn != NULL && ::IsWindow( hWndOwn ) );
HWND hWndParent = ::GetParent( hWndOwn );
bool bVirtualMode = false, bFinalNotify = true;
#if (!defined __EXT_MFC_NO_SCROLLWND)
CExtScrollWnd * pExtScrollWnd = NULL;
if( hWndParent != NULL )
{
CWnd * pWndParentPermanent = CWnd::FromHandlePermanent( hWndParent );
if( pWndParentPermanent != NULL )
{
pExtScrollWnd = DYNAMIC_DOWNCAST( CExtScrollWnd, pWndParentPermanent );
#if (!defined __EXT_MFC_NO_SCROLLITEMWND)
if( pExtScrollWnd != NULL )
{
CExtScrollItemWnd * pExtScrollItemWnd = DYNAMIC_DOWNCAST( CExtScrollItemWnd, pWndParentPermanent );
if( pExtScrollItemWnd != NULL )
{
DWORD dwScrollType = __ESIW_ST_NONE;
if( _psbd.m_bHorzBar )
dwScrollType = pExtScrollItemWnd->SiwScrollTypeHGet();
else
dwScrollType = pExtScrollItemWnd->SiwScrollTypeVGet();
if( dwScrollType == __ESIW_ST_VIRTUAL )
bVirtualMode = true;
}
}
#endif
}
}
#endif
bool bStopFlag = false;
CPoint ptCursor( point );
INT nStepSize = 0L;
bool bUpStep = false;
bool bMouseButtonsNotSwapped = ( ::GetSystemMetrics( SM_SWAPBUTTON ) != 0 ) ? false : true;
switch( _psbd.m_eSBMHT )
{
case CExtPaintManager::__ESBMHT_BUTTON_UP:
bUpStep = true;
// continue falling here ...
case CExtPaintManager::__ESBMHT_BUTTON_DOWN:
nStepSize = GetStepSize();
#if (!defined __EXT_MFC_NO_SCROLLWND)
if( pExtScrollWnd != NULL )
{
int nDir = ( _psbd.m_eSBMHT == CExtPaintManager::__ESBMHT_BUTTON_DOWN ) ? (-1) : 1;
CSize _size = pExtScrollWnd->OnSwGetLineSize( nDir );
nStepSize = _psbd.m_bHorzBar ? _size.cx : _size.cy;
if( nStepSize <= 0L )
nStepSize = GetStepSize();
}
#endif
break;
case CExtPaintManager::__ESBMHT_PAGE_UP:
bUpStep = true;
// continue falling here ...
case CExtPaintManager::__ESBMHT_PAGE_DOWN:
nStepSize = (INT)_psbd.m_DSI.nPage;
#if (!defined __EXT_MFC_NO_SCROLLWND)
if( pExtScrollWnd != NULL )
{
int nDir = ( _psbd.m_eSBMHT == CExtPaintManager::__ESBMHT_PAGE_DOWN ) ? (-1) : 1;
CSize _size = pExtScrollWnd->OnSwGetPageSize( nDir );
nStepSize = _psbd.m_bHorzBar ? _size.cx : _size.cy;
}
#endif
if( nStepSize <= 0L )
nStepSize = GetStepSize();
break;
case CExtPaintManager::__ESBMHT_THUMB:
break;
}
bool bMenuMode = false;
if( CExtPopupMenuWnd::IsMenuTracking() )
{
CWnd * pWnd = GetParent();
for( ; pWnd != NULL; pWnd = pWnd->GetParent() )
{
if( pWnd->IsKindOf( RUNTIME_CLASS(CExtPopupMenuWnd) ) )
{
bMenuMode = true;
break;
}
if( (pWnd->GetStyle()&WS_CHILD) == 0 )
break;
}
}
INT nMx = INT( _psbd.m_DSI.nMax - _psbd.m_DSI.nPage + 1 );
INT nScrollLimit = _psbd.m_DSI.nMax - _psbd.m_DSI.nMin - _psbd.m_DSI.nPage + 1;
ASSERT( nScrollLimit >= 0 );
if( nStepSize > nScrollLimit )
nStepSize = nScrollLimit;
CRect rcScrollable = _psbd.m_rcBar;
if( _psbd.m_bHorzBar )
{
rcScrollable.left = _psbd.m_rcButtonUp.right;
rcScrollable.right = _psbd.m_rcButtonDown.left;
}
else
{
rcScrollable.top = _psbd.m_rcButtonUp.bottom;
rcScrollable.bottom = _psbd.m_rcButtonDown.top;
}
ScrollBar_CaptureSet();
if( nStepSize != 0L )
::PostMessage( hWndOwn, WM_TIMER, WPARAM(nTimerID_zero_start), LPARAM(0L) );
for( MSG msg; ::IsWindow( hWndOwn ) && (!bStopFlag); )
{
if( ! PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE) )
{
if( ! ::IsWindow( hWndOwn ) )
break;
::WaitMessage();
continue;
}
bool bAnalyzeThumb = false;
switch( msg.message )
{
case WM_LBUTTONDBLCLK:
case WM_LBUTTONUP:
case WM_RBUTTONDBLCLK:
case WM_RBUTTONDOWN:
case WM_RBUTTONUP:
case WM_MBUTTONDBLCLK:
case WM_MBUTTONDOWN:
case WM_MBUTTONUP:
case WM_CANCELMODE:
case WM_ACTIVATEAPP:
case WM_KEYDOWN:
case WM_KEYUP:
bStopFlag = true;
break;
case WM_CAPTURECHANGED:
if( (HWND)msg.wParam != hWndOwn )
bStopFlag = true;
break;
case WM_MOUSEMOVE:
if( m_nSBMHT == INT(CExtPaintManager::__ESBMHT_THUMB) )
{
if( ( ! CExtPopupMenuWnd::IsKeyPressed( bMouseButtonsNotSwapped ? VK_LBUTTON : VK_RBUTTON,true) )
|| CExtPopupMenuWnd::IsKeyPressed( VK_MBUTTON )
|| CExtPopupMenuWnd::IsKeyPressed( bMouseButtonsNotSwapped ? VK_RBUTTON : VK_LBUTTON,true )
|| ( (!bMenuMode) && CExtPopupMenuWnd::IsMenuTracking() )
)
{
bStopFlag = true;
break;
}
PeekMessage(&msg,NULL,msg.message,msg.message,PM_REMOVE);
bAnalyzeThumb = true;
::GetCursorPos( &ptCursor );
::ScreenToClient( hWndOwn, &ptCursor );
break;
}
if( nStepSize == 0 )
break;
case WM_TIMER:
{
if( ( ! CExtPopupMenuWnd::IsKeyPressed( bMouseButtonsNotSwapped ? VK_LBUTTON : VK_RBUTTON,true) )
|| CExtPopupMenuWnd::IsKeyPressed( VK_MBUTTON )
|| CExtPopupMenuWnd::IsKeyPressed( bMouseButtonsNotSwapped ? VK_RBUTTON : VK_LBUTTON,true )
|| ( (!bMenuMode) && CExtPopupMenuWnd::IsMenuTracking() )
)
{
bStopFlag = true;
break;
}
if( msg.hwnd != hWndOwn )
break;
if( msg.wParam != nTimerID_zero_start
&& msg.wParam != nTimerID_1st_slow
&& msg.wParam != nTimerID_2nd_fast
)
break;
if( msg.wParam == nTimerID_zero_start )
::SetTimer( hWndOwn, nTimerID_1st_slow, nTimerEllapse_1st_slow, NULL );
else if( msg.wParam == nTimerID_1st_slow )
{
::KillTimer( hWndOwn, nTimerID_1st_slow );
::SetTimer( hWndOwn, nTimerID_2nd_fast, nTimerEllapse_2nd_fast, NULL );
}
ASSERT( nStepSize != 0L );
PeekMessage(&msg,NULL,msg.message,msg.message,PM_REMOVE);
::GetCursorPos( &ptCursor );
::ScreenToClient( hWndOwn, &ptCursor );
bool bPause = false;
if( ! rcArea.PtInRect( ptCursor ) )
bPause = true;
else
{
if( m_nSBMHT == INT(CExtPaintManager::__ESBMHT_PAGE_UP)
|| m_nSBMHT == INT(CExtPaintManager::__ESBMHT_PAGE_DOWN)
)
{
CExtPaintManager::PAINTSCROLLBARDATA _psbd2( this );
_psbd2.AdjustHT( ptCursor );
INT nSBMHT2 = INT( _psbd.m_eSBMHT );
if( nSBMHT2 != m_nSBMHT )
bPause = true;
else
{
CRect rcArea2 = _psbd2.GetAreaRectHT();
if( ! rcArea2.PtInRect( ptCursor ) )
bPause = true;
else
{
if( _psbd2.m_bHorzBar )
{
if( m_nSBMHT == INT(CExtPaintManager::__ESBMHT_PAGE_UP) )
{
if( ptCursor.x >= _psbd2.m_rcThumb.left )
bPause = true;
}
else if( m_nSBMHT == INT(CExtPaintManager::__ESBMHT_PAGE_DOWN) )
{
if( ptCursor.x <= _psbd2.m_rcThumb.right )
bPause = true;
}
}
else
{
if( m_nSBMHT == INT(CExtPaintManager::__ESBMHT_PAGE_UP) )
{
if( ptCursor.y >= _psbd2.m_rcThumb.top )
bPause = true;
}
else if( m_nSBMHT == INT(CExtPaintManager::__ESBMHT_PAGE_DOWN) )
{
if( ptCursor.y <= _psbd2.m_rcThumb.bottom )
bPause = true;
}
}
}
}
}
}
if( bPause )
{
if( ! m_bProcessingOutClick )
{
m_bProcessingOutClick = true;
Invalidate();
}
if( pATTW != NULL )
pATTW->Hide();
continue;
}
if( bUpStep )
{
nScrollPos -= nStepSize;
if( nScrollPos < _psbd.m_DSI.nMin )
nScrollPos = _psbd.m_DSI.nMin;
}
else
{
nScrollPos += nStepSize;
if( nScrollPos > nMx )
nScrollPos = nMx;
}
if( _GetScrollPos( true ) != nScrollPos )
{
bool bSendScrollingNotification = true, bTrackPos = true;
if( hWndParent != NULL )
{
switch( m_nSBMHT )
{
case (CExtPaintManager::__ESBMHT_BUTTON_UP):
if( m_bSendActionNotifications )
::SendMessage( hWndParent, _psbd.m_bHorzBar ? WM_HSCROLL : WM_VSCROLL, MAKEWPARAM( ( _psbd.m_bHorzBar ? SB_LINELEFT : SB_LINEUP ), 0 ), LPARAM(m_hWnd) );
if( ! bVirtualMode )
_SetScrollPos( nScrollPos, bTrackPos, true, bSendScrollingNotification );
else
bFinalNotify = (!m_bSendActionNotifications);
break;
case (CExtPaintManager::__ESBMHT_BUTTON_DOWN):
if( m_bSendActionNotifications )
::SendMessage( hWndParent, _psbd.m_bHorzBar ? WM_HSCROLL : WM_VSCROLL, MAKEWPARAM( ( _psbd.m_bHorzBar ? SB_LINERIGHT : SB_LINEDOWN ), 0 ), LPARAM(m_hWnd) );
if( ! bVirtualMode )
_SetScrollPos( nScrollPos, bTrackPos, true, bSendScrollingNotification );
else
bFinalNotify = (!m_bSendActionNotifications);
break;
case (CExtPaintManager::__ESBMHT_PAGE_UP):
if( m_bSendActionNotifications )
::SendMessage( hWndParent, _psbd.m_bHorzBar ? WM_HSCROLL : WM_VSCROLL, MAKEWPARAM( ( _psbd.m_bHorzBar ? SB_PAGELEFT : SB_PAGEUP ), 0 ), LPARAM(m_hWnd) );
if( ! bVirtualMode )
_SetScrollPos( nScrollPos, bTrackPos, true, bSendScrollingNotification );
else
bFinalNotify = (!m_bSendActionNotifications);
break;
case (CExtPaintManager::__ESBMHT_PAGE_DOWN):
if( m_bSendActionNotifications )
::SendMessage( hWndParent, _psbd.m_bHorzBar ? WM_HSCROLL : WM_VSCROLL, MAKEWPARAM( ( _psbd.m_bHorzBar ? SB_PAGERIGHT : SB_PAGEDOWN ), 0 ), LPARAM(m_hWnd) );
if( ! bVirtualMode )
_SetScrollPos( nScrollPos, bTrackPos, true, bSendScrollingNotification );
else
bFinalNotify = (!m_bSendActionNotifications);
break;
case (CExtPaintManager::__ESBMHT_THUMB):
bTrackPos = true;
if( ! bVirtualMode )
_SetScrollPos( nScrollPos, bTrackPos, true, bSendScrollingNotification );
else
bFinalNotify = false;
break;
}
}
if( pATTW != NULL && ( ! bAnalyzeThumb ) )
OnAdvancedPopupMenuTipWndDisplay( *pATTW, m_nSBMHT, true );
}
_psbd.AdjustHT( ptCursor );
bool bProcessingOutClick =
( m_nSBMHT == INT(_psbd.m_eSBMHT) )
? false : true;
rcArea = _psbd.GetAreaRect( CExtPaintManager::e_scroll_bar_mouse_hover_type_t(m_nSBMHT) );
if( m_bProcessingOutClick != bProcessingOutClick )
{
bool bAnimationLocked = AnimationClient_CacheGeneratorIsLocked();
if( ! bAnimationLocked )
{
AnimationClient_CacheGeneratorLock();
AnimationClient_CacheNextStateMinInfo( false, __EAPT_BY_PRESSED_STATE_TURNED_OFF );
}
m_bProcessingOutClick = bProcessingOutClick;
if( ! bAnimationLocked )
{
AnimationClient_CacheNextStateMinInfo( true, __EAPT_BY_PRESSED_STATE_TURNED_OFF );
AnimationClient_CacheGeneratorUnlock();
}
Invalidate();
UpdateWindow();
}
}
break;
default:
{
if( ( ! CExtPopupMenuWnd::IsKeyPressed( bMouseButtonsNotSwapped ? VK_LBUTTON : VK_RBUTTON,true) )
|| CExtPopupMenuWnd::IsKeyPressed( VK_MBUTTON )
|| CExtPopupMenuWnd::IsKeyPressed( bMouseButtonsNotSwapped ? VK_RBUTTON : VK_LBUTTON,true )
|| ( (!bMenuMode) && CExtPopupMenuWnd::IsMenuTracking() )
)
bStopFlag = true;
}
break;
}
if( bStopFlag || nScrollLimit == 0L )
break;
if( bAnalyzeThumb )
{
LONG nPixelOffset = _psbd.m_bHorzBar
? (ptCursor.x - point.x)
: (ptCursor.y - point.y);
LONG nPixelExtent = _psbd.m_bHorzBar
? (rcScrollable.Width() - _psbd.m_rcThumb.Width())
: (rcScrollable.Height() - _psbd.m_rcThumb.Height());
if( nPixelExtent <= 0 )
{
bStopFlag = true;
break;
}
if( abs(nPixelOffset) > nPixelExtent )
nPixelOffset = (nPixelOffset < 0) ? (-nPixelExtent) : nPixelExtent;
INT nShift = ( nPixelExtent == 0 || nPixelOffset == 0 ) ? 0 : ::MulDiv( nScrollLimit, abs(nPixelOffset), nPixelExtent );
nScrollPos = nScrollPosStart;
if( nPixelOffset < 0 )
{
nScrollPos -= nShift;
if( nScrollPos < _psbd.m_DSI.nMin )
nScrollPos = _psbd.m_DSI.nMin;
}
else
{
nScrollPos += nShift;
if( nScrollPos > nMx )
nScrollPos = nMx;
}
if( ! bVirtualMode )
{
if( _GetScrollPos( true ) != nScrollPos )
{
_SetScrollPos( nScrollPos, true );
if( pATTW != NULL )
OnAdvancedPopupMenuTipWndDisplay( *pATTW, m_nSBMHT, true );
}
bFinalNotify = true;
}
_psbd.AdjustHT( ptCursor );
rcArea = _psbd.GetAreaRect( CExtPaintManager::__ESBMHT_THUMB );
continue;
}
if( m_bPopupInactiveLightMode
&& ( msg.message == WM_TIMER
|| (__EXT_MFC_WM_MOUSEFIRST <= msg.message && msg.message <= __EXT_MFC_WM_MOUSELAST )
)
)
::PeekMessage(&msg,NULL,msg.message,msg.message,PM_REMOVE);
else
if( ! AfxGetThread()->PumpMessage() )
break;
}
if( ! ::IsWindow( hWndOwn ) )
return;
if( nStepSize != 0L )
{
::KillTimer( hWndOwn, nTimerID_1st_slow );
::KillTimer( hWndOwn, nTimerID_2nd_fast );
}
bAnimationLocked = AnimationClient_CacheGeneratorIsLocked();
if( ! bAnimationLocked )
{
AnimationClient_CacheGeneratorLock();
if( AnimationClient_StateGet(true).IsEmpty() )
AnimationClient_CacheNextStateMinInfo( false, __EAPT_BY_PRESSED_STATE_TURNED_OFF );
}
if( bFinalNotify )
{
bool bSendScrollingNotification = true;
_SetScrollPos( nScrollPos, false, true, bSendScrollingNotification );
}
m_nSBMHT = INT(CExtPaintManager::__ESBMHT_NOWHERE);
m_bProcessingClick
= m_bProcessingOutClick
= m_bProcessingHover
= false;
if( ! bAnimationLocked )
{
::GetCursorPos( &ptCursor );
ScreenToClient( &ptCursor );
_psbd.AdjustHT( ptCursor );
m_nSBMHT = INT(_psbd.m_eSBMHT);
AnimationClient_CacheNextStateMinInfo( true, __EAPT_BY_PRESSED_STATE_TURNED_OFF );
AnimationClient_CacheGeneratorUnlock();
}
Invalidate();
UpdateWindow();
m_nHelperTrackPos = -1;
m_bHelperHaveTrackPos = false;
ScrollBar_CaptureRelease();
if( pATTW != NULL )
OnAdvancedPopupMenuTipWndDisplay( *pATTW, INT(_psbd.m_eSBMHT), false );
::SendMessage( hWndParent, _psbd.m_bHorzBar ? WM_HSCROLL : WM_VSCROLL, MAKEWPARAM( SB_ENDSCROLL, 0 ), LPARAM(m_hWnd) );
if( m_bEnableHookSpy )
HookSpyRegister();
}
|
|
Krustys Donuts
|
Jul 8, 2008 - 1:01 PM
|
I’m using Prof-UIS version 2.83. I have a CExtGridWnd with 5 columns. The 5th (rightmost) column is editable. The columns are all narrow enough to all fit in the horizontal space available to them, so the horizontal scrollbar at the bottom of the control is grayed out. When the user clicks in the rightmost column, the columns all immediately shift two columns to the left, so that the 1st and 2nd columns are clipped off. However, the horizontal scrollbar is still grayed out, so the user cannot scroll the columns back into view! The only thing the user can do is use the left-arrow key to move keyboard focus back into the leftmost column, which causes it to horizontally-scroll back into view. What should I do to prevent this ridiculous auto-scrolling? The CExtGridWnd’s style flags are set by the code below, if this helps:
DWORD extGridBaseStyle = __EGBS_SFB_CELLS | __EGBS_GRIDLINES_H | __EGBS_GRIDLINES_V |
__EGBS_NO_HIDE_SELECTION | __EGBS_RESIZING_CELLS_OUTER_H | __EGBS_DYNAMIC_RESIZING_H |
__ESIS_DISABLE_AUTOHIDE_SB_H | __ESIS_DISABLE_AUTOHIDE_SB_V | __EGBS_SUBTRACT_SEL_AREAS;
SiwModifyStyle( extGridBaseStyle, 0, false);
DWORD extGridBaseStyleEx = __EGBS_EX_CELL_TOOLTIPS | __EGBS_EX_HVI_EVENT_CELLS | __EGBS_EX_HVO_EVENT_CELLS |
__EGBS_EX_HVI_HIGHLIGHT_ROWS;
SiwModifyStyleEx( extGridBaseStyleEx, 0, false);
DWORD extGridWndStyle = __EGWS_BSE_EDIT_CELLS_INNER | __EGWS_BSE_EDIT_SINGLE_LCLICK | __EGWS_BSE_EDIT_DOUBLE_LCLICK |
__EGWS_BSE_EDIT_SINGLE_FOCUSED_ONLY |
__EGWS_BSE_EDIT_RETURN_CLICK | __EGWS_BSE_WALK_HORZ | __EGWS_BSE_WALK_VERT; // | __EGWS_BSE_EDIT_AUTO
BseModifyStyle( extGridWndStyle, 0, false);
|
|
Krustys Donuts
|
Jul 10, 2008 - 2:38 PM
|
I couldn’t get the problem to reproduce in the test application you attached, no matter how I massaged it (reduced the number of columns, changed the style flags to match mine, etc.). However, I discovered that removing the __ESIS_DISABLE_AUTOHIDE_SB_H style flag from my own grid (in the call to SiwModifyStyle() ) makes my problem go away.
|
|
Technical Support
|
Jul 9, 2008 - 12:40 PM
|
First of all, please invoke the OnSwUpdateScrollBars() method at the end of grid initialization. The scroll bar states should be always synchronized with the width/height of columns. If you do not need the horizontal scroll bar, you should disable or hide it. If the OnSwUpdateScrollBars() method does not help, we would like to ask you to reproduce the problem using the following very simple grid-based test application and send it to us:
|
|
Krustys Donuts
|
Jul 10, 2008 - 2:39 PM
|
I couldn’t get the problem to reproduce in the test application you attached, no matter how I massaged it (reduced the number of columns, changed the style flags to match mine, etc.). However, I discovered that removing the __ESIS_DISABLE_AUTOHIDE_SB_H style flag from my own grid (in the call to SiwModifyStyle() ) makes my problem go away.
|
|
Technical Support
|
Jul 10, 2008 - 3:25 PM
|
If you are using the __ESIS_DISABLE_AUTOHIDE_SB_H grid style, please ensure the grid window is created with the WS_HSCROLL standard window style which makes the horizontal scroll bar initially visible. If the grid window is created without the WS_HSCROLL style, then you can apply it using the following code: CExtGridWnd & wndGrid = . . .
wndGrid.ModifyStyle( 0, WS_HSCROLL, SWP_FRAMECHANGED ); After that you can apply the __ESIS_DISABLE_AUTOHIDE_SB_H grid style and it should work without any problems.
|
|
Offer Har
|
Jul 7, 2008 - 6:56 AM
|
I have an application, in it a floating bar. 1) Click on the main-frame title bar to give it the focus (this ensures the floating bar does not have focus) 2) Move mouse to the frame of the floating bar 3) Start dragging (fast! from the time you press down the button till you start move the mouse do not wait - the bar must not have the focus when starting the drag.) You will see that the frame and the mouse cursor are not in the same place - the frame is lagging after the mouse. This did not happen in version 2.82.
|
|
Technical Support
|
Jul 7, 2008 - 12:36 PM
|
We believe the problem is really hidden in something what has not been discussed yet:
1) Do you use any heavy timers in your project?
2) Do you use any heavy command updating methods in your project?
3) And last but not least: do you use a heavy overridden version of the CWinApp::OnIdle() method in your project?
|
|
Offer Har
|
Jul 7, 2008 - 1:01 PM
|
1) We use timers, to update the views 2) No 3) No But - in 2.82 with the same code this does not happen.
|
|
Technical Support
|
Jul 8, 2008 - 8:29 AM
|
If we start drag-n-dropping a floating control bar, the mouse position is always kept in the same location relative to the top/left corner of the floating mini frame window regardless of how we started drag-n-dropping it. But, if we have two or more visible control bars in one tabbed group and we drag the third floating bar into the third tab into the same tabbed group temporarily without releasing tje mouse button and then drag it out of the tabbed group, then the mouse position relative to the top/left corner of the floating mini frame window can change. Is that what you mean?
|
|
Offer Har
|
Jul 8, 2008 - 8:32 AM
|
Dear Support, When I first reported that bug, I sent you a video clip of how it looks. Did you look at it? Please look at it and it will all be clear. Ron.
|
|
Offer Har
|
Jul 7, 2008 - 6:54 AM
|
I create a new node in the tree, get its HTREEITEM and call this line (I have a two columns tree): GridCellJoinSet(CSize(2,1), 0, ItemGetVisibleIndexOf(hti));
What happens is very weird - it seems that the two cells in the row that I joined are being written one on top of the other... Note that the two cells are of the type CExtGridCellString , the left one has a text value, and the right one is empty, what I wanted was that when the left column becomes narrow, the text will flow to the right column’s cell. I am using it in one row only (as you can see above: CSize(2,1) ) Please fix.
|
|
Technical Support
|
Jul 8, 2008 - 12:35 PM
|
|
|
Offer Har
|
Jul 8, 2008 - 3:23 PM
|
The same bug I reported also happens in your beta demo: Check what happens when you drawg the left side of the column marked as ’Second column’ to the left . Look what happens in the second and third row - you do not compute the offset of the nodes correctly. The same happens in 2.83
|
|
Offer Har
|
Jul 7, 2008 - 6:52 AM
|
Dear Support, When setting a color to a grid combo-box cell, and leaving the grid from focus as describes below, the color is changed to be black. 1) Create a dialog with a grid and an button (don’t implement any handler to the button - this is dummy button). 2) Create a CExtGridCellComboBox . 3) Add items to it, each one with a different color using SetItemTextColor . 4) Run the application 5) Select an item in the cell’s combo-box drop list (the colored item should appear in the cell) 6) click on the dummy button. What you will see is that the combo-box lost its color. if you don’t do step 6, the color remains. The bug is when the grid loses its focus, and the focus cell is a cell mentioned. Please fix
|
|
Technical Support
|
Sep 24, 2008 - 5:03 AM
|
We need your help in reproducing this issue. Could you please modify the following simple test project in such a way that we have grid cells like you have in your real project and provide us with exact description of what we should click, press, move, drag and do to see the problem?
http://www.prof-uis.com/download/forums/TestHoveredButtonsForRon.zip
|
|
Offer Har
|
Sep 18, 2008 - 5:24 AM
|
The Grid page in the ProfUIS_Controls sample application does not contain a combo like I described! My combo is one that each item is in a different color, and when it is selected, as one would excpect, the selected item text & color are moved to the cell. If you create such combo, and repeat the stepsr I described you’ll see the bug.
|
|
Offer Har
|
Sep 8, 2008 - 3:26 PM
|
Dear Support, It’s been two months now!!! Please FIX this bug. Ron.
|
|
Offer Har
|
Jul 17, 2008 - 1:53 PM
|
Can you please confirm this bug and fix it?
|
|
Technical Support
|
Sep 18, 2008 - 3:36 AM
|
The Grid page in the ProfUIS_Controls sample application contains a grid window with color cells, many hyper link buttons at the bottom and a push button. We failed to reproduce this issue with this sample application. Could you please create a small test project that reproduces this problem?
|
|
Offer Har
|
Sep 18, 2008 - 5:26 AM
|
The Grid page in the ProfUIS_Controls sample application does not contain a combo like I described! My combo is one that each item is in a different color, and when it is selected, as one would excpect, the selected item text & color are moved to the cell. If you create such combo, and repeat the stepsr I described you’ll see the bug.
|
|
Offer Har
|
Jul 7, 2008 - 6:50 AM
|
I have a grid with 4 rows visible, and 5 rows in total. The height of the grid is set so that exactly 4 rows are displayed. When rows 1-4 are displayed, and I click on row 4, the grid scroll down to show row 5, which it should not. I found that this happens if I show exactly 4 row, if I add even one row of pixel below the 4th row, it does not jump, as you can see in this zoomed in screen-shot. Can you please make it more precise to the pixel level? Thanks, Ron.
|
|
Offer Har
|
Jul 17, 2008 - 1:54 PM
|
Can you please confirm this bug and fix it?
|
|
Offer Har
|
Sep 8, 2008 - 3:28 PM
|
Can you please confirm this bug and fix it?
|
|
Technical Support
|
Sep 9, 2008 - 2:21 PM
|
We have fixed the selection of last and partially visible row at the bottom. We can provide you with the source code update for most of issue you reported, but as result you will get Prof-UIS version which is very close to latest stable 2.84. We think you have reason to update to 2.84.
|
|
Offer Har
|
Sep 9, 2008 - 3:20 PM
|
1) When you fix bugs, please let us know - as we try and keep track of all open issues, and it consumes a lot of time on our side. 2) Please send us the latest stable code of 2.84 Thanks.
|
|
Offer Har
|
Jul 7, 2008 - 6:49 AM
|
I have an application that runs on a computer with 2 monitors set in Dual View mode. On the primary display, when the application is maximized all looks well. On the secondary display, 2 pixels are cut-off in all sides of the application when maximized.
|
|
Offer Har
|
Sep 8, 2008 - 3:29 PM
|
Can you please confirm this bug and fix it?
|
|
Technical Support
|
Sep 9, 2008 - 2:17 PM
|
Believe or not, this issue is definitively fixed. We re-coded multi-monitor support for Prof-UIS 2.84. There are no more issues like pixels of maximized window outside monitor where it’s maximized and partially visible status bar at the bottom. We can provide you with the latest stable and tested Prof-UIS 2.84 source code.
|
|
Offer Har
|
Sep 9, 2008 - 3:11 PM
|
Thanks. Next time please do not ignore our posts, just reply and let us know that these issues are fixed. Are you still planningon releasing 2.84 next week? Can you please e-mail us the latest 2.84?
|
|
Technical Support
|
Sep 10, 2008 - 9:11 AM
|
It looks like the release of 2.84 will be delayed for some not very long time. Could you please drop us an e-mail to the support mail box so we will reply with the download information?
|
|
Offer Har
|
Jul 7, 2008 - 6:48 AM
|
I have a multi-line edit box with one line of text in it. When resizing the dialog the text flickers heavily. Please fix.
|
|
Offer Har
|
Jul 12, 2008 - 9:51 AM
|
Yes I did. Please look at the previous thread about this bug - there is a screen-shot of the edit box properties.
|
|
Technical Support
|
Jul 12, 2008 - 9:40 AM
|
Did you apply the WS_CLIPCHILDREN and WS_CLIPSIBLINS styles to your dialog window as we already suggested?
|
|
Offer Har
|
Sep 8, 2008 - 3:29 PM
|
Can you please confirm this bug and fix it?
|
|
Technical Support
|
Sep 9, 2008 - 2:18 PM
|
Please understand us right. We have researched this problem in details. But we came to conclusion that is easier to replace edit control with rich edit control if you need flicker free editor or log viewer window which is also can be used as both single line and multiline text editor. This is clearly visible in the ProfUIS_Controls sample application where you can compare resizing of multiline rich edit on the Date Browser dialog page and simple multiline edit control on the Date and Time dialog page. In both case Prof-UIS skinned scroll bars are applied but in both cases inner client are is painted by original controls - not by Prof-UIS. We would be really happy to fix flicker of simple edit common control, but it looks like it’s very special issue because we suspect Windows and/or Common Control library handles edit windows in some special way. It’s easier for us to code a new editor like http://www.codeproject.com/KB/edit/crysedit.aspx or http://www.scintilla.org. It’s easier for you to switch using rich edit window and not to wait for anything. Besides, MS Office, Visual Studio .NET, Visual Studio 2005 and Visual Studio 2008 applications are using rich editor windows everywhere it’s possible: all the edit controls inside toolbars and menus (including combo boxes) are rich editors there.
|
|
Offer Har
|
Jul 7, 2008 - 6:44 AM
|
When switching views from the CExtTabMdiWnd , the OnSetFocus is not called in the views. Please fix.
|
|
Offer Har
|
Jul 8, 2008 - 3:27 PM
|
I did some more tests in my application, and this is what I found: 1) My application has a view which is created in InitInstance, and is maximized 2) The focus message is lost as long as I do not click anywhere in the view. the minute the view gets the focus once, all the conscutive focus messages are received. Of-course if I switch views not from the CExtTabMdiWnd I alays get the focus message, so somehow the CExtTabMdiWnd eats these messages...
|
|
Technical Support
|
Jul 8, 2008 - 12:34 PM
|
We used the TabPages sample for testing where we added the following two message handlers to the CChildView class: void CChildView::OnSetFocus(CWnd* pOldWnd)
{
CWnd::OnSetFocus( pOldWnd );
TRACE1( "CChildView::OnSetFocus() for %p\r\n", this );
}
void CChildView::OnKillFocus(CWnd* pNewWnd)
{
CWnd::OnKillFocus( pNewWnd );
TRACE1( "CChildView::OnKillFocus() for %p\r\n", this );
} The handling of both messages was correct. Please notice the MDI child frame window receives the focus first. This happens when MDI child frame window becomes activated. It handles focus gaining and sets focus to its child view window. The view window can be any type of window but it must have the AFX_IDW_PANE_FIRST dialog control identifier which allows the MDI child frame window to determine which of its child windows is the view window. The view window in your project can be un-focused only in the following cases: 1) Focus changing is handled in your MDI child frame window in some special way and, as result, focus is not forwarded to view. 2) Focus changing is handled in the view’s WindowProc() method without invocation of the parent class method. 3) Focus changing is filtered in some PreTranslateMessage() method. 4) Focus changing is filtered in some thread hook procedure. We are sure all the cases are not related to Prof-UIS source code.
|
|
Offer Har
|
Jul 8, 2008 - 3:29 PM
|
I did some more tests in my application, and this is what I found: 1) My application has a view which is created in InitInstance, and is maximized 2) The focus message is lost as long as I do not click anywhere in the view. the minute the view gets the focus once, all the conscutive focus messages are received. Of-course if I switch views not from the CExtTabMdiWnd I alays get the focus message, so somehow the CExtTabMdiWnd eats these messages...
|
|
Technical Support
|
Jul 10, 2008 - 1:44 PM
|
We need your help in reproducing this problem with one of Prof-UIS sample applications or any other test project:
1) Which type of view class should be used? Form view? Edit View? Simple CView? Any other?
2) Do you use any complex routes in message pre-translation?
Could you try to trace the WM_SETFOCUS messages sent to your view window using TRACE***(***) in the PreTranslateMessage() virtual method of your view class? We need to know whether WM_SETFOCUS is not passed through message pre-translation routes?
|
|
Ian McIntosh
|
Jul 3, 2008 - 11:09 AM
|
Hi,
I have a class derived from CExtTabPageContainerWhidbeyWnd. When it is initially displayed, the scroll bars look like standard MFC scrollbars (ie, grey). However, if I click on the scrollbar it gets redrawn as a prof-UIS style scroll bar (ie, coloured & responds to mouse hovver events).
Any idea what could be causing this?
|
|
Technical Support
|
Jul 4, 2008 - 1:17 PM
|
The page container windows never have scroll bars. They are simply container windows for one tab control and several page windows. Please provide us with more exact details about where and which window you have created with scroll bars? Did you create some child window inside a tab page container and register it as a page?
|