Board index » delphi » RichEdit not working on W2K

RichEdit not working on W2K

A user reports a problem when checking out my prog on W2K.

RTF (read by a TRichedit) which appears OK on the W95 computers comes out
as plain raw rich text (in a huge blue font!).
{\rtf1\deff0\deftab 720{\fonttbl{\f0\fswiss
..etc. not exactly as informative as it's meant to be!

the huge blue font is the font that should be used for the first proper text
indicating that the rtf header has been read and understood.

This is the top of one of the Rtf files.

Quote
> {\rtf1\ansi\deff0\deftab720{\fonttbl{\f0\fswiss MS Sans
> Serif;}{\f1\froman\fcharset2 Symbol;}{\f2\fswiss\fprq2
> Arial;}{\f3\froman\fprq2\fcharset2 Symbol;}}
> {\colortbl\red0\green0\blue0;\red0\green0\blue129;\red0\green129\blue129;\re
> d0\green128\blue0;\red0\green0\blue255;\red255\green255\blue255;}
> \deflang1033\pard\qc\plain\f2\fs64\cf1\b Occupational

                       .   . f2\fs64\cf1\b = big blue font.
Quote
> \par Pension
> \par Schemes
> \par Practice Notes
> \par \pard\qr\plain\f2\fs22\cf1\b IR12 (2001)

.. looks like good RTF yes?
it renders fine on my W95 computer, and on W98 and NT afaik.
Also on the target W2K computer in Word and Wordpad. But not in a W2K
TRichEdit.

Any suggestions anybody, on what to do about this?
Hasn't anybody else come across anything similar?

TIA Iain.

 

Re:RichEdit not working on W2K


Quote
"Iain & Sue" wrote...

> A user reports a problem when checking out my prog on W2K.

> RTF (read by a TRichedit) which appears OK on the W95 computers comes out
> as plain raw rich text (in a huge blue font!).
[snipped]
> Any suggestions anybody, on what to do about this?
> Hasn't anybody else come across anything similar?

I've seen more reports on unexpected behaviour of TRichedit
controls on different OS's. Don't know of W2K specific.

I'm currently playing around with TRichedit98 from
Alexander Obukhov. It is wrapper of Richedit version 2.0.
The first impression is that this one is more stable (and it also
adds some nice new features).

http://www.delphi32.com/vcl/472/

--
Pieter

Re:RichEdit not working on W2K


In article <3b50748a_2@dnews>, "Pieter Zijlstra" <pzijlstr...@freeler.nl>
wrote:

Quote
> I've seen more reports on unexpected behaviour of TRichedit
> controls on different OS's. Don't know of W2K specific.

I've come across something that could account for the behaviour I described
In ComCtrls.pas proc TRichEditStrings.LoadFromStream.

If a load of RTF results in dwError of non-zero it attempts to reload the
file as plain text from the previously saved stream position; only if this
second attempt fails does it give up and raise EOutOfResources.

So it could have got past the header and set the font to the one I
requested, before reloading the whole file as plain text. A similar effect
can be obtained by loading plain text into a richedit which previously
contained rich text - the plain text takes on the attributes which were at
the cursor before the reload.

So the question now becomes: why would a *stream* give an error on Win 2K
but not on W95? .. Surely not lack of resources, it is W95 that is notorious
for this!

Quote
> I'm currently playing around with TRichedit98 from
> Alexander Obukhov. It is wrapper of Richedit version 2.0.
> The first impression is that this one is more stable (and it also
> adds some nice new features).

Hmm, not too keen on introducing third-components.. I'm having enough
trouble getting Borland and MS stuff to cooperate.

Thanks for your input Pieter.

Re:RichEdit not working on W2K


Quote
"Iain & Sue" wrote...
> So the question now becomes: why would a *stream* give an error
> on Win 2K but not on W95? .. Surely not lack of resources, it is
> W95 that is notorious for this!

W2K uses richedit3 which can *emulate* richedit1,  this is the one
used by D5 (don't know which one D6 is using). Maybe this emulating
is not going as well as you might expect and is this the reason why it
functions correctly on 'original' richedit1 versions (read 95/98/NT)
and not on W2K.
I assume that Wordpad uses the latest richedit versions (>= 2.0).

Quote
> Hmm, not too keen on introducing third-components.. I'm having
> enough trouble getting Borland and MS stuff to cooperate.

One of the reasons I'm using it because in WinME there is somehow a
limitation of about 64-70KB on RTF files when using the standard D5
richedit. When using TRichEdit98 this limit is not there (I stopped testing
at 1MB).
One other nice side-effect is that it reports the correct caret position
when
the caret is moved to the end of a line within in paragraph (soft CR) by
using
the End-key.

--
Pieter

Re:RichEdit not working on W2K


In article <3b533df0_1@dnews>, "Pieter Zijlstra" <pzijlstr...@freeler.nl>
wrote:

Quote
> "Iain & Sue" wrote...
>> So the question now becomes: why would a *stream* give an error
>> on Win 2K but not on W95? .. Surely not lack of resources, it is
>> W95 that is notorious for this!

> W2K uses richedit3 which can *emulate* richedit1,  this is the one
> used by D5 (don't know which one D6 is using). Maybe this emulating
> is not going as well as you might expect

Blessed is he who expecteth nothing.
I'd like to expect backward compatibility.. but from MS its unlikely.
Quote
> and is this the reason why it
> functions correctly on 'original' richedit1 versions (read 95/98/NT)
> and not on W2K.
> I assume that Wordpad uses the latest richedit versions (>= 2.0).

My understanding was that different DLLs are used. Riched32 for version 1
and Riched20 for v2 (and perhaps >2). However the Delphi components at least
to v5 call only Riched32.DLL.
This means that they are not expected to be able to use features added
later. (However part of the RTF spec is 'if the reader doesn't understand
something it should ignore it'). I am not using later features anyway and
the first line in the RTF specifies that it is RTF1.

Quote
> One of the reasons I'm using it because in WinME there is somehow a
> limitation of about 64-70KB on RTF files when using the standard D5
> richedit.

Thanks Pieter, this is significant because my files are much larger than
this. It will be inconvenient if it turns out that it is just the filesize
that is causing the problem.  One reason I chose to use RTF in the first
place was that there were no real limits on the size.
Quote
> When using TRichEdit98 this limit is not there (I stopped testing
> at 1MB).

I've loaded files bigger than 1MB in W95. However in an internal processing
program I did find that I couldn't load a copy of the contents of one 1MB
Richedit into a second. Had to save the first to disk and clear it first.

regards Iain.

Re:RichEdit not working on W2K


Quote
"Iain & Sue" wrote...

> > One of the reasons I'm using it because in WinME there is somehow a
> > limitation of about 64-70KB on RTF files when using the standard D5
> > richedit.
> Thanks Pieter, this is significant because my files are much larger than
> this. It will be inconvenient if it turns out that it is just the filesize
> that is causing the problem.

I've found the reason for my problem. For loading text I'm using a
filestream
together with RichEdit1.Lines.LoadFromStream. When doing so I can't
type anything more text when it reaches about 70K in size.
When I use LoadFromFile (without the filestream) everything works Ok!
LoadFromFile has an extra line on the end which sets the MaxLength
to $7FFFFFFF0.
When I go back to my original situation (with LoadFromStream) and
also set MaxLength directly after loading from the stream now also this
functions properly.

<I assume you're also using LoadFromStream>
I've seen a post about Richedit vs W2K describing what looks like the
same strange RTF output you have. The post also implies that setting
MaxLength after loading solved the problem.
(posted on b.p.d.winapi by Ian Trackman subject RichEd32.dll)

HTH
--
Pieter

Re:RichEdit not working on W2K


In article <3b5741ac_1@dnews>, "Pieter Zijlstra" <pzijlstr...@freeler.nl>
wrote:

Quote
> I've found the reason for my problem. For loading text I'm using a
> filestream
> together with RichEdit1.Lines.LoadFromStream. When doing so I can't
> type anything more text when it reaches about 70K in size.
> When I use LoadFromFile (without the filestream) everything works Ok!
> LoadFromFile has an extra line on the end which sets the MaxLength
> to $7FFFFFFF0.

This looks a bit more than 70Kb already!
What do you reset it to?
I don't see this extra line in the source; I would expect it to cause a
second attempt to load to work even though perhaps it failed first time. My
site reports this not to be the case.
Doesn't *yours* work only second time around on LoadFromFile ?
Quote
> When I go back to my original situation (with LoadFromStream) and
> also set MaxLength directly after loading from the stream now also this
> functions properly.
> <I assume you're also using LoadFromStream>

No I'm using LoadFromFile.
But the VCL implements this method by setting up a filestream and calling
LoadFromStream. It is within LoadFromStream that I saw the call to reload as
plain text on error, so I don't really see how resetting MaxLength after
LoadFromFile completes can help....
Quote
> I've seen a post about Richedit vs W2K describing what looks like the
> same strange RTF output you have. The post also implies that setting
> MaxLength after loading solved the problem.

.. but it sounds worth a try.
Or setting it before the load maybe ?
I'll have to go out to the site that is having trouble though to test it.
Quote
> (posted on b.p.d.winapi by Ian Trackman subject RichEd32.dll)

I've been scanning there for 'Rich*' for some time. although this group
looks more on-topic.
Latest post tonight, RichEdit Out of resources looks like it is related.
Quote

> HTH

Indeed it does!
Last week I had very little idea about what to do about this (had even made
contingency plans to revive the plain text file reader in case I could not
fix it) but in the light of your comments I now have some worthwhile tests
that can be conducted on-site that look likely to yield a solution.

I have now had confirmation that shortening the file enables it to be
rendered (what is left of it). Which proves that either the length is the
problem or that there is some other error just beyond the point when the
file becomes unreadable.

Best regards
Iain.

Re:RichEdit not working on W2K


Quote
"Iain & Sue" wrote...
> > I've found the reason for my problem. For loading text I'm
> > using a filestream together with RichEdit1.Lines.LoadFromStream.
> > When doing so I can't type anything more text when it reaches
> > about 70K in size. When I use LoadFromFile (without the
> >  filestream) everything works Ok!
> > LoadFromFile has an extra line on the end which sets
> >  the MaxLength to $7FFFFFFF0.
> This looks a bit more than 70Kb already!
> What do you reset it to?

var
  FStatStream : TFileStream;
begin
  FStatStream := TFileStream.Create('c:\test.wri', fmOpenReadWrite or
fmShareDenyWrite);
  try
    if Assigned(FStatStream) then
      rchStat.Lines.LoadFromStream(FStatStream);
    rchStat.MaxLength := $7FFFFFF0;
  finally
    FStatStream.Free;
  end;
end;
// note: this is not original code, in the real code FStatStream is a
private
//       member which is not freed before the user is done with the file.

Quote
> I don't see this extra line in the source; I would expect it to cause a
> second attempt to load to work even though perhaps it failed first
> time. My site reports this not to be the case.

<D5.01 in ComCtrls.pas>
procedure TRichEditStrings.LoadFromFile(const FileName: string);
var
  .....
  RichEdit.DoSetMaxLength($7FFFFFF0);  // line 9850
end;

Quote
> Doesn't *yours* work only second time around on LoadFromFile?

On WinME LoadFromFile seems to function always.
When using LoadFromStream I at least have to set the
MaxLength once.  It also worked when simply setting
the MaxLength property of the richedit in designtime
to $7FFFFFF0.
When you've MaxLength set to 0 it uses the default value
for it, according to the docs this is 32K. When now loading
from a stream it sets the MaxLength to the length of the file
at least that is what it seems to do on WinME.
Maybe there are other issues on W2K making this way of
doing it not function correctly. You could try settings the
MaxLength at forehand at designtime. (but then again a
second call to LoadFromFile should do the same and as
you said this also doesn't function on W2K....?)

Quote
> No I'm using LoadFromFile.
> But the VCL implements this method by setting up a filestream
> and calling LoadFromStream. It is within LoadFromStream that
> I saw the call to reload as plain text on error, so I don't really see
> how resetting MaxLength after LoadFromFile completes can help....

Me neither :) it was just a guess based on the posts I saw.

[snipped]

Quote
> Last week I had very little idea about what to do about this (had even
> made contingency plans to revive the plain text file reader in case I
> could not fix it) but in the light of your comments I now have some
> worthwhile tests that can be conducted on-site that look likely to
> yield a solution.

Here is another one. As I understand the riched32.dll is a little file
(about 4K?) on W2K which is doing the emulation and is using
riched20.dll.  You could try using another version of this riched32.dll
(borrow one from 98 or NT) and see if that one will function
properly on W2K.

--
Pieter

PS1 I've been playing around with richedit version 1 and 2 on WinME.
       Loading/editing/saving file of several MB's does not give me any
       problems. So the problems you've described originally, seems to
       be W2K specific (but I guess you already knew this).

PS2 I know you don't like moving to a 3rd-party richedit but here
        is another one... RXLib (www.rxlib.com) has a richedit
        control with support for version 1, 2 and 3. There is also a
        little demo program in it (like the one in Delphi). You could
        take that one with you and see if this one functions properly
        on their RTF-files.

Re:RichEdit not working on W2K


Quote
"Pieter Zijlstra" wrote....
> <something>

PS3 :)
I've found some messages (mainly by Peter Below) which tell
me that is should be possible to just take a riched32.dll from
NT and dump this one in your application directory when your
installer detects a W2K system. On W2K this dll will be
used/loaded when your program starts and AFAICS there are
no other issues (meaning it should work without any problems
(i hope:) ).

On other OS's, there is no need to do this and you can just
use the one which is already installed on the system

--
Pieter

Re:RichEdit not working on W2K


In article <3b599c4d_2@dnews>, "Pieter Zijlstra" <pzijlstr...@freeler.nl>
wrote:

Quote
> <D5.01 in ComCtrls.pas>
> procedure TRichEditStrings.LoadFromFile(const FileName: string);
> var
>   .....
>   RichEdit.DoSetMaxLength($7FFFFFF0);  // line 9850
> end;

Not there in 3.01. (I could upgrade, but that would probably break something
else).
Perhaps it is a v4 or 5 bug fix.
Quote
> When you've MaxLength set to 0 it uses the default value
> for it, according to the docs this is 32K.

Which might account for your observed result of failing on files of 40-70K
i.e 32K of actual text plus 8-38K of formatting. (?)
Quote
> When now loading
> from a stream it sets the MaxLength to the length of the file

.. well that would seem to be enough, though I wouldn't be surprised if it
took a second try to get it to take effect.
Quote
> at least that is what it seems to do on WinME.
> Maybe there are other issues on W2K making this way of
> doing it not function correctly. You could try settings the
> MaxLength at forehand at designtime. (but then again a
> second call to LoadFromFile should do the same and as
> you said this also doesn't function on W2K....?)

Not if compiled with D3. It might with D5 because of the line you quote
above.
I think I'll try setting Maxlength to $7FFFFFF0 at design time, *and* before
loadfromfile *and* afterwards! If it works I can try to isolate which one is
essential, though experience tells me that once it works the target site
will lose interest.

Quote
>> worthwhile tests that can be conducted on-site that look likely to
>> yield a solution.
> Here is another one. As I understand the riched32.dll is a little file
> (about 4K?) on W2K which is doing the emulation and is using
> riched20.dll.  You could try using another version of this riched32.dll
> (borrow one from 98 or NT) and see if that one will function
> properly on W2K.

I like your PS3 better. This would be OK as a test to prove that it is
really M$'s fault but the site probably wouldn't like me overwriting their
system files, and it could cause other software to malfunction..

Quote
> PS1 I've been playing around with richedit version 1 and 2 on WinME.
>        Loading/editing/saving file of several MB's does not give me any
>        problems. So the problems you've described originally, seems to
>        be W2K specific (but I guess you already knew this).

Site originally said it occurred on their NT terminals as well but they've
since retracted this. Plenty of people run my app on NT with no problems.

(from other post)

Quote
> PS3 :)
> I've found some messages (mainly by Peter Below) which tell
> me that is should be possible to just take a riched32.dll from
> NT and dump this one in your application directory

.. yes I can see that this ought to work in principle!
I wonder though if another application then calls LoadLibrary on RichEdit32
whether it could get directed to my copy while it is in memory and cause
unexpected behaviour in the other app.
Bit surprised that PB hasn't commented here, he usually answers richedit
qns. But I think you've given me enough material to crack this. Phew. On
average I take about 1 hour from reading a bug report to isolating the cause
and proposing a solution. Not 1 month as in this one!

Thanks for all your help.
regards Iain.

Re:RichEdit not working on W2K


Quote
"Iain & Sue" wrote...
> > I've found some messages (mainly by Peter Below) which tell
> > me that is should be possible to just take a riched32.dll from
> > NT and dump this one in your application directory

> .. yes I can see that this ought to work in principle!
> I wonder though if another application then calls LoadLibrary
> on RichEdit32 whether it could get directed to my copy while
> it is in memory and cause unexpected behaviour in the other app.

AFAIK W2K will load the one you have in the app directory only
for your application. Also when there is already another one active
in memory.  This is not the case for other windows versions 9x/NT
(not sure about ME) they will 'see' that there is a richedit loaded
and take a copy of that one.
So you would have to check the target system during installation
and only copy the riched32.dll when it is W2K.

--
Pieter

Re:RichEdit not working on W2K


"Iain & Sue" <h...@ariesps.co.uk> wrote in message news:3b5c6ceb_1@dnews...

Quote
> >   RichEdit.DoSetMaxLength($7FFFFFF0);  // line 9850
> > end;
> Not there in 3.01. (I could upgrade, but that would probably break
something
> else).

Before filling the richedit with content, try:
  SendMessage(richedit1.Handle, EM_EXLIMITTEXT, 0, $7FFFFFF0);

(Not upgrading your development tool regulary makes it much more difficult
when you finally decide to upgrade to the latest version!)

--
Rune

Re:RichEdit not working on W2K


In article <3b5c7b2d_1@dnews>, "Pieter Zijlstra" <pzijlstr...@freeler.nl>
wrote:

Quote
> AFAIK W2K will load the one you have in the app directory only
> for your application. Also when there is already another one active
> in memory.

Makes some sense. I understand that M$ are proposing to return to a system
with applications and their associated files being directory based and no
more registry.
Quote
> This is not the case for other windows versions 9x/NT
> (not sure about ME) they will 'see' that there is a richedit loaded
> and take a copy of that one.

That's what I was worried about. And conversely if I 'get in first' the
other apps will take a copy of mine.
Quote
> So you would have to check the target system during installation
> and only copy the riched32.dll when it is W2K.

The app is usually loaded onto a server and run by workstations. Therefore
it is entirely possible that the same app will run on NT and W2K depending
on which the workstation has. This is indeed the case at my troubled site...

.. but if we took a copy of the NT DLL it wouldn't matter if it were running
on NT - although the physical location of the file would be different the
functionality would be the same. If they also had any 9x stations this might
be a problem though.

regards Iain.

Re:RichEdit not working on W2K


Quote
In article <3b5d38c8_1@dnews>, "Rune Moberg" <rmob...@arxi.no> wrote:
> Before filling the richedit with content, try:
>   SendMessage(richedit1.Handle, EM_EXLIMITTEXT, 0, $7FFFFFF0);

That is what Richedit.DoSetMaxLength($7F...) does.

(although this method is protected so the SendMessage direct is probably
shorter than exposing it).

Quote

> (Not upgrading your development tool regulary makes it much more difficult
> when you finally decide to upgrade to the latest version!)

Although only users with W9x+ can use this part of the system (Richedit
display) we still have many users who have W3.11 believe it or not.
Therefore _most_ of my code must compile on D1. That's why I prefer to stick
to D3.
To target systems as widely separated as 3.11 and 2K I restrict my choice of
components to the most basic - I do not even use BitButtons as they can
crash some early video cards.

For the benefit of the users with lower grade systems we must continue to
produce programs they can run. Probably in about 10 years time I'll be
searching for D6 or 7 because we have found that all users have web browser
access and I need Websnap. <g>

regards Iain.

Re:RichEdit not working on W2K


Cracked it: Final Post on this:

Quote
>> When you've MaxLength set to 0 it uses the default value
>> for it, according to the docs this is 32K.
> Which might account for your observed result of failing on files of 40-70K
> i.e 32K of actual text plus 8-38K of formatting. (?)

My tests indicated that 64KB of actual text (ignoring formatting) could be
loaded before it fell over.
Perhaps a variation between versions of the DLL.

Quote
> I think I'll try setting Maxlength to $7FFFFFF0 at design time, *and* before
> loadfromfile *and* afterwards!
Message from site:
>>> Iain
>>> That works OK now.

%-)))))
Phew!
Go to page: [1] [2]

Other Threads