baumchen It looks as though the scrollbars are associated with the panes in a manner that happened to be right for my application, but is perhaps not right for yours. When you specify WS_HSCROLL and WS_VSCROLL you get a horizontal scrollbar on all the panes along the bottom of the window, and a vertical scrollbar on all those on the right hand side. So in my 2x2 display I have 4 scrollbars in total. (Without WS_HSCROLL and WS_VSCROLL there would be 8, 2 for each pane). Sorry, the description in my earlier post was a little misleading. I had forgotten the existence of 2 of my scrollbars because the top row is sized such that it never needs vertical scrolling, and the left column never needs horizontal scrolling - so their bars are always grayed out. It appears that the horizontal scrollbars are shared by all the panes stacked above them, and the vertical ones by all the panes on the row to their left. I haven't been able to test this completely because my top-left pane is a dummy - but this is certainly how the other 3 behave. This would be consistent with your result. In a 1 row x 2 column display, you only get one shared scrollbar - the vertical one. I haven't managed to find any documentation to confirm this, but Technical Note 29 (.Net 2002) has a very short section on shared scroll bars which hints at this arrangment. I didn't write any special handlers. The base classes, CSplitterWnd and CScrollView, managed all the scrolling messages for me. Best Wishes Cliff

I'm not sure if this exactly fits your requirement, but it is possible to place two views derived from CScrollView into different panes of a splitter window and scroll them together. You need to specify WS_VSCROLL when you create the splitter, otherwise you get a scrollbar for each pane instead of one that works them both. I used WS_HSCROLL and WS_VSCROLL in a recent application to scroll around a matrix and get the row and column headings to scroll along with the body of the matrix. Like this (CMatrixSplitterFrame derived from CMDIChildWnd):

BOOL CMatrixSplitterFrame::OnCreateClient(LPCREATESTRUCT lpcs, CCreateContext* pContext)
{
//Create a splitter with 2 rows and 2 columns
if (!m_SplitterWnd.CreateStatic(this, 2, 2, WS_CHILD | WS_VISIBLE | WS_HSCROLL | WS_VSCROLL)) //Specify WS_HSCROLL and WS_VSCROLL to get one set of horizontal and vertical scrollbars for the splitter window instead of both in each pane.
{
TRACE0("Failed to CreateStaticSplitter\n");
return FALSE;
}

//Add column headings pane
if (!m\_SplitterWnd.CreateView(0, 1,	RUNTIME\_CLASS(CKernelMatrixColHeadView), CSize(2000, CELL\_YSIZE + CELL\_INTER\_GAP + CELL\_INTER\_GAP), pContext))
{
	TRACE0("Failed to create second pane\\n");
	return FALSE;
}
    //etc..

Best Regards Cliff Hatch

If you have the handle of the item you want to expand you can call CTreeCtrl::Expand. Something like this:

pTreeCtrl->Expand(hItem, TVE_EXPAND);

P.S. When I first read your post I thought you were just looking for a way to expand a node programmatically, but I've just realised there is more to it and the above reply is probably not much use - because TVE_EXPAND generates a TVN_ITEMEXPANDING message. What problem is the TVN_ITEMEXPANDING message causing you? Best Regards Cliff

modified on Sunday, August 17, 2008 7:36 AM

Your application sounds very similar to the sample program MTGDI in the MSDN Library. It might help you get started. MTGDI[^] Best Regards Cliff

Hans Apologies, I intended to vote your comment 5, but somehow managed to click 1 by mistake :-O - do you know any way to retract a vote? I didn't particularly want to participate in this debate, but I agree that the submission of positive comments is a good strategy. Best Regards Cliff

gor wrote:

CMainFrame can see all the dialog bars and should be the one to update them based on the active document when the active document is changed.

I agree. I update dialog bars from CMainFrame in much the same way as you descibe, except that I make the functions public and call them directly from my view/doc classes instead of sending messages. I override CView::OnActivateView() to get the correct action when the current view is deactivated or a new view is activated. The only problem I had with this was coping with the counter-intuitive way the system sets the pActiveView and pDeactiveView parameters (I'm not sure if this is relevant to your enquiry, but I can provide a code sample if you are interested). I don't know if this is the best approach, but I can vouch for the fact that it works, and that it deals with activation of views by conventional mouse clicks and custom code. It seems strange to me too that there is no function in the CMDIFrameWnd class that can be overridden to achieve this - if you ever discover a better way I would be very interested to hear. Best Regards Cliff

Oh well, it's good to score 100% now and again - it's normally just an aspirational target. :doh: I'm sorry that my reply was unhelpful and glad you have solved the problem. What's the key to updating the view without invalidation? Best Regards Cliff

Hi includeh10

includeh10 wrote:

have downloaded several samples, but all of them are incorrect in basic concept, because they all call update function InvalidateRect(0), RedrawWindow(0) etc - if so, there is no neccessary to use Rubber band tech, as my understanding, rubber banding should only update requied pixels (such as a line) and without touching others (right?).

I wrote an application that displays multiple models (as boxes) and treats connections between them as rubber bands. I used InvalidateRect(), and although I acknowledge that the technique redraws more of the image than is necessary, I wouldn't go so far as to call it incorrect in concept. It does the job and is plenty fast enough to keep pace with mouse moves, even when there are many connections to redraw. It also seems to be the 'windows way'. I'm not sure how to get parts of the view updated without using invalidation. I had some problems with flickering background rectangles in early versions, but solved this by using a memory device context and blitting to the view's device context. Best Regards Cliff

Thanks David Yes, I see the thread count changing. There seem to be a number of short-lived threads in addition to the persistent one I noticed. Best Regards Cliff

Many thanks for this Roger. I didn't know the "Threads" window existed. I found it under "Debug", "Windows", "Threads" in .NET 2002, and suddenly your original post makes perfect sense. :) The unknown thread has the generic sounding title "Win32 Thread", and the call stack contains just two entries: ntdll.dll!7c90eb94() kernel32.dll!7c80b683() I'm still curious about what it does, but it is clearly a system thing (see also reply from David Crow below). I'm happy to accept that - and even happier to have discovered a new Visual Studio feature along the way. :-D Best Regards Cliff -- modified at 12:11 Tuesday 5th December, 2006

Thanks for the suggestion Roger, but I'm having difficulty following your instructions. All the threads close down cleanly when I halt - I assume you mean "pause"? How should I switch the context of the unknown thread? The number of switches increments when I refresh the Spy properties window - is this what you mean? I don't see how the call stack or anything else will be affected when the application is paused. Apologies for this - I think I must be completely mis-interpreting your suggestion - could you provide some clarification? Best Regards Cliff

.NET 2002, MFC Application, MDI.

I'm working on an application that launches a separate thread for some processor intensive activities. I used Spy to look at the running application, expecting to see two threads - but there were three! I can make out the main thread and the one that I launched. Both these clock up CPU time as expected. The third thread doesn't appear to do anything - CPU time etc. stays at zero. The application works fine - I'm just curious to know where the extra thread comes from. I assume the system creates it automatically for some purpose. Does anyone know what it might be for? Best Regards Cliff Hatch

I wrote the following procedure to activate views programatically. It's a bit specialised, but I hope it might give you some useful clues. The bit underneath the comment "//There is already a View displaying this parent..." activates the view pointed to by pView.

CKernelView* CMainFrame::ActivateView(CModel* pParentModel)
{
//Activate new or existing view containing pParentModel

CKernelView \*pView, \*pActiveView;
CWnd\* pBar;
CMDIFrameWnd \*pFrame;
CMDIChildWnd \*pChild;

pBar = GetDlgItem(IDD\_NAVIGATOR\_BAR);

//Get a pointer to the active view (there are three stages to this)
pFrame = (CMDIFrameWnd\*)AfxGetApp()->m\_pMainWnd;		//Get a pointer to the active MDI window
pChild = (CMDIChildWnd \*) pFrame->GetActiveFrame();		//Get the active MDI child window.
pActiveView = (CKernelView\*)pChild->GetActiveView();	//Get the View attached to the active MDI child window

if (pActiveView->m\_pParentModel == pParentModel)
	pView = pActiveView;	//The required parent model is already in the active view
else if (pParentModel->m\_pShadow != NULL)
{
	//There is already a View displaying this parent, activate its frame
	pView = pParentModel->m\_pShadow->m\_pView;
	pFrame = (CMDIFrameWnd\*)pView->GetParentFrame();
	pFrame->ActivateFrame(SW\_RESTORE);
}
else if (pBar->IsDlgButtonChecked(IDC\_TRACK\_NEW))
	pView = pParentModel->OpenView(m\_pDocViewed, pParentModel->m\_PlantFlag);	//Open new window
else
{
	//Reuse current window
	pView = pActiveView;
	pView->ChangeModel(pParentModel);	
}

return pView;

}

Best Regards Cliff -- modified at 17:36 Monday 3rd July, 2006

Thanks Michael, that answers my question perfectly. :) Best Regards Cliff

Thanks guys. I can see that there is a problem if messages conflict, but what's puzzling me is why does it matter what the value is so long as it is unique - and if I use the Resource Symbols dialog to create it, doesn't that guarantee uniqueness? Is it a matter of standardisation and ease of maintenance perhaps? Best Regards Cliff

Thanks for your reply. It makes perfect sense now. :) Best Regards Cliff

The help files recommend that user messages be defined in the range WM_USER to 0x7fff, but opening the Resource Symbols dialog to create a new ID and letting it choose the value seems to work fine. Does anyone know if there is anything wrong with this? Best Regards Cliff Hatch -- modified at 14:42 Wednesday 24th May, 2006

I've created a handler for a user defined message with the following declaration:

afx_msg LRESULT OnIdleScan(WPARAM wPar, LPARAM lPar);

It works, but what value (of type LRESULT) should the function return, and what does the system do with this? I assume it is not passed back via PostMessage, because it doesn't wait for the handler to execute. I'm arbitrarily returning 0 at present. Best Regards Cliff Hatch

It just occurred to me that I may have misread your question. I thought you meant that your Cemulist was a member of Cemu, comprising a recursive structure. Apologies if I have caused any confusion. I would still suggest the same solution though. You could try calling the list's Serialize function from within the Serialize function of whatever object contains the Cemulist, in the same way as I did with m_ModelList. The serialize functions of the list classes invoke the serialize functions of all the things the list points to, so they save the whole structure. I imagine they also write out the number of items, but this is unseen by the user.