Well, I am infact not getting mouse wheel messages, only vscroll. That is, if the scroll bar is on. I think it depends on the mouse driver. Once I got two mice connected. One would send mouse wheel as expected, another would translate wheel messages to vscroll. So I need to break in, where the mouse wheel comes in to reject cscroll messages on mouse wheel.

I'm using mouse wheel as user input in a CWnd. But when vertical scroll bars are on, I'm receiving OnVScroll() messages instead of OnMouseWheel() messages. How can I ignore OnVScroll() messages, and always receive OnMouseWheel() as if the scrollers were not enabled? Thanks

Thank you for your help, it works with the handler - still I wonder, still I wonder.. :)

So I shouldn't override OnCommand(), instead I should create a handler? ON_COMMAND_RANGE( 700 , 701 , OnMenuCommand ) afx_msg void OnMenuCommand ( UINT nID ) I just wonder - why is OnCommand() virtual then?

No I am overriding OnCommand() For CWnd's this seems to be enough - maybe for CFrameWnd's it's not enough?

All items are grayed out, why?

void CMyFrameWnd::OnRButtonUp(UINT nFlags, CPoint p)
{
CMenu menu;
menu.CreatePopupMenu();
menu.AppendMenu( MF_STRING | MF_ENABLED , 700 , "Zoom All" );
menu.AppendMenu( MF_STRING | MF_ENABLED , 701 , "Properties" );
ClientToScreen(&p);
menu.TrackPopupMenu(TPM_CENTERALIGN,p.x,p.y,this,NULL);
CFrameWnd::OnRButtonUp(nFlags, point);
}

I tried creating such a header-wnd already. This approach has three additional problems: 1) the header and the actual grid dowsn't draw excactly at the same time (even if they're invalidated at the same time), so the header seem to be 'ahead' of the grid when resizing columns. 2) the header leaves a blank space in upper right corner of the grid control, above the vertical scroller. Notice file explorer has a scroller all the way up to the top. 3) too much housekeeping with who's actually owning the 'columns'. The header should simply know so much about the grid, that it might aswell be the same window. My next strategy is as follows: Create a header-cwnd yes, but leave it 'blank', that is without drawing anything with it. Pass all mouse messages on to the grid ctrl. Let the header and the cedit have the CLIP_SIBLINGS flag, and they'll clip against each other. Clumsy yes - but it's the only solution I can find to my question: "how to clip child windows to a clipping region defined by the parent?" - Holy cow Simple is beautiful

Yes, this is excactly what I'm doing. When the user clicks a cell, I create a new cedit and places it at the cell position. Trouble is vertical scrolling - the newly created cedit will draw on top of (instead of beneath) the header row drawn by the parent. I took a look at Mauders grid control, but you'll notice that he scrolls in steps of 'row height', so he can hide the entire cedit instead of clipping it. I'd like smooth scrolling (pixel by pixel), so it's possiblt for the cedit to be partly hidden beneath the header row. Usually child wnd's are clipped to the parents client rect. Eg you can create a new cedit at location CRect(10,-10,100,10) and it will be partly hidden. CRect cr; GetClientRect(&cr); always as (0,0) as upper left corner, and 'size-of-cwnd' as the lower right corner. This client rect defines the clipping rect to which child cedits are clipped. And this is the rect I want to modity by eg: cr.top += HEADER_ROW_HEIGHT; ClipChildrenToThisRect(&cr); Kno' I mean? :) Simple is beautiful

Hard hehe, I shortened my question for experts to take their time to actually read the question. Left out the details on what this was for, because I know that I'm actually re-inventing a huge wheel here - but it's a whole lot of fun! Yes drawing the parent is the simple part, and it's all handled already (on a memdc without flicker) I know how to use clipping regions while drawing, but they won't clip child cedit's - and that's what my question is all about. So it's not a question on how to code a grid control, it's far more simple: Is it possible to clip child wnd's to a rect defined by a parent? :) Simple is beautiful

I have got at CWnd that add's CEdit's to itself. Parent draws a grid, in where those CEdit's are placed. The parent also has a scrollbar to the right, so that I can move my edit fields up and down. The parent draws a header row on top, but I don't want to have the cedits drawn on top of the header as I scroll up and down. So I want to create a 'clipping region' inside my client area, in where child cedits are allowed to draw themselves. Hope this helps? Thanks for your time :) Simple is beautiful

Question is, how can I reduce the client area? Simple is beautiful

Is it possible for a CWnd to clip child wnd's to a clipping region determined by the parent. Normally children are clipped to client area, but how can I reduce this area? Simple is beautiful

