Does #228 reproduce for anyone?

Our bugs system has a relatively elderly entry for D4 numbered 288 and
entitled: "Rich Text Edit control context menus may be opened up twice on
Windows ME and 98SE".

This was originally reported by Bill, and the associated text is:

-----------------
"Context menus appear not to close after making a selection; must click
outside to close." This is probably because the control is now responding to
a right click (as in Win2K) and therefore the code in
#wmRButtonUp:wParam:lParam: is duplicating the context menu. The version
check in there probably needs to be for a certain version of the rich edit
control, rather than just looking for Win2K. Need to test out on 98SE and
ME.
-----------------

I've tested this on an ME box, and it does not occur. I've checked MSDN and
according to that neither 98SE or ME should have the version of the rich
edit control installed that causes this problem (i.e. 3.0 emulating 1.0).
Only 2k and XP should have it.

As a bit of background, Dolphin includes a workaround for a problem in the
original RichEdit controls, in that they did not transmit WM_CONTEXTMENU
events. Therefore we added a workaround and issued them ourselves. Later
when 2K appeared the RichEdit 3.0 emulation on their did not emulate the
original bug, and so we had to add a version check. The version check is
based on the host OS, because there does not seem to be a reliable way to
determine whether one is connected to the original 1.0 RichEdit, or the 3.0
emulation of it.

Therefore I would be interested to know if Win98SE and ME users experience
this problem (if you did I expect you would have noticed by now!), and if so
what are the version numbers of the RichEd*.dll's on your machine.

If there is no response, I'm going to close this one off as it has been in
the system since May 2001 with no further reports.

Thanks

Blair

Hi Blair,

> Our bugs system has a relatively elderly entry for D4 numbered 288 and
> entitled: "Rich Text Edit control context menus may be opened up twice on
> Windows ME and 98SE".

I'm not sure I ever said anything about 98SE, and I _think_ that I have a
counter-example to that.  I'll have to check my K6-2/650 at home, but, I
think it's running SE and is happy.


> This was originally reported by Bill, and the associated text is:
>
> -----------------
> "Context menus appear not to close after making a selection; must click
> outside to close." This is probably because the control is now responding
to
> a right click (as in Win2K) and therefore the code in
> #wmRButtonUp:wParam:lParam: is duplicating the context menu. The version
> check in there probably needs to be for a certain version of the rich edit
> control, rather than just looking for Win2K. Need to test out on 98SE and
> ME.
> -----------------
>
> I've tested this on an ME box, and it does not occur.

I just repeated it on an ME box, and got the same results as before with D4
and with D5.


> Therefore I would be interested to know if Win98SE and ME users experience
> this problem (if you did I expect you would have noticed by now!), and if
so
> what are the version numbers of the RichEd*.dll's on your machine.


riched.dll  - 4.0.834.839
riched20.dll - 5.30.23.1203
riched32.dll - 5.0.1934.1
richtxt32.ocx - 6.0.81.69

Have a good one,

Bill

---
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> ...
> > Our bugs system has a relatively elderly entry for D4 numbered 288 and
> > entitled: "Rich Text Edit control context menus may be opened up twice
on
> > Windows ME and 98SE".
>
> I'm not sure I ever said anything about 98SE, and I _think_ that I have a
> counter-example to that.  I'll have to check my K6-2/650 at home, but, I
> think it's running SE and is happy.
> ....
> I just repeated it on an ME box, and got the same results as before with
D4
> and with D5.
>
> > Therefore I would be interested to know if Win98SE and ME users
experience
> > this problem (if you did I expect you would have noticed by now!), and
if
> so
> > what are the version numbers of the RichEd*.dll's on your machine.
>
>
> riched.dll  - 4.0.834.839
> riched20.dll - 5.30.23.1203
> riched32.dll - 5.0.1934.1
> richtxt32.ocx - 6.0.81.69

OK. I think then that the only solution to this is to move up to
RichEd20.dll (i.e. off the version 1.0 version of the control and onto
version 2.0 control), because there does not seem to be a clear way to
determine from all the myriad version numbers whether it is a 3.0 control
emulating version 1.0, or really version 1.0. There is no documentation on
which version numbers of the RichEd??.dll's are what, so I'm worried that if
we test the version number of the control, that there will be further
problems.

Up to now we have been relying on a OS version test. From MSDN:

"The following list describes which versions of Rich Edit are included in
which releases Microsoft® Windows®.
  Windows XP
  Includes Rich Edit 3.0 with a Rich Edit 1.0 emulator.
  Windows Me
  Includes Rich Edit 1.0 and 3.0.
  Windows 2000
  Includes Rich Edit 3.0 with a Rich Edit 1.0 emulator.
  Windows NT 4.0
  Includes Rich Edit 1.0 and 2.0.
  Windows 98
  Includes Rich Edit 1.0 and 2.0.
  Windows 95
  Includes only Rich Edit 1.0. However, Riched20.dll is compatible with
Windows 95 and may be installed by an application that requires it. "
Unfortunately it appears that one cannot reliably tell just from the OS,
since it would seem that something Bill has installed on his ME machine has
upgraded his RichEdit 3.0 installation to be using the DLL from Win2K and
XP.  Either that or ME ships with a new version of 1.0 that "fixed" the
original bug.

The use of RichEdit20 will mean that it will not run on a plain vanilla
Windows 95 (original release), but (a) we are not officially supporting D5
on Windows 95, (b) most Win95 installations will have a later version of the
control by virtue of installing one or other piece of MS s/w, and (c)
"Riched20.dll is compatible with Windows 95 and may be installed by an
application that requires it.".

This does at least allow us to move on and use some of the enhanced
functionality in the newer control, such as multi-level undo and support for
the text object model. The multi-level undo, for instance, makes for a big
improvement as a code editor (he says having just tried it).

Regards

Blair

Blair,

> OK. I think then that the only solution to this is to move up to
> RichEd20.dll (i.e. off the version 1.0 version of the control and onto
> version 2.0 control), because there does not seem to be a clear way to
> determine from all the myriad version numbers whether it is a 3.0 control
> emulating version 1.0, or really version 1.0. There is no documentation on
> which version numbers of the RichEd??.dll's are what, so I'm worried that
if
> we test the version number of the control, that there will be further
> problems.

Seems reasonable to me.  One caution: I'm basing this solely on two of three
"identical" ME machines that were purchased roughly one year ago.  I've
tried D5 on only one of them, but, they've all had the problem with D4.
Maybe HP sent out some misconfigured machines????


> The use of RichEdit20 will mean that it will not run on a plain vanilla
> Windows 95 (original release), but (a) we are not officially supporting D5
> on Windows 95, (b) most Win95 installations will have a later version of
the
> control by virtue of installing one or other piece of MS s/w, and (c)
> "Riched20.dll is compatible with Windows 95 and may be installed by an
> application that requires it.".

One way to handle that would be to add an optional installation of the DLL
to your installer.  I say optional because I learned the hard way to do
that, having been blamed because one of my apps "broke" somebody's machine -
turns out that they were running some commerical gizmo that installs rogue
DLLs.  My installers have a "Microsoft libraries" checkbox that's off by
default, and I instruct users to try first with it off, and re-run with it
only if indicated.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hi Blair and Bill,

>
> Seems reasonable to me.  One caution: I'm basing this solely on two of
three
> "identical" ME machines that were purchased roughly one year ago.  I've
> tried D5 on only one of them, but, they've all had the problem with D4.
> Maybe HP sent out some misconfigured machines????
>
>

I've got a HP machine with ME at home (about a year old) and both D4 and D5
run without a problem. If  these menu problems would have been there I would
have nioticed them, as I use the context menu *loads*.

Haven't got access to that machine at the moment, but if you're interested
in the versions, I'll take a look over the weekend.

Ted

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > OK. I think then that the only solution to this is to move up to
> > RichEd20.dll (i.e. off the version 1.0 version of the control and onto
> > version 2.0 control), because there does not seem to be a clear way to
> > determine from all the myriad version numbers whether it is a 3.0
control
> > emulating version 1.0, or really version 1.0. There is no documentation
on
> > which version numbers of the RichEd??.dll's are what, so I'm worried
that
> if
> > we test the version number of the control, that there will be further
> > problems.
>
> Seems reasonable to me.  One caution: I'm basing this solely on two of
three
> "identical" ME machines that were purchased roughly one year ago.  I've
> tried D5 on only one of them, but, they've all had the problem with D4.
> Maybe HP sent out some misconfigured machines????

I wouldn't go that far. Maybe they just install some other s/w.

> > The use of RichEdit20 will mean that it will not run on a plain vanilla
> > Windows 95 (original release), but (a) we are not officially supporting
D5
> > on Windows 95, (b) most Win95 installations will have a later version of
> the
> > control by virtue of installing one or other piece of MS s/w, and (c)
> > "Riched20.dll is compatible with Windows 95 and may be installed by an
> > application that requires it.".
>
> One way to handle that would be to add an optional installation of the DLL
> to your installer.  I say optional because I learned the hard way to do
> that, having been blamed because one of my apps "broke" somebody's
machine -
> turns out that they were running some commerical gizmo that installs rogue
> DLLs.  My installers have a "Microsoft libraries" checkbox that's off by
> default, and I instruct users to try first with it off, and re-run with it
> only if indicated.

We won't be shipping RichEd20.dll with Dolphin 5.0 because we are not
supporting Windows 95.

BTW: It is very unlikely that a change to RichEd20.dll will occur in the
next beta because there is a significant incompatbility that soon becomes
apparent - the 1.0 control uses the standard windows CR/LF line end
sequence, whereas the 2.0 control uses only CR. This upsets various things
such as the compiler's text<->ip maps, which assume two characters have to
be counted for a line ending (the RE control counts the line end as a single
character for the purposes of selection, regardless of whether one has
actually stuffed two character line endings into it).

Regards

Blair

apart from riched32.dll my machine has got the same versions as Bill's

My riched32.dll has got version 5.0.1461.82, extra info: sp4, application:
ms-exchange

But I can't reproduce the error of context menus not closing.

hth

Ted