Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

RichEdit Version 3.0 FindText

110 views
Skip to first unread message

Iain Macmillan

unread,
Jun 14, 2002, 5:09:42 PM6/14/02
to

I have a RichEdit version 3; calls to FindText (and FindTextEx WinAPI) act
quite differently from a version 1 TRichedit.

Suppose the text contains numerous instances of 'a'
Rich.FindText('a',0,$FFFFFF,[]);
returns -1 !!
but
Rich.FindText('a',$FFFFFF,$FFFFFF,[]);
returns the position of the last 'a' in the text !!!!!

i.e. it is finding the 1st instance prior to the requested starting
position, not the first one after it.

This is most inconvenient, does anyone (Hello Roger?) know how to make it
look forwards?

-Iain.

Roger Morton

unread,
Jun 15, 2002, 4:54:24 AM6/15/02
to

Iain

The Delphi TRichEdit.FindText results in an EM_FindText being sent to
the underlying MS Version 1 control, with a whole bunch of search
option flags set.

If you've got something else that wraps Version 3, then it's FindText
is presumably doing something not necessarily identical. Maybe worth
comparing what goes on inside the two FindText methods?

If you've simply inherited the Delphi code, then one thing the MSDN
Help says you will certainly need to set is the FR_Down flag - it's
ignored in Version 1 (which always searches down), but needs to be set
in Version 2 onwards if you want to avoid searching upward....

Roger Morton
ro...@chez-morton.com

Iain Macmillan

unread,
Jun 17, 2002, 10:43:07 AM6/17/02
to

In article <e3UJwYA4EdanCADA8DhvxA@LIVING>, ro...@xnospamxchez-morton.com
(Roger Morton) wrote:


> The Delphi TRichEdit.FindText results in an EM_FindText being sent to
> the underlying MS Version 1 control, with a whole bunch of search
> option flags set.

I see only 2 flags, MatchCase and WholeWord.

> If you've simply inherited the Delphi code,

I inherited from TRichedit, so the call to FindText wrapped EM_FindText.
When I found it wasn't giving the results I wanted, I added a method to my
v3 class that wrapped EM_FindTextEx but still no joy.
Then I wrote my kludgy slow FindTextForward method so I could at least get
on with some work.

> then one thing the MSDN
> Help says you will certainly need to set is the FR_Down flag -

AHA!! Do you know the numerical value of FR_Down? I'll have to declare this
const myself.


> it's
> ignored in Version 1 (which always searches down), but needs to be set
> in Version 2 onwards if you want to avoid searching upward....

Well of course I want to avoid searching upwards, how many times in practise
does one want to do this compared with searching down? Have MS never heard
of using sensible default values? Or considered backward reuse of ver 1
code?..
<fume><rant>

Thanks very much, Roger.

regards
-Iain

Roger Morton

unread,
Jun 17, 2002, 2:48:35 PM6/17/02
to
In <3d0df854_2@dnews>, Iain Macmillan wrote:


> I see only 2 flags, MatchCase and WholeWord.
>

Well, more than one then :-)

> AHA!! Do you know the numerical value of FR_Down? I'll have to
> declare this
> const myself.
>

I think I do. The machine on which I have the Platform SDK is
currently hors de combat; but peeking at RxRichEdit, it declares
something called FT_Down as being..... 1. Try it.

> Have MS never
> heard
> of using sensible default values?

I couldn't possibly comment :-)

Roger Morton
ro...@chez-morton.com


Iain Macmillan

unread,
Jun 17, 2002, 3:10:10 PM6/17/02
to

In article <z48DgYInEdanCADA8DhvxA@LIVING>, ro...@xnospamxchez-morton.com
(Roger Morton) wrote:

>
> I think I do. The machine on which I have the Platform SDK is
> currently hors de combat; but peeking at RxRichEdit, it declares
> something called FT_Down as being..... 1. Try it.

Thanks Roger.

Roger Morton

unread,
Jun 18, 2002, 10:43:59 AM6/18/02
to

> >
> > I think I do. The machine on which I have the Platform SDK is
> > currently hors de combat; but peeking at RxRichEdit, it declares
> > something called FT_Down as being..... 1. Try it.
>

The machine has arisen; I now discover the damn thing (FR_Down) was
hiding in commdlg.h all the time, and you'll therefore find it declared
for you in Dialogs.pas.

Again, I couldn't possibly comment.....


Roger Morton
ro...@chez-morton.com

Iain Macmillan

unread,
Jun 18, 2002, 1:52:04 PM6/18/02
to

In article <PncKooLHEdaWmwDA8DgiHw@LOFT>, ro...@xnospamxchez-morton.com
(Roger Morton) wrote:


> The machine has arisen; I now discover the damn thing (FR_Down) was
> hiding in commdlg.h all the time, and you'll therefore find it declared
> for you in Dialogs.pas.

A reference to it in Dialogs.pas, the declaration is in commdlg.pas
(Source\RTL\Win)
Silly of me not to think of looking for it there! <G>
(Actually I could have found it by tracing out how FT/FR_ MatchCase got
their values..)

These seem to be slightly different animals, FR_Down, or rather its wrapper
FTDown is a possible set element of a TFindOption. But what we need here is
a TSearchType. (of course it makes sense that these are strongly related,
but you can't rely on what makes sense actually having been done.. I know,
you couldn't possibly comment ..)

So anyway I have overloaded FindText in the v3RichEdit class and replaced
flags:=0; by flags:=1;
This works. %-).

(Then I declared a property FindBackwards and made it
if FindBackwards flags:=0 else flags=1;
- just in case I need it)

Maybe safer to use FT_Down constant(?), but of course my RichEdit derivative
has no other reason currently to use Commdlg or Dialogs! A visual display
component has no business firing off dialog boxes, that is a job for its
parent form.. Yes, you couldn't comment <g> ..

Best regards
Iain.

Roger Morton

unread,
Jun 19, 2002, 5:00:59 AM6/19/02
to
In <3d0f7159_2@dnews>, Iain Macmillan wrote:

>
> A reference to it in Dialogs.pas, the declaration is in commdlg.pas
> (Source\RTL\Win)
> Silly of me not to think of looking for it there! <G>
> (Actually I could have found it by tracing out how FT/FR_ MatchCase
> got
> their values..)
>

Yeah, sorry

> These seem to be slightly different animals, FR_Down, or rather its
> wrapper
> FTDown is a possible set element of a TFindOption. But what we need
> here is
> a TSearchType. (of course it makes sense that these are strongly
> related,
> but you can't rely on what makes sense actually having been done.. I
> know,
> you couldn't possibly comment ..)
>

If you look at the ancient WinAPI Help that comes with Delphi, you'll
find the FindText dialog function is documented with FR_ flags, but
the EM_FindText message (for V1 of RichEdit) is kitted out with
FT_MatchCase and FT_WholeWord. Hence, I guess, Borland's
implementation of TFindOptions and TSearchTypes being different.

But the current MSDN Help for EM_FindText has ditched the FT_ flags and
replaced them with their equivalents from the FR_ set, and added a few
more exotic ones for good measure.

Those are the facts; ICPC... :-)

> So anyway I have overloaded FindText in the v3RichEdit class and
> replaced
> flags:=0; by flags:=1;
> This works. %-).
>

Excellent.

>
> Maybe safer to use FT_Down constant(?), but of course my RichEdit
> derivative
> has no other reason currently to use Commdlg or Dialogs!

You mean FR_Down? I wouldn't think it matters - I'd be very surprised
if MS ever tried to change it's value (as opposed to how they
name/document it) in a future V4.

Gosh, that was a comment. I must stop :-)


Roger Morton
ro...@chez-morton.com

Iain Macmillan

unread,
Jun 19, 2002, 3:38:04 PM6/19/02
to

In article <wYWf4YNfEdaWmwDA8DgiHw@LOFT>, ro...@xnospamxchez-morton.com
(Roger Morton) wrote:

> Yeah, sorry
No need, you already got a solution for me.
Much needed, as I have been asked to improve search facilities, and without
a working FindText this would have been difficult!

> You mean FR_Down?
Yes. I'm confusing myself now!

> I wouldn't think it matters - I'd be very surprised
> if MS ever tried to change it's value (as opposed to how they
> name/document it) in a future V4.

Yes, I did ponder this a bit. If it changed value, a new version (of Delphi
or any other compiler) that know about the new value would be needed.
Programs compiled with old compilers wouldn't work with the new DLL and vice
versa.
It would break so much that I don't think they could do it.

> Gosh, that was a comment. I must stop :-)

Go on, have a chat. <G>

0 new messages