To make it simple, I made this small utility that converts a binary file into an array of unsigned chars for the compiler to read. This enables me to #include the binary chunk directly into the source. Wooh, does this smell like good old times..

I'm creating a library with som custom controls. How can I have a bitmap drawn on a custom button? When the button control is in a .lib - where to put the image? What about resource conflicts? Thanks for any comment

I am looking for strategies for using tree controls. The goal is to extend the CTreeCtrl (or maybe even build a new custom CWnd descendant tree control) in a way that makes it easy to use, and that hides away most of the uggly struct and message tweeking needed. At init I would want to add one single node, the root, to the tree control. And as user expands nodes, the tree would ask the node to list its children. For the tree to be able to ask nodes for children, we need some kind of "class ITreeNode" interface. Implementing this interface would enable an object to be represented as a node in the tree. And the object would itself be in charge of how it should be represented in the tree. The tree this way visualizes the object structure in memory, which is a fair approach imo. The treenode interface could look something like this... class ITreeNode { virtual CString GetTreeLabel() { return "Default"; } virtual void GetTreeChildren( CTreeNodeList& L ) {} virtual int GetTreeImage() { return 0; } virtual int GetTreeImageSelected( return GetTreeImage(); } } Did anyone experiment with anything like this?

I use mouse wheel in my application to alter the size of a square in my view. I use ON_WM_MOUSEWHEEL() to catch the wheel messages. Everythin worked just fine, untill I upgraded to XP. Now I get ON_WM_VSCROLL() messages instead, and never see the wheel messages when the scrollbar is on. I want to find a way to bypass the scrolling and have wheel messages instead, how? Thanks Jesper

I use mouse wheel to zoom in/out on my CScrollView. But now on windows xp (previously i used w2k without problems), i get OnVScroll() messages instead of OnMouseWheel(). I cant find a way to catch the wheel and overrule the scrolling behaviour. What the...?? When the scrollbars are off, I get mousewheel messages When the scrollbars are on, I get vscroll messages I want to always reveive mouse wheel! Thanks

I have around five years of mfc programming behind be, and one thing I've learned is that there is no such a thing as "forward approach". But as I mentioned before, looking at mfc's own scroll code may help you a great deal. And btw, don't forget, you'll have to set the dc's viewportorg yourself before drawing in your OnPaint() function. This is what makes the control scroll its contents. something like this (please forgive me if this doesn't compile, it's straight out of my mind..) void SomeControl::OnPaint() { // let the scrollbars move dc's viewportorg CPaintDC dc(this); int orgx = GetScrollPos(SB_HORZ); int orgy = GetScrollPos(SB_VERT); dc.SetViewPortOrg(-orgx,-orgy); // then draw the actual control dc.MoveTo(0,0); dc.LineTo(100,100); } Good luck - Jesper

Hi You may have to add ON_WM_VSCROLL() to your message map and implement the function, maybe something like this, which works for me. Think I stole some of it from mfc's own CScrollView, take a look here too. Don't know why this doesn't work automatically inside mfc. I feel like (by calling SetScrollPos()) I'm telling the scrollbar something it actually already knows. Well mfc is not alway intuitive, and always trying to figure out "why" will make you go nuts :confused:. Who knows why scrolling works like this, am I completely out of track here? - Jesper void EPropListCtrl::OnVScroll( UINT nSBCode, UINT nPos, CScrollBar* pScrollBar ) { int nNewPos = -1; int sp = GetScrollPos(SB_VERT); if( nSBCode==SB_THUMBPOSITION || nSBCode==SB_THUMBTRACK ) { nNewPos = nPos; } else if( nSBCode==SB_LINEUP ) { sp -= 5; nNewPos = sp; } else if( nSBCode==SB_LINEDOWN ) { sp+=5; nNewPos = sp; } else if( nSBCode==SB_PAGEUP ) { sp-=20; nNewPos = sp; } else if( nSBCode==SB_PAGEDOWN ) { sp+=20; nNewPos = sp; } if( nNewPos >= 0 ) { SetScrollPos( SB_VERT , nNewPos ); Invalidate(); } }

This would increment the index at runtime. What I need is the pre-processor to increment the index as it compiles so that the indices are found at compile time and fixed at runtime. Something like this (which will not compile..) #define AAA 0 #define NEXT_INDEX { AAA //insert as AAA #define AAA (AAA+1) //next time it is incremented by one } First time using NEXT_INDEX it compiles to AAA (which is 0 at first), next time I want it to compile to 1. This setup imo makes sence, but not to the compiler.. ;)