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
| Вернуться в корень Архива
|