I don't know your actual requirement but ICommand can be helpful in such situations. It makes your view cleaner. May I get the exact scenario for the problem? :) Niladri Biswas

Expose a CollectionViewSource on your ViewModel. The use the IsSynchronizedWithCurrentitem property on the two controls. I know it sounds simple, but it works and was designed to be simple. Cheers, Karl » CodeProject 2008 MVP, CodeProject 2009 MVP My Blog | Mole's Home Page | XAML Power Toys Home Page Just a grain of sand on the worlds beaches.

You're welcome. "WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes. My blog | My articles | MoXAML PowerToys | Onyx

I fiddled a bit with my code and found the cause, even though I don't really understand why. My application uses a directx renderer from a DLL that's written in C++. To init the renderer, I pass it the WPF window's hwnd by using WindowInteropHelper. Now the interesting bit: If I init the renderer before creating and showing my modeless dialogs (the ones with the scrollbar problem), the scrollbars don't appear correctly. But if I init the renderer *after* creating the dialogs, the scrollbars are fine. If anyone has an idea of why this happens, I'd be happy to hear it! :)

You can override the TreeViewItem template ? <Style TargetType="TreeViewItem"> <Setter Property="Template"> <Setter.Value> <ControlTemplate TargetType="TreeViewItem"> <StackPanel Orientation="Horizontal"> <TextBox></Button> <Button>X</Button> </StackPanel> </ControlTemplate> </Setter.Value> </Setter> </Style>

If you provide a DataTemplate for each of the types, it should pick it up automatically. Check this post[^] from Mark. It should give you an idea.

See the project settings that you have the 'Import Library' option set under 'Linker->Advanced'. This controls the creation of the .lib file. Also, you must have a module definition file in your project. If this file doesn't exist, then the compiler/linker creates the export library only if you have dllexport-declarations inside the code files. This might result in incorrect behaviour if those functions which you add to the classes are not exported. The module definition file is not required to export any symbols. All that needs to be there is a line 'LIBRARY your_dll_name_here'. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.

I disagree. A CMemFile object is a memory file that behaves like a disk file except that the file is stored in RAM rather than on disk. A MMF, by definition, provides you with the capability to map a view of all or part of a file on disk to a specific range of addresses within your process's address space. Once that is done, accessing the content of it is as simple as dereferencing a pointer in the designated range of addresses. I fail to see how they are THAT different. In either case, once the file is read from disk and into memory, you operate on the file in its memory-mapped state, using the appropriate functions. The MSDN article Q142377 offers another view.

Sounds like an excellent candidate for using a DATABASE. Like SQL Server. That's what these programs do for a living.... If you really need to do this yourself, you should probably create a series of memory structures to house the data and create indexes on the various fields. The MFC/OO approach would be to create objects similar to the following: class CommandObj { public: CString m_cCommandTime; CString m_cCommandName; WORD m_wParam1; WORD m_wParam2; WORD m_wParam3; }; class CommandDB { BOOL CheckMatch(CommandObj *pCmdObj, LPCSTR cpCommand, WORD *wpParam1, WORD *wpParam2, WORD *wpParam3); public: CObList m_oCommands; // list of Command objects CMapStringToOb m_oCmdNameIndex; // index of cmd name to a CObList of Command objects that have this cmd name CMapWordToOb m_oParam1Index; // index of param1 values to a CObList of Command objects that have this value virtual ~CommandDB(); // clean up our lists void AddCommandObj(CommandObj *pCmdObj); BOOL SearchCommands(CObList *pOutputResults, LPCSTR cpCommand, WORD *wpParam1, WORD *wpParam2, WORD *wpParam3); }; void CommandDB::AddCommandObj(CommandObj *pCmdObj) { CObList *pIdxList = NULL; // update our indexes... if (!m_oCmdNameIndex.Lookup(pCmdObj->m_cCommandName,pIdxList)) { pIdxList = new CObList; m_oCmdNameIndex.SetAt(pCmdObj->m_cCommandName,pIdxList); } pIdxList->AddTail(pCmdObj); if (!m_oParam1Index.Lookup(pCmdObj->m_wParam1,pIdxList)) { pIdxList = new CObList; m_oParam1Index.SetAt(pCmdObj->m_wParam1,pIdxList); } pIdxList->AddTail(pCmdObj); // and add to "table" m_oCommands.AddTail(pCmdObj); } BOOL CommandDB::SearchCommands(CObList *pOutputResults, LPCSTR cpCommand, WORD *wpParam1, WORD *wpParam2, WORD *wpParam3) { BOOL bFound = TRUE; CommandObj *pCmdObj; CObList *pKeyList = NULL; if (cpCommand != NULL && *cpCommand) m_oCmdNameIndex.Lookup(cpCommand,pKeyList); else if (wpParam1 != NULL) m_oParam1Index.Lookup(*wpParam1,pKeyList); else pKeyList = &m_oCommands; // table scan time... // scan keyset for matches POSITION pPos = pKeyList->GetHeadPosition(); while (pPos) { pCmdObj = (CommandObj *)pKeyList->GetNext(pPos); if (CheckMatch(pCmdObj,cpCommand,wpParam1,wpParam2,wpParam3)) { bFound = TRUE; pOutputResults->AddTail(pCmdObj); } } return bFound; } BOOL CommandDB::Check

You might want to have a look at KB article Q75236. http://support.microsoft.com/default.aspx?scid=kb;en-us;Q75236 I have to admit to never having used OpenGL. Do you not do your rendering in response to WM_PAINT messages? 'Cause if your rendering is in response to WM_PAINT, you won't get any WM_PAINT messages if the window is totally obscured.

Looks like that works. Thanks :) Shawn

Would you be able to post your code for loading and releasing the DLL's. What you are describing sounds weird. The only other things I can think off that would possibly affect you are that because they are extension DLL's they get loaded/released together, or the base address's of the dlls (set in the linker tab of settings) are clashing somehow. Roger Allen Sonork 100.10016 If I'm not breathing, I'm either dead or holding my breath.

Sounds like you bound a data variable (like a double, or float) instead of a control class (like CEdit), and letting MFC do the value-to-text & text-to-value conversions for you.    Bind a CEdit to the edit control, and handle the display/conversion yourself.    Or, you could write your own DDX routine to format the value as you like.  Look up "TN026" in MSDN for more information.    Peace! -=- James.

I understand the error a little more. The "#File Error#" part of the message means that it can't find the file the error occurs in, so instead of the filename it gives #File Error#. So, it knows there's a memory leak and it knows at what line it happens, but it doesn't know which file. Ugh. I'll investigate some more. Steve The Plant

Wow! You really do know what you're talking about, don't you? I stand corrected, I bow my head before you ;-) I did a search on MSDN on the subject (yeah, I know, should have done it before), and article Q190799 does a pretty good job explaining things (at least after I had read your post first :-) I will immidiately check if my current multi-DLL application project is linked to the MT DLL version! Cheers Steen. "To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"

The usual way of doing this is to handle validation in the OnKillFocus method call for that object. Then, hitting Enter (which will submit the dialog if the edit control is on a dialog) or hitting Tab (which will go to the next field in the tab order if if the edit control is on a dialog) will both kick-off that event. If you're rolling your own interface in a non-dialog setting, you should be subclassing the parent window to pre process all the messages that come through your main window proc, and that would be where you would do Enter and Tab key handling (and other key for that matter).

From VC++ help: Regular DLLs must have a CWinApp-derived class and a single object of that application class, as does an MFC application. Unlike the CWinApp object of an application, the CWinApp object of the DLL does not have a main message pump. [...] If the DLL opens modeless dialog boxes or has a main frame window of its own, the application's main message pump must call a routine exported by the DLL, which in turn calls the CWinApp::PreTranslateMessage member function of the DLL's application object. This should clear things a little bit. Tomasz Sowinski -- http://www.shooltz.com

Hi, Just some stupid ideas: - could it be a Unicode/Ansi mismatch? (DebugString.fUnicode) - a dynamic buffer to store the result would be better, since you know the exact length of the string (otherwise you could have a buffer overrun) As for the indent problem, use <PRE> </PRE> tags to enclose the source code. Cheers, Paolo ------ "airplane is cool, but space shuttle is even better" (J. Kaczorowski)