Take a look at Microsofts public symbol server. You can download symbols for all their code from it, and set breakpoints and so on.
You can speciyf these sylbols in VS and when it tries to load downloads them automatically. I use windbg though so I cant help you much more than that, and I work in the kernel, but if you choose to do the same this is a usefull command:
bp nt!ntcreatefile "dt nt!_UNICODE_STRING poi(poi(@esp+0xc)+0x8)"
It sets a break point on createfile (this is what CreateFile maps to in the kernel) and displays the file being opened (This is 32 bit, if it was 64 the parameter would be in a register not on the stack).
SO any user mode acces to creatfile you can break on and have a wander arond the stack and see whats doing what.
Or as the poster above says, set the bp in the usermode dll.
I can deffinitely recomend using windbg, it is a hell of a debugger, everyone in microsoft uses it, VS is a toy in comparison.
My system is win7 64Bit
I use the VS2008 to compile the chrome solution. But I meet some problem about compile the FFMPEG.
I google that the others are all ok when compiling, but I have bad luck. I donot know why some error happen.
Does anyone meet the same problems?
Hi All, many thanks up-front to anyone who can help here.
I have a client that wants me to migrate a CTreeView-derived class to one which works like a docking pane. The class is so large now that it's not feasible to rewrite everything.
So...I still have the underlying CTreeCtrl-derived class (more/less untouched), which is a child of a class derived from CDockablePane (migrated from the CView class). I've also derived from CMultiPaneFrameWnd (used when the pane is floating) to try to trap events.
I've got it working about 80%. I need help/direction with the other 20%. I've got the CDockablePane derived class working with bulk of the MESSAGE_MAP events (menu handlers, ON_UPDATE_COMMAND_UI, etc.) working correctly. The events associated with the mouse are giving me grief.
I see 3 standard modes for the dockable pane: floating, docked, and tabbed. And they all behave differently w/r to mouse events - and depending on the docking mode.
* If the docking mode is DT_SMART *and* the pane is NOT floating, then drag&drop and double-clicking work correctly.
* If the docking mode isn't DT_SMART, then drag&drop usually tries to drag the complete docking pane instead of working correctly (regardless of floating, docked, tabbed).
* When the pane is floating, I can't trap WM_LBUTTONDBLCLK (unless you click on the lines and little [+] boxes...) or the respective notify or reflect messages - even Spy++ doesn't record them. I just don't see any left button double-click events - at all!
Found it! There is an intermediate class which inherited from CTreeCtrl. It was originally set up to support a CView, and forwarded the LButtonDown event to its parent. Well, now that the parent is a dockable pane, the behaviour changed a lot! Removing that handler got lots of stuff working!
Last Visit: 31-Dec-99 18:00 Last Update: 1-Oct-23 2:34