Had a cup of tea, am felling calmer so here are more details. The view that I'm trying to call is derived from CListview and is a report style List view showing database information in an Access like gridview. This is the code I'm using to initialise it DWORD dwExStyle; CRepPartDoc* pDoc = GetDocument(); ASSERT_VALID(pDoc); //CActionsApp *pApp = (CActionsApp*)AfxGetApp(); CListCtrl& m_List = GetListCtrl(); dwExStyle = m_List.GetExStyle(); dwExStyle |= LVS_EX_FULLROWSELECT | LVS_EX_GRIDLINES; m_List.SetExtendedStyle(dwExStyle); m_List.SetBkColor(RGB(255, 255, 255)); ASSERT(m_List.GetBkColor() == RGB(255, 255, 255)); m_List.InsertColumn(0,_T("Share"),LVCFMT_LEFT,160); m_List.InsertColumn(1,_T("Status"),LVCFMT_LEFT,90); m_List.InsertColumn(2,_T("Action Date"),LVCFMT_LEFT,90); m_List.InsertColumn(3,_T("Book Date"),LVCFMT_LEFT,90); m_List.InsertColumn(4,_T("Comment"),LVCFMT_LEFT,160); I have used it before in a SDI application that opened on this view with no problems whatsoever, which leads me to believe there must be a special way of calling the same view from a menu within a MDI application that I'm missing. This is the only code I have in the menu handler function at the moment CRepPartApp* pApp = (CRepPartApp*)AfxGetApp(); pApp->m_pDocManager->OnFileNew(); All the example's I can find deals with multiple document and views and switching between them. It is a new job and I'm feeling a bit incompetent:-O so any pointers would be much appreciated:) Grasp it but you cannot get it! It's name is memory..

Let's see if I can shed some more light on the subject. There are basically two locations where memory can be allocated in C++: on the stack or on the heap. The stack is used by the compiler mostly to allocate local variables whose size is well known at compile time. Every time you define a local variable (inside a function block), the compiler reserves a block of bytes for the size taken up by the variable. This is a very quick operation because all the compiler does is assign the address to the variable and move its "stack pointer" down by the size of the variable. This is called pushing the stack. When the variable goes out of scope the compiler does the opposite -- it pops the stack -- and the memory is reclaimed. Thus, memory allocated on the stack is automatically reclaimed by the compiler, and it's all very quick because it's all done in one location -- the end of the stack, if you will. The stack is also used whenever a function is called to hold its return address and its parameters (if any). The heap is quite different. It's typically used to allocate variables that you plan to keep longer than duration of a function block, or variables whose size is not known until run-time (such as dynamic arrays). In C++, memory is taken from the heap via the new operator (or via the global C function "malloc"). When this happens, the heap manager looks for a block of memory large enough to hold the contents of your variable and returns the beginning address of that block. This block of memory stays allocated until your program calls the delete operator on that memory (or "free" if malloc was used) or until the program ends. By the way, allocating memory on the heap is much slower than allocating from the stack, so the stack should be used if the variable will not be needed outside the block where it was allocated and its size is known at compile-time. In addition, since the stack's memory is automatically reclaimed, it requires less housekeeping on the part of the programmer (to prevent memory leaks). However, the stack should ONLY be used when the variable will not be referenced outside the block where it was allocated, otherwise you'll be left with an invalid memory address which when used will cause the program to crash. I hope to have cleared things up. Regards, Alvaro Behind a beautiful woman there's usually a guy who just couldn't wait to get rid of her.

:-D Fantastic movie. Fortunately I like my job. :) Jon Sagara What about :bob:? Sonork ID: 100.9999 jonsagara

1. the emulator when used for debugging applications works fine... 2. who do you think writes the drivers for the CE ethernet cards? I really have problems when writing this driver for a PCMCIA ethernet, a wireless LAN or a bluetooth card... I have to debug over USB (with the cradle). Do you know a good kernel debugger for WinCE 3.0 iPac devices? I do not want to use the Platform builder and generate my own CE platform, since I need access to the already existing iPac platform. -------------------------------------------------- If my messages appear curt, I apologize. I try to be brief to save your time as well as mine. --------------------------------------------------

Personally, I wouldn't touch FoxPro with anything other than the delete key. I've never written anything with it, though I have used a couple of programs written in it and also used the IDE to modify databases. There must be a reason nearly every other language under the sun in going to be incorporated into .NET and even though FoxPro is part of Visual Studio it is not. :rolleyes: "das leid schlaft in der maschine" -Einstürzende Neubauten