Editor/debugger design, looking for suggestions
Greg Lee ID -- GLee@kollmorgen.com Thursday, February 06, 1997 Environment: VC++ 4.0, Win95, MSDN I am writing an MDI editor/debugger which has many of your standard features (breakpoints, single stepping, etc), similar to the Quincy 96 application by Al Stevens in Dr. Dobb's Journal, using CRichEditView as the basis of my design. I am a long time C programmer, but this is my first C++ project and my first Windows programming project. Quite a way to cut my teeth! I have "subclassed" CRichEditView to add the capability of displaying breakpoints attached to a particular line of text. I have this working now, but I am not happy with the way I have done it. A quick description of how I am displaying the breakpoints now: 1) I set the left margin on the RichEditCtrl to allow enough room to display the breakpoint and execution markers. 2) Handle all (hopefully!) of the events which may cause a breakpoint to move and adjust the breakpoint's position correctly. 3) Install my own WindowProc to handle the WM_PAINT and WM_HSCROLL events in which breakpoints have to be displayed. The main problem with this method is that I am displaying the breakpoints in the RichEditCtrl's client area. Luckily the control does not paint over this area, but the mouse pointer is still sensitive to this area. So, highlighting is a little screwed up (the highlight-whole-line mouse icon does not appear until I mouse over to the LEFT of the breakpoints). Additionally, I need to manage the breakpoints a little better (right now they are a global list). I am considering a better/different design: 1) My new view CDebugView would be derived from CRichEditView and would have two windows, a) edit window, b) icon window. 2) When a view is created, shrink the RichEditCtrl so that I can add a second window to the left of the control (in OnInitialUpdate). This window is where I would display the breakpoint and execution pointer icons. This would take care of the mouse point problems (although I would have to handle some mouse actions in the icon window for the RichEditCtrl). 3) Encapsulate the breakpoints within CDebugView. Questions: 1) Should I really be deriving from CRichEditView, or should I start with CView and build my own view? 2) Has anyone done this before? 3) Any suggestions? 4) Does anyone want the code when I'm done? I would appreciate any comments. Greg Lee glee@kollmorgen.com
Frank Clark -- Frank_Clark@msn.com Monday, February 10, 1997 Greg, I would recommend Source View from Tetradyne Software Inc. I've recently used it to replace the editor in the IDE for our System 390 development tools. Does what we want, simple implementation. Color coding and graphics in the margin are easy to implement. Because it is line centric, it is a simple matter to keep track of break points and such. Their address is www.Tetradyne.com. Frank Clark ---------- From: owner-mfc-l@majordomo.netcom.com on behalf of Greg Lee (ID) Sent: Friday, February 07, 1997 8:15 AM To: 'mfc-l@netcom.com' Subject: Editor/debugger design, looking for suggestions Environment: VC++ 4.0, Win95, MSDN I am writing an MDI editor/debugger which has many of your standard features (breakpoints, single stepping, etc), similar to the Quincy 96 application by Al Stevens in Dr. Dobb's Journal, using CRichEditView as the basis of my design. I am a long time C programmer, but this is my first C++ project and my first Windows programming project. Quite a way to cut my teeth! I have "subclassed" CRichEditView to add the capability of displaying breakpoints attached to a particular line of text. I have this working now, but I am not happy with the way I have done it. A quick description of how I am displaying the breakpoints now: 1) I set the left margin on the RichEditCtrl to allow enough room to display the breakpoint and execution markers. 2) Handle all (hopefully!) of the events which may cause a breakpoint to move and adjust the breakpoint's position correctly. 3) Install my own WindowProc to handle the WM_PAINT and WM_HSCROLL events in which breakpoints have to be displayed. The main problem with this method is that I am displaying the breakpoints in the RichEditCtrl's client area. Luckily the control does not paint over this area, but the mouse pointer is still sensitive to this area. So, highlighting is a little screwed up (the highlight-whole-line mouse icon does not appear until I mouse over to the LEFT of the breakpoints). Additionally, I need to manage the breakpoints a little better (right now they are a global list). I am considering a better/different design: 1) My new view CDebugView would be derived from CRichEditView and would have two windows, a) edit window, b) icon window. 2) When a view is created, shrink the RichEditCtrl so that I can add a second window to the left of the control (in OnInitialUpdate). This window is where I would display the breakpoint and execution pointer icons. This would take care of the mouse point problems (although I would have to handle some mouse actions in the icon window for the RichEditCtrl). 3) Encapsulate the breakpoints within CDebugView. Questions: 1) Should I really be deriving from CRichEditView, or should I start with CView and build my own view? 2) Has anyone done this before? 3) Any suggestions? 4) Does anyone want the code when I'm done? I would appreciate any comments. Greg Lee glee@kollmorgen.com
Become an MFC-L member | Вернуться в корень Архива |