CEdit
in [MFC]
|
From: vvf on 19 Apr 2010 15:49 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:c56ps514lekogv5375ip35imbbr544s8cn(a)4ax.com... > Ah, then I would have expected the question to ask about the scrollbars, > not about > "buttons", which are a separate control. > > And, I believe that the answer is "You cannot do anything about this" (the > alternate > answer is "you will have to handle the OnNcPaint event and paint the > non-client area for > yourself) but that is not something most expienced WIndows programmers > would choose to > undertake, let alone a novice. Thanks for your answer. I just wasn't sure if going the OnNcPaint route for a CEdit would be something feasible knowing that CEdit kind of "fights" against custom drawing. > There is another answer: create a separate scrollbar control and use it. > This is the > solution usually proposed in kiosk situations where a large touchable area > is required. I think this would be a good compromise. > > But the question was ill-formed, and was asking a detail of how to > implement something, > instead of asking how to solve a problem, e.g., "I have a touch-screen > situation and I > need to make large touchable scrollbars, what is the best recommendation > for how to do > this for an edit control?" Sorry for not stating clearly what the purpose of my question really was. Here is an explanation: I am developing an application that uses my own custom controls (buttons, comboboxes, listboxes, and so on.) I do my own text drawing ( I have my own DrawText function because I use actual png's for each letter because I wanted to design a font that would contain shadows so that I could alpha-blend the letter nicely on the background, etc. I know, not terribly flexible, but good enough for my needs and it looks really really good). My DrawText function takes a rectangle and renders a text in it. It supports text alignment (vertical,center,etc), multi-line, etc. The only problem is that it doesn't support "text scrolling" in either direction (horizonta/vertical). Therefore, I found myself in the situation of having to develop my own CEdit-like control. I got pretty far: my edit control behaves as a CEdit except that I didn't implement block selection and it does not have a scroll bar yet. Furthermore, I still have to fix a few bugs relating to caret positioning. Unfortunately, I never expected to write a CEdit-like control that would have to support more than a "page" of text (page being defined by the height of the control). Therefore, I designed my initial code with this limitation in mind. Now, when I continued the development to support other pages of text as well, I realized that my design wasn't quite right (instead of having concepts such as rows, columns, etc) I just had images rendered on the screen (representing letters). Therefore, all the cursor positioning (via keyboard or mouse) was done at pixel level. I would check where the user clicked in terms of x and y coordinates, I would find what row of text is associated with the particular y coordinate, I would iterate through the text adding the widths of each letter to determine after what letter the caret should be positioned and so on. Basically, a wrong design that got to be a headache after adding scrolling and so on. Now, I realized that it would be much easier to just use the CEdit because I don't want to spend too much time on this (sure, I will continue to develop my own CEdit-like control, but that will take quite a while) so for now, I wanted a compromise: I wanted to somehow customize the drawing of the scrollbar and buttons but didn't read much about this because I remembered that CEdit is not really designed to allow you to do too much customization of its drawing. Thanks for your suggestion. __________ Information from ESET NOD32 Antivirus, version of virus signature database 5036 (20100417) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
From: Joseph M. Newcomer on 19 Apr 2010 23:49 See below... On Mon, 19 Apr 2010 22:49:49 +0300, "vvf" <vvf(a)vvf.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:c56ps514lekogv5375ip35imbbr544s8cn(a)4ax.com... >> Ah, then I would have expected the question to ask about the scrollbars, >> not about >> "buttons", which are a separate control. >> >> And, I believe that the answer is "You cannot do anything about this" (the >> alternate >> answer is "you will have to handle the OnNcPaint event and paint the >> non-client area for >> yourself) but that is not something most expienced WIndows programmers >> would choose to >> undertake, let alone a novice. > >Thanks for your answer. I just wasn't sure if going the OnNcPaint route for >a CEdit would be something feasible knowing that CEdit kind of "fights" >against custom drawing. *** It really does fight you. I have no idea if OnNcPaint is going to be sufficient in this case. Also, that only handles the drawing; you have to handle OnNcLButtonDown to handle the mouse clicks. It just begins to be a nightmare at that point **** > >> There is another answer: create a separate scrollbar control and use it. >> This is the >> solution usually proposed in kiosk situations where a large touchable area >> is required. > >I think this would be a good compromise. **** Given the horrors on OnNcPaint, that's the first approach I'd try *** > >> >> But the question was ill-formed, and was asking a detail of how to >> implement something, >> instead of asking how to solve a problem, e.g., "I have a touch-screen >> situation and I >> need to make large touchable scrollbars, what is the best recommendation >> for how to do >> this for an edit control?" > >Sorry for not stating clearly what the purpose of my question really was. >Here is an explanation: I am developing an application that uses my own >custom controls (buttons, comboboxes, listboxes, >and so on.) I do my own text drawing ( I have my own DrawText function >because I use actual png's for each letter because I wanted to design a font >that would contain shadows so that I could alpha-blend the letter nicely on >the background, etc. I know, not terribly flexible, but good enough for my >needs and it looks really really good). **** There is a point where artistic cuteness and cost of development don't mix, and you are well beyond that point here. Cost-effective solutions do not fit well with the idea of bitmap graphics characters (have you really looked at the subtleties that ClearText uses to draw readable characters?) And you would NOT use a CEdit for this under any conditions imaginable. You start with CWnd and do EVERYTHING, including figuring out how to manipulate the caret for internerational fonts! Not really a fun activity under the best of conditions. As someone who has to produce cost-effective solutions for my customers, I tend to avoid things like this. It costs far more than can be justified!. ***** >My DrawText function takes a >rectangle and renders a text in it. It supports text alignment >(vertical,center,etc), multi-line, etc. The only problem is that it doesn't >support "text scrolling" in either direction (horizonta/vertical). >Therefore, I found myself in the situation of having to develop my own >CEdit-like control. I got pretty far: my edit control behaves as a CEdit >except that I didn't implement block selection *** You would be surprised how difficult this is to get right! **** > and it does not have a scroll >bar yet. Furthermore, I still have to fix a few bugs relating to caret >positioning. Unfortunately, I never expected to write a CEdit-like control >that would have to support more than a "page" of text (page being defined by >the height of the control). Therefore, I designed my initial code with this >limitation in mind. Now, when I continued the development to support other >pages of text as well, I realized that my design wasn't quite right (instead >of having concepts such as rows, columns, etc) I just had images rendered on >the screen (representing letters). Therefore, all the cursor positioning >(via keyboard or mouse) was done at pixel level. **** It turns out that this is exactly the level you have to work at. And doing with a variable-pitch font is a realy nightmare! **** > I would check where the >user clicked in terms of x and y coordinates, I would find what row of text >is associated with the particular y coordinate, I would iterate through the >text adding the widths of each letter to determine after what letter the >caret should be positioned and so on. Basically, a wrong design that got to >be a headache after adding scrolling and so on. Now, I realized that it >would be much easier to just use the CEdit because I don't want to spend too >much time on this (sure, I will continue to develop my own CEdit-like >control, but that will take quite a while) so for now, I wanted a >compromise: I wanted to somehow customize the drawing of the scrollbar and >buttons but didn't read much about this because I remembered that CEdit is >not really designed to allow you to do too much customization of its >drawing. *** Look into Rich Edit Control as a start (that's where I would start) and I'd look at what I could do to position text without scrollbars to see if I had the kind of control I'd need to implement an external scrollbar. If my experiments were successful, then I'd take the next step of creating either a large scrollbar control or building my own custom control (starting with CWnd) for a scrollbar. But you are in Very Complex Territory here, and working well beyond the design bounds of most controls. This is the kind of place that experienced programmers really try to avoid going (something about Where Experts Fear To Tread comes to mind here...) If you have infinite time and/or no budget limitations, feel free, but if I had a customer come to me and ask for this, my response would be "This is going to be very expensive to develop; are you REALLY sure you want this?" and I'd allow weeks in the schedule just to get the basic control right! joe **** > >Thanks for your suggestion. > > > >__________ Information from ESET NOD32 Antivirus, version of virus signature database 5036 (20100417) __________ > >The message was checked by ESET NOD32 Antivirus. > >http://www.eset.com > > > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: vvf on 20 Apr 2010 02:17 >>Thanks for your answer. I just wasn't sure if going the OnNcPaint route >>for >>a CEdit would be something feasible knowing that CEdit kind of "fights" >>against custom drawing. > *** > It really does fight you. I have no idea if OnNcPaint is going to be > sufficient in this > case. Also, that only handles the drawing; you have to handle > OnNcLButtonDown to handle > the mouse clicks. It just begins to be a nightmare at that point > **** Indeed, I think I would be better off just continuing work on my CWnd derived control instead of starting to experiment with situations like this. >>CEdit-like control. I got pretty far: my edit control behaves as a CEdit >>except that I didn't implement block selection > *** > You would be surprised how difficult this is to get right! > **** You are right, I am at a point where I am thinking that at least for now, I have to drop block selection altogether otherwise I'll end up working on this edit field forever. I would like to mention though that my intent wasn't to develop a general purpose CEdit-like control. The control that I am working on will only be used by me in my application. Therefore, it would only work with my own fonts which take the naive approach of just having all the symbols I need defined as PNG files. > **** > It turns out that this is exactly the level you have to work at. And > doing with a > variable-pitch font is a realy nightmare! > **** The thing is that I would only handle my own fonts that sure, have variable letter widths but fixed pitch (I guess they are called 'proportional fonts'.) > *** > Look into Rich Edit Control as a start (that's where I would start) and > I'd look at what I > could do to position text without scrollbars to see if I had the kind of > control I'd need > to implement an external scrollbar. If my experiments were successful, > then I'd take the > next step of creating either a large scrollbar control or building my own > custom control > (starting with CWnd) for a scrollbar. But you are in Very Complex > Territory here, and > working well beyond the design bounds of most controls. This is the kind > of place that > experienced programmers really try to avoid going (something about Where > Experts Fear To > Tread comes to mind here...) It is really frustrating that, at least for my purposes, I have most functionality implemented. This is what I have accomplished so far: 1) If all the text entered fits within one page (page being defined as the height of the control) then everything works correctly: caret positioning (both via keyboard and mouse), muliline-editing, alignment and so on. 2) If, as you type, the current text line needs to go to another page, everything works correctly. The control scrolls down vertically one row, makes room for another line, you can continue typing and/or return to a previous paragraph via scrolling back (vertically), insert/edit text and so on. However, at this point, the caret positioning (for the new page) doesn't work anymore because now I have to play w/ offsets in my arrays (to compensate for the row detected ON SCREEN as opposed to the actual row in my string buffer and so on.) This is the point where I am at now. However, as I mentioned before, I have no support for block selection and horizontal scrolling. Now, I am afraid that if I continue down this path, even when I'll be done with everything my users will probably expect to be able to select a block of text and delete it/cut-it/paste something and so on. I really need to make sure that my users wouldn't get annoyed by a control that they feel should work a certain way but in reality it does something "almost the same". Therefore, instead of frustrating my users this way, I thought of a compromise of using CEdit but at least attempt to customize it. As such, your idea of a control hosting scroll buttons and scroll bars seems the way to go. BTW, I hope that the CEdit control accepts scrolling messages even though scrolling is disabled. > If you have infinite time and/or no budget limitations, feel free, but if > I had a customer > come to me and ask for this, my response would be "This is going to be > very expensive to > develop; are you REALLY sure you want this?" and I'd allow weeks in the > schedule just to > get the basic control right! At least I know that I wasn't doing something wrong. As I was working on this control, I just couldn't believe all the complexity that I was running into. It seemed that I would fix one thing and then something else wouldn't work and so I just wasn't sure if it made sense to continue this way or not. After all, my intent is to complete my application not to develop UI controls. I then realized that I wasn't just developing a UI control but rather a fully fledged text editor. I started looking into design patterns for this and consulted the GoF - Design Patterns example for their Lexi word processor and consider things such as maintaing the document's physical structure (arrangements of text/graphics into lines), generating the visual representation of the internal structure, mapping positions of the display to internal structure elements and so on. Instead, since I didn't expect to having to write a scrollable edit field, my implementation relied on a CString to hold the text, an array of "break positions" that indicate where the lines of text break off and a caret positioning function that determined what CString index corresponded to the pixel location clicked by the user. After that, I basically thought that all I had to do was keep a "start / end" offset and use that offset for array-lookups and that somehow it will all work this way. In theory, sure, all sounds nice and well but in practice I hit a lof ot special case situations that took quite a while to sort out. In the end, I am close to what I wanted, but that just isn't enough and as I mentioned before, even my final result which excludes block selection may frustrate the user for lacking this feature and that is the last thing I would want to do. vvf __________ Information from ESET NOD32 Antivirus, version of virus signature database 5036 (20100417) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
From: Joseph M. Newcomer on 20 Apr 2010 11:28 See below... On Tue, 20 Apr 2010 09:17:39 +0300, "vvf" <vvf(a)vvf.com> wrote: > >>>Thanks for your answer. I just wasn't sure if going the OnNcPaint route >>>for >>>a CEdit would be something feasible knowing that CEdit kind of "fights" >>>against custom drawing. >> *** >> It really does fight you. I have no idea if OnNcPaint is going to be >> sufficient in this >> case. Also, that only handles the drawing; you have to handle >> OnNcLButtonDown to handle >> the mouse clicks. It just begins to be a nightmare at that point >> **** > >Indeed, I think I would be better off just continuing work on my CWnd >derived control instead of starting to experiment with situations like this. > >>>CEdit-like control. I got pretty far: my edit control behaves as a CEdit >>>except that I didn't implement block selection >> *** >> You would be surprised how difficult this is to get right! >> **** > >You are right, I am at a point where I am thinking that at least for now, I >have to drop block selection altogether otherwise I'll end up working on >this edit field forever. I would like to mention though >that my intent wasn't to develop a general purpose CEdit-like control. The >control that I am working on will only be used by me in my application. >Therefore, it would only work with my own fonts >which take the naive approach of just having all the symbols I need defined >as PNG files. **** With fixed-pitch fonts, we used to assign this project to students in the intro-to-Windows-programming course after only a couple days of training. With variable-pitch fonts it is a nightmare. But the fixed-pitch is REALLY easy to do! InvalidateRect() the highlighted area, and then when you redraw the text in that area, and XOR a black rectangle on top of it! WIth fixed-pitch fonts, the calculations are really easy! joe **** > >> **** >> It turns out that this is exactly the level you have to work at. And >> doing with a >> variable-pitch font is a realy nightmare! >> **** > >The thing is that I would only handle my own fonts that sure, have variable >letter widths but fixed pitch (I guess they are called 'proportional >fonts'.) **** No, if the letter widths vary, it is a variable-pitch font (the "pitch" of the font is the number of letters per inch, and if that is constant independent of the letter choice, it is fixed pitch; otherwise it is variable-pitch) **** > >> *** >> Look into Rich Edit Control as a start (that's where I would start) and >> I'd look at what I >> could do to position text without scrollbars to see if I had the kind of >> control I'd need >> to implement an external scrollbar. If my experiments were successful, >> then I'd take the >> next step of creating either a large scrollbar control or building my own >> custom control >> (starting with CWnd) for a scrollbar. But you are in Very Complex >> Territory here, and >> working well beyond the design bounds of most controls. This is the kind >> of place that >> experienced programmers really try to avoid going (something about Where >> Experts Fear To >> Tread comes to mind here...) > >It is really frustrating that, at least for my purposes, I have most >functionality implemented. This is what I have accomplished so far: > >1) If all the text entered fits within one page (page being defined as the >height of the control) then everything works correctly: caret positioning >(both via keyboard and mouse), muliline-editing, alignment and so on. **** It is easy to do this even if you add scrolling. You work in relative coordinates, and SetWindowOrg to do the scrolling. You can draw above the area of the window and the window clips it (if it doesn't, you need to SetClipRgn, which is trivial). And you need to take the offset into account when converting mouse coordinates to logical coordinates. It's just arithmetic. **** > >2) If, as you type, the current text line needs to go to another page, >everything works correctly. The control scrolls down vertically one row, >makes room for another line, you can continue typing and/or return to a >previous paragraph via scrolling back (vertically), insert/edit text and so >on. However, at this point, the caret positioning (for the new page) doesn't >work anymore because now I have to play w/ offsets in my arrays (to >compensate for the row detected ON SCREEN as opposed to the actual row in my >string buffer and so on.) **** But that's just trivial arithmetic! Since you know what you set for the window origin, you just add that value in, or subtract it (depending on what computation you are doing!) **** > >This is the point where I am at now. However, as I mentioned before, I have >no support for block selection and horizontal scrolling. Now, I am afraid >that if I continue down this path, even when I'll be done with everything my >users will probably expect to be able to select a block of text and delete >it/cut-it/paste something and so on. I really need to make sure that my >users wouldn't get annoyed by a control that they feel should work a certain >way but in reality it does something "almost the same". Therefore, instead >of frustrating my users this way, I thought of a compromise of using CEdit >but at least attempt to customize it. As such, your idea of a control >hosting scroll buttons and scroll bars seems the way to go. BTW, I hope that >the CEdit control accepts scrolling messages even though scrolling is >disabled. **** Horizontal scrolling is just SetWindowOrg, same as for vertical, except you make the x-dimension be other than 0. Let GDI do the clipping for you! **** > >> If you have infinite time and/or no budget limitations, feel free, but if >> I had a customer >> come to me and ask for this, my response would be "This is going to be >> very expensive to >> develop; are you REALLY sure you want this?" and I'd allow weeks in the >> schedule just to >> get the basic control right! > >At least I know that I wasn't doing something wrong. As I was working on >this control, I just couldn't believe all the complexity that I was running >into. It seemed that I would fix one thing and then something else wouldn't >work and so I just wasn't sure if it made sense to continue this way or not. >After all, my intent is to complete my application not to develop UI >controls. **** It's tedious, but doable; as I said, we assigned this task to beginners with only three days of training, providing you are using a fixed-pitch font. Variable-pitch just adds horrid tedious calculations to the coordinate positions. But yes, developing CEdit for variable-pitch is a LOT of work, more than can be rationally expended or even justified on almost any project, product or personal. ***** > >I then realized that I wasn't just developing a UI control but rather a >fully fledged text editor. I started looking into design patterns for this >and consulted the GoF - Design Patterns example for their Lexi word >processor and consider things such as maintaing the document's physical >structure (arrangements of text/graphics into lines), generating the visual >representation of the internal structure, mapping positions of the display >to internal structure elements and so on. Instead, since I didn't expect to >having to write a scrollable edit field, my implementation relied on a >CString to hold the text, an array of "break positions" that indicate where >the lines of text break off and a caret positioning function that determined >what CString index corresponded to the pixel location clicked by the user. >After that, I basically thought that all I had to do was keep a "start / >end" offset and use that offset for array-lookups and that somehow it will >all work this way. In theory, sure, all sounds nice and well but in practice >I hit a lof ot special case situations that took quite a while to sort out. >In the end, I am close to what I wanted, but that just isn't enough and as I >mentioned before, even my final result which excludes block selection may >frustrate the user for lacking this feature and that is the last thing I >would want to do. **** Actually, you sound like you have the basics under control. The rest is just arithmetic. And remember: GDI does clipping for you! That's important, because it means you don't have to do any on your own! (Tyically, you compute line breaks on-the-fly, and line wrap does add a lot of weird cases!) joe **** > >vvf > > > >__________ Information from ESET NOD32 Antivirus, version of virus signature database 5036 (20100417) __________ > >The message was checked by ESET NOD32 Antivirus. > >http://www.eset.com > > > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: vvf on 22 Apr 2010 07:17
> **** > No, if the letter widths vary, it is a variable-pitch font (the "pitch" of > the font is the > number of letters per inch, and if that is constant independent of the > letter choice, it > is fixed pitch; otherwise it is variable-pitch) > **** I see. Thanks for that clarification. I am using a variable-pitch font then. > **** > Horizontal scrolling is just SetWindowOrg, same as for vertical, except > you make the > x-dimension be other than 0. Let GDI do the clipping for you! > **** Thanks for this insight. I was actually doing the clipping myself. > **** > It's tedious, but doable; as I said, we assigned this task to beginners > with only three > days of training, providing you are using a fixed-pitch font. > Variable-pitch just adds > horrid tedious calculations to the coordinate positions. > > But yes, developing CEdit for variable-pitch is a LOT of work, more than > can be rationally > expended or even justified on almost any project, product or personal. > ***** I think I will continue work on this control AFTER I release my product. Meanwhile, I'll use your suggestion of having a separate control hosting scrolling bar/buttons and work with the standard CEdit. After all, this control will only be displayed in one of my application's screens! Thanks for all your suggestions and for your time! __________ Information from ESET Smart Security, version of virus signature database 3948 (20090319) __________ The message was checked by ESET Smart Security. http://www.eset.com |