1. RichEdit/xControls issues
Hi!
I did not stop rewriting a Syntax2.ew syntax control with bookmarks and text
folding, but I'm hitting a wall erected by Windows.
Because some text in the file shouldn't be displayed, as it relates to the
above features, I can't call the default processing for painting, as in the
current Syntax. This works, including painting the selected and [un]folded
areas.
The problem is that the RichEdit control, when responding to navigation keys,
displays the caret according to some internal info that is not updated when
changing font. Creating the caret with the right dimensions on w32HActivate or
w32HPaint doesn't help. Thus, for instance, the caret moves by 9 pixels up and
down even though the font size was set to 18 (characters entered display with
the right font however). Looks like this aspect remains stuck to default
parameters if the default painting is not used.
As I'm writing this post, I realize that calling the default processing to
paint on font change, then clear window and redraw my way might work, I have
to test this.
There are several options out, so I'm asking the (future) users of Syntax here:
1/ Use the CFM_HIDDEN attribute to hide unwanted text. That may be a bit slow,
and won't work with RichEdit v2.0 or less, which could be an issue on Win95/98
systems.
2/ Create a new control on font change, and route events so that win32lib
still believes the original id is alive. Drawback is that the undo stack is
lost in the process.
3/ Create the control from scratch, handling everything from selection to
undoing and stuff. This has some good aspects, as the RichEdit interface has
some backward compatible quirks I can get rid of. I started going that route,
but obviously it's a tremendous amount of work, so that the release date would
be quite later than expected.
None of the above is needed if the trick I mentioned works as expected, but
there's hardly any guarantee it does.
Whichever option is taken, the new control would have to include xControls.e
so as to register as a custom control. This approach would work for all of the
xControls collection, allowing them to be used independently; this change
avoids loading heaps of unused code, which is a factor in Eu2.5 (even though
the beta version improved things a lot).
win32lib does have an undocumented mechanism for registering custom controls,
but some of its routines are not coded to support custom controls known by
interface only. The days it fully works, Syntax2.ew can live without
xControls.e.
What do you think? Greg (or Don), you have a special vote to cast on this, of
course ...
CChris
2. Re: RichEdit/xControls issues
> 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'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. I just need him to start documenting it. I
can only get so far be examining code.
~Greg
3. Re: RichEdit/xControls issues
- Posted by Derek Parnell <ddparnell at bigpond.com>
Jan 26, 2005
-
Last edited Jan 27, 2005
Greg Haberek wrote:
[snip]
>It will really flex
> Derek's new control system. I just need him to start documenting it. I
> can only get so far be examining code.
I've just returned from a very long vacation (think 'sun and surfing') and
I'm refreshed and anxious to restart the win32lib upgrade.
The new control system has already been upgraded from that presented in
v0.60.6, and I am documenting it too! 
--
Derek Parnell
Melbourne, Australia
4. Re: RichEdit/xControls issues
- Posted by cklester <cklester at yahoo.com>
Jan 26, 2005
-
Last edited Jan 27, 2005
Derek Parnell wrote:
>
> I've just returned from a very long vacation (think 'sun and surfing') and
> I'm refreshed and anxious to restart the win32lib upgrade.
Excellent for you, Derek! I hope you got pics that you can share. :)
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
5. Re: RichEdit/xControls issues
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
>
>
