Re: RichEdit/xControls issues
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Jan 27, 2005
- 591 views
Greg Haberek wrote: > > > What do you think? Greg (or Don), you have a special vote to cast on this, > > of > > course ... > > I think that in order to achieve the results you want, you may end up > needing to completely re-write the control. RichEdit was never > designed for what you want it to do. The good news is, that several > people have already written custom syntax controls. Don himself has > written three - Syntax, Syntax2 and Nexus. I believe only the original > Syntax relies on external code (RichEdit). Then there's MEditor, which > even uses its own custom caret, plus many others. > I'll try the fix I just had occurred to me tomorrow. If it doesn't work, then the fully rewritten thing is the only way to go for all systems to benefit from the control. If anybody had RichEdit 3.0 or more, I wouldn't have to do this. > I've been spending a bit of time looking into Win32Lib custom control > routines. I believe this is how I'm going to handle xControls from now > on. Basically, registerXcontrol() will still be valid, except it will > return a Win32Lib control id that will work with create() and/or > xControl() (for backward compatibility, I guess). It will really flex > Derek's new control system. A couple days ago, I sent Derek a list of the routines that wouldn't handle custom control correctly if left unmodified. The problem is that some code examines the exact class of a control, instead of using its ctrl_Family[]. Custom edit controls would be more affected, along with custol LV and TV. For instance, setFont() sends EM_CHARFORMAT to RichEdit controls only, so that the Syntax2 wouldn't get this message it needs. I had started mod'ing syntax2 so as to take advantage of the system, but packpedaled due to this. Distributing a modified win32lib.ew could be an option if the next release is really long in coming. > I just need him to start documenting it. I > can only get so far be examining code. Well, it's undocumented because the library is not ready yet. The mechanism for adding custom classes works correctly though. CChris > ~Greg > >