I encountered a few strange questions when I used RichTextBox.
◆ Problem 1:
When I copy data from MS-Word to RichTextBox, I encountered the following three questions:
(1)The image color is changed
(2) The edge of the picture appears jagged
(3) The Unicode characters can't be displayed
◆ Problem 2:
RichTextBox SelStart, SelLength and SelText are sometimes incorrect.
◆ Problem 3:
RichTextBox will have a memory leak when we frequently use the SelStart, SelLength and SelText properties.
(1) In XP, whether it is in VB6 IDE environment or compiled into an executable file, RichTextBox has memory leak problem (at least on my computer). When click the Problem3 button, the test program will run out of all the memory of the computer.
(2) In Win10, in the VB6 IDE environment, RichTextBox does not happen memory leak. However, when compiled into an executable program, RichTextBox has memory leak problem and will run out of all the memory of the computer and raise 'Automation error'.
◆ Problem 4:
If we use Ms Word to open sample.rtf, the pictures are not distorted. If we use RichTextBox to open sample.rtf, the pictures are distorted. In fact, all information about anti-aliasing is present in the rtf, but how can we find and use this information ?
See the test program for details. Thanks very much.
Problem 2: No idea. Maybe you aren't maintaining sync between the RichTextBox wrapper and the underlying RichEdit control you have manipulated via TOM or windows messages?
Problem 3: I've never seen it.
Problems 1 & 4: Perhaps you aren't capturing and rendering properly?
I have altered a prior demo I provided in another thread earlier. This one (a.) renders using another method, and (b.) allows Form resizing so you can see these images scale up.
I left your sample.rtf out to save on attachment size.
Problem 1 is a limitation of the RichTextBox wrapping an old-style RichEdit control. Using a version 4.1 RichEdit might address it but I think somebody else already said that it doesn't over in the other thread.
Problem 1 is a limitation of the RichTextBox wrapping an old-style RichEdit control. Using a version 4.1 RichEdit might address it but I think somebody else already said that it doesn't over in the other thread.
Rich Edit version 4.1 shows some Chinese characters over (outside) the picture of question 3, also a couple of Chinese characters over the figures of questions 1 and 2 that I can not see in the original (opening the rtf file with Word).
Besides that, it has the same problems described in the "Problem 1" point of the OP, as Rich Edit version 1 also has.
The same can be seen opening the file with Wordpad, it seems that Wordpad (on XP) uses Rich Edit Version 4.1 (it changes the letters color, the circle is jagged, Etc.)
All that tested on Window XP.
In the image that dilettante posted, I see that the Chinese characters as displayed properly inside the figure of question 3, I don't get that on XP, not even with Wordpad.
I'm sure there are tons of things in Word that system RichEdit controls can't support.
I'm not sure that storing screenshots is very useful though, because a lot of things are far larger than the screen and even compressing bitmaps can result in large blobs of data and a loss of fidelity. At least metafiles can be scaled cleanly if they contain vector graphics.
Wrapping capture bitmaps within PDF markup only makes things worse, so I'm not sure why that might make sense. What am I missing?
I'm sure there are tons of things in Word that system RichEdit controls can't support.
I'm not sure that storing screenshots is very useful though, because a lot of things are far larger than the screen and even compressing bitmaps can result in large blobs of data and a loss of fidelity. At least metafiles can be scaled cleanly if they contain vector graphics.
Wrapping capture bitmaps within PDF markup only makes things worse, so I'm not sure why that might make sense. What am I missing?
The PDF option is intended to pack together formatted text and graphics without the text being converted to images.
More or less the same that RTF does. I think that PDF uses less space than RTF for storing images, because it uses compression.
I added option 3) at the bottom: Instead of a RichTextBox, to use an OLE container and save the data in Word format.
◆ Problem 2:
RichTextBox SelStart, SelLength and SelText are sometimes incorrect.
I experienced that.
There are sometimes hidden or special characters, and when you try to change the .SelStart (rtb.SelStart = rtb.SelStart + 1) it remains in the same value, until you advance enough characters at once.
Whether it is a bug or a feature I don't know, but it cause problems.
I encountered a few strange questions when I used RichTextBox.
◆ Problem 1:
When I copy data from MS-Word to RichTextBox, I encountered the following three questions:
(1)The image color is changed
(2) The edge of the picture appears jagged
(3) The Unicode characters can't be displayed
...
Note: Problem 1 has been discussed in the following thread, and there is no need to discuss it here.
Well, what didn't come up in that thread was a decent explanation, why that happened:
Word is using EMF (a resolution-independent Vector-Format, which only describes
and stores Graphics-API-calls as priorily recorded "EMF-Records").
So, the original Image Word always works with, is the "blue stroked lines"
with the "red Characters" at the edges.
Word then enumerates the EMF-Records of that original EMF-image - but renders
them "antialiased, using GDI+" (instead of the normal EMF/WMF-API, which is rendering with GDI).
But what Word then also applies "on top" of that rendering, is a "User-setting" on that
image, choosable from a DropDown-Combo in the appropriate "Word-Image-Effects"
Dialogue (the effect in question is called "Black and white Rendering" or something like
that).
That effect-setting is "docked sideways" to the Image-Data in Word) - and you can
of course also remove that effect on the given Image, any time (without destroing
the underlying EMF) - using the Image-Format-Dialogue in the Word-Application.
As for, how you answered the question about "what the whole thing is for" -
(you developing a multipurpose "Copy&Paste-Tool" for Document-Texts and -Images
from multiple sources, including Browers...
Especially the last requirement (having Browsers as Sources which could provide the copied Input),
should give you already the hint, that going the "RTF-route" is somehow not really covering
your whole scenario.
On the other hand, when you choose HTML as your storage-format, you could cover it in a
broader way, since Word *does* put its content also HTML-formatted onto the Clipboard
(whereas most Browsers don't put RTF onto it, when WebPage-contents are copied).
The PDF format is more like a metafile graphics format, PCL, etc. If you feed these a bitmap capture there isn't much to be done with it in terms of space savings. At best they might try to apply PNG-like compression but I'm not sure any of them do.
If you can make Word "print" to PDF then yes, at least text will be saved as globs of text with font-and-layout markup. I'm not sure how they manage metafile graphics but it would have the chance to capture the vector-based elements of the drawing as vector graphics. That's how print drivers work.
But screen captures would be worse than what we've demonstrated already. Far worse in nearly every way.
The most ideal solution would be to preserve the original markup and data it wraps, and store that. Doing so means you need a renderer for each one if viewing and printing is needed. For Word that means Word, for HTML+CSS it means an appropriate rendering engine as well.
Even just considering those two it gets dicey. Capabilities vary all over: different versions of Word have different abilities, different browsers render differently and many pages are created or completed either server- or client-side at run time to target a specific brand and version of browser.
You could capture and store the markup on one machine and have it render poorly on another machine.
The virtual printer driver approach starts to sound better and better.
The virtual printer driver approach starts to sound better and better.
Yes, but he won't be able to separate text from graphics as he does now with your TOM program.
BTW: once he gets the images with the TOM program, if he stores them in the database in a pixel based format (bmp, jpg), he is losing the metafile, the capabilities of vector based rendering.
As long as he persists the StdPicture object he can keep the WMF/EMF/EMF+ when that's what the pasted RTF contains. Of course grabbing the rendered StdPicture from a PictureBox or Form does lose that information.
I'm not sure why he separates out the text unless it is for indexing or searching.
As long as he persists the StdPicture object he can keep the WMF/EMF/EMF+ when that's what the pasted RTF contains. Of course grabbing the rendered StdPicture from a PictureBox or Form does lose that information.
I'm not sure why he separates out the text unless it is for indexing or searching.
I don't think he persist the StdPicture.
He should be saving a .emf (or .wmf) file and then store it into the database.
Do you know of any way of persisting the StdPicture regardeless of what is inside? (I think you need to save it in the proper file format: bmp, ico, wmf, emf)
Word is using EMF (a resolution-independent Vector-Format, which only describes
and stores Graphics-API-calls as priorily recorded "EMF-Records").
So, the original Image Word always works with, is the "blue stroked lines"
with the "red Characters" at the edges.
Word then enumerates the EMF-Records of that original EMF-image - but renders
them "antialiased, using GDI+" (instead of the normal EMF/WMF-API, which is rendering with GDI)...
I can't speak to what Word itself does, but EMF+ is more complex than just "EMF rendered via GDI+".
EMF+ supports the full range of GDI+ drawing commands, including many commands for which there is no obvious GDI replacement. The official spec describes all the options in detail, but it's not just drawing commands that are problematic - it's objects like pens and brushes as well. (For example, there's no way to produce something complex like a "path gradient brush with a dozen RGBA stops" in GDI.)
So as the spec itself says...
EMF+ is not considered an extension to the EMF feature set; that is, EMF+ does not define new EMF records. EMF+ is semantically a completely separate, independent format. EMF+ records define graphical images and text using commands, objects, and properties of GDI+.
Without a local copy of Word I can only be so helpful here, but as I mentioned in the other thread, EMF files support so-called "Dual-EMF" records, where the vector data is stored inside the file *twice*: once in regular EMF format, and then a second, full "EMF+" record. (The EMF+ data is hidden inside EMF comments that will be ignored by an old-style EMF parser, interestingly.) The regular EMF data is supposed to be as close to the EMF+ data as possible, but in my experience, Microsoft is very lackadaisical about this - e.g. color constants may not be translated correctly, drawing commands may be approximately poorly, etc.
There's no obvious way to tell this from the .emf extension, because it is shared between EMF, EMF+, and Dual-EMF files. You have to actually look inside the file to tell what kind of data is stored.
I still think the most likely explanation is that Word embeds Dual-EMF files. The RTB grabs this and parses only the regular EMF data (which is incomplete and buggy). Word, on the other hand, uses the EMF+ data, so it can preserve the image "perfectly" even when moving to/from RTF format.
I bring this up because it isn't that difficult to render an EMF+ record into a bitmap container, which you could substitute "on-the-fly" for the RTF. Yes you would lose all the vector benefits, but given the choice between "a visually broken EMF imitation", and a "visually perfect but un-scale-able bitmap copy", the latter is likely preferable (especially for preserving Unicode chars).
That said, I imagine Word puts a bitmap version of the data on the clipboard anyway (Office is notorious for vomiting dozens of clipboard formats on each Ctrl+C). They'd want this for consumption in non-vector-aware programs. It may still be easiest to coerce the RTB into just taking some bitmap clipboard format, instead of trying to solve this EMF-specific issue.
I don't think he persist the StdPicture.
He should be saving a .emf (or .wmf) file and then store it into the database.
Do you know of any way of persisting the StdPicture regardeless of what is inside? (I think you need to save it in the proper file format: bmp, ico, wmf, emf)
I'm pretty sure that if you use ADO and Store a StdPicture into a BLOB field it makes use of the IPicture interface to persist it. IPicture::SaveAsFile writes to an IStream, which is what ADO wants.
I bring this up because it isn't that difficult to render an EMF+ record into a bitmap container, which you could substitute "on-the-fly" for the RTF. Yes you would lose all the vector benefits, but given the choice between "a visually broken EMF imitation", and a "visually perfect but un-scale-able bitmap copy", the latter is likely preferable (especially for preserving Unicode chars).
The example code I posted seems to render fine, no Word required.
Whether that meets the requirement is another issue, but it appears to address the question posted. Or did I misinterpret what was being asked for?
Perhaps so, since the RTB still shows lo-fi images.
As far as I can tell the RTB's problem may stem from its IRichEditOleCallback implementation. So perhaps it isn't the wrapped RichEdit control itself, but the wrapper.
Yes, dilettante - your example does indeed solve the Unicode problem (tested on Win 10 here), but the "lo-fi" images seem to indicate that any EMF+ features are still being ignored. A tell-tale sign is the bars in the bar graph - in a Dual-EMF file, semi-transparency is emulated with hatch brushes. That's exactly what's happening here, if I understand dreammanor's MyRichText7.bmp file correctly.
The hard thing is that this sample file only contains very basic shapes and figures. A file with more complex charts or imagery could look even worse than just mangled colors and antialiasing differences. It's hard to know if any given "workaround" is going to be acceptable when we only have one file to test!
dreammanor, can you put together a few other RTF files for us? How hard would that be?
Problem 2: No idea. Maybe you aren't maintaining sync between the RichTextBox wrapper and the underlying RichEdit control you have manipulated via TOM or windows messages?
In my test program, first load Sample.rtf, and then click the button <<Problem 2>>, you will find selStart and SelLength occur offset.(I have tested in XP and Win10).
Originally Posted by dilettante
Problem 3: I've never seen it.
(1) In XP, whether it is in VB6 IDE environment or compiled into an executable file, RichTextBox has memory leak problem. When click the Problem3 button, the test program will run out of all the memory of the computer.
(2) In Win10, in the VB6 IDE environment, RichTextBox does not happen memory leak. However, when compiled into an executable program, RichTextBox has memory leak problem and will run out of all the memory of the computer and raise 'Automation error'.
Originally Posted by dilettante
Problems 1 & 4: Perhaps you aren't capturing and rendering properly?
The pictures are extracted with the TOM method (using the demo program you have previously provided), but the data has changed before rendering (that is, it changed when it was copied from the clipboard to the RichTextBox)
Originally Posted by dilettante
I have altered a prior demo I provided in another thread earlier. This one (a.) renders using another method, and (b.) allows Form resizing so you can see these images scale up.
Your new method solves the problem that the picture Unicode characters can not be displayed, thanks a lot.
Problem 1 is a limitation of the RichTextBox wrapping an old-style RichEdit control. Using a version 4.1 RichEdit might address it but I think somebody else already said that it doesn't over in the other thread.
How to use VB6 to package msftedit.dll, I did not find the relevant information on the Internet.
By the way, you told me to use the TOM interface with the following statement
Code:
SendMessage RichTextBox1.hWnd, EM_GETOLEINTERFACE, 0, VarPtr(IUnknown)
Set TextDocument1 = IUnknown
But I don't know how to unattach(stop) TOM interface from RichTextBox when I finished the RichTextBox operation.
And also,how to use TOM or Window messages to achieve the operations similar to SelStart, SelLength, SelText ?
So, if someone thought that anything that can be displayed in Word could also be passed to a RichTextBox, this approach was mistaken from the start.
In fact, Word has put all the information (including picture rendering info.) into the RTF file, if we can extract and parse the information, then most of the information that can be displayed in Word could also be shown in RichTextBox.
Originally Posted by Eduardo-
If the requirement is that anything that the user can see on the screen he needs to be able to save it to a database, then I suggest:
1) Capture that part of the screen and save that picture.
2) Print it with a PDF printer driver and save the PDF file.
I think these two options were already suggested by others in the other thread.
3) Use and OLE container and save in Word format.
Some customers have not installed MS Word on their computers, but they need to view and edit the data. Thanks for your advice.
@the OP
FWIW, here's a Cairo-based EMZtoPNG-converter (although we still don't know, what the whole exercise really is for).
Code:
Option Explicit
Private Sub Form_Load()
EMZ2PNG App.Path & "\image001.emz", App.Path & "\image001.png", 480
EMZ2PNG App.Path & "\image003.emz", App.Path & "\image003.png", 480
EMZ2PNG App.Path & "\image005.emz", App.Path & "\image005.png", 480
'now show a preview for one of the converted Images
Set Picture = Cairo.ImageList.AddImage("", App.Path & "\image003.png").Picture
End Sub
Private Sub EMZ2PNG(EMZFile As String, PNGFile As String, ByVal DstHeightPxl As Long)
Dim BCmp() As Byte, BDec() As Byte, EMFPage As cReportPage, Srf As cCairoSurface
BCmp = New_c.FSO.ReadByteContent(EMZFile) 'read the entire File into a Byte-Array
New_c.Crypt.GzDecompress BCmp, BDec 'decode the ByteArray with the GZ-Decompression-algo
'create a new ReportPage-instance (cReportPage is handling EMF internally)
Set EMFPage = New_c.ReportPage
EMFPage.EMFContent = BDec 'provide the GZ-Decoded EMF-bytes as the Page-content
'prepare an oversized Cairo-Surface for as a target for the EMF-rendering
Set Srf = Cairo.CreateWin32Surface(3.3 * DstHeightPxl * EMFPage.AspectRatio, 3.3 * DstHeightPxl)
Srf.CreateContext.Paint 1, Cairo.CreateSolidPatternLng(vbWhite)
EMFPage.RenderTo Srf.GetDC, 0, 0, Srf.Width, Srf.Height 'render the EMF onto the CairoSrf
With Srf.CreateContext 'correct the missing Alpha-Info on the just rendered EMF-content
.Operator = CAIRO_OPERATOR_DEST_ATOP
.Paint 1, Cairo.CreateSolidPatternLng(vbBlack)
End With
'finally a high-quality downstretching from the oversized Cairo-Surface to a smaller one
With Cairo.CreateSurface(DstHeightPxl * EMFPage.AspectRatio, DstHeightPxl).CreateContext
.RenderSurfaceContent Srf, 0, 0, .Surface.Width, .Surface.Height, CAIRO_FILTER_GAUSSIAN
.Surface.WriteContentToPngFile PNGFile
End With
End Sub
Private Sub Form_Terminate()
New_c.CleanupRichClientDll
End Sub
Here's a preview of the green-circle after conversion (from one of those EMZs, which were created during HTML-export).
Olaf
Move Olaf's reply from another post to here.
Last edited by dreammanor; Mar 8th, 2017 at 06:42 AM.
In fact, Word has put all the information (including picture rendering info.) into the RTF file, if we can extract and parse the information, then most of the information that can be displayed in Word could also be shown in RichTextBox.
Some customers have not installed MS Word on their computers, but they need to view and edit the data. Thanks for your advice.
There will always be information that will be displayed in Word and not in the RTB (or Wordpad), or will be displayed incorrectly, simply because the Rich Edit doesn't handle all the RTF codes supported by Word, even when you don't want to believe it (or investigate).
You are trying to do something logically imposible.
If you are OK with having "most the information", OK, you already have "most of the information". Then don't expect it to be perfect.
vbRichClient5 can be perfect to read EMZ file format, which is really useful.
I'm thinking, since Ms Word has put all the information (including picture rendering info.) into the RTF file, then we can extract, parse and use this information. If we can convert all the image data existed in RTF into EMZ files, then we can use vbRichClient5 to convert these EMZ files into PNG files and reinsert them into RTF, then the most troublesome problem can be resolved.
Of course, if vbRichClient can directly read the EMZ or other picture information in the RTF, it is more perfect,
then vbRichClient and Cairo can play a greater role.
Well, what didn't come up in that thread was a decent explanation, why that happened:
Sorry, my new post has caused confusion and inconvenience. The original post title(How to change the specified color...) and the content of the discussion is inconsistent, in addition, I encountered a few new RTB problems, so I merged the 'question 1' into this new post.
Originally Posted by Schmidt
As for, how you answered the question about "what the whole thing is for" -
(you developing a multipurpose "Copy&Paste-Tool" for Document-Texts and -Images
from multiple sources, including Browers...
Especially the last requirement (having Browsers as Sources which could provide the copied Input),
should give you already the hint, that going the "RTF-route" is somehow not really covering
your whole scenario.
On the other hand, when you choose HTML as your storage-format, you could cover it in a
broader way, since Word *does* put its content also HTML-formatted onto the Clipboard
(whereas most Browsers don't put RTF onto it, when WebPage-contents are copied).
Olaf
RTF does not meet all of my needs, but as long as the problem of picture distortion can be solved, then RTF basically can meet 90% of the project needs. In addition, the project has begun more than three months, and it's too late to adopt a new alternative solution.
Since vbRichClient can read EMF files, so I am now considering a remedy. My idea is this: First, save MS Word doc as html file, and then parse html file, and then use vbRichClient5 to convert EMZ files into PNG files, and then insert the PNG files into the RTF.
Last edited by dreammanor; Mar 9th, 2017 at 02:49 AM.
Compliments, you all seem to have a lot of experience with the RichEdit control. If you google site:masm32.com riched bugs, you may add some new problems to your list.
The best versions we've seen so far are Office11 (fastest) and Office12 (fast and maybe a bit more complete).
RichEdit 4.1 (msft.dll) is a factor 10 faster than Sys32 in loading RTF sources, but EM_STREAMOUT is broken: it forgets a few bytes on 2048*n borders.
The bugs don't appear with small files, and don't seem to appear with large text files. Until one day you see mysterious compiler messages because the stupid control has suppressed a few characters...
I know this doesn't add much to your debate here - this is just to let you know that others are suffering from this crappy control, too
I experienced that.
There are sometimes hidden or special characters, and when you try to change the .SelStart (rtb.SelStart = rtb.SelStart + 1) it remains in the same value, until you advance enough characters at once.
Whether it is a bug or a feature I don't know, but it cause problems.
Yes, I think so. If RTB's SelStart, SelLength and SelText are sometimes incorrect, it is unpredictable to use RichTextBox to perform search and replace operation.
As long as he persists the StdPicture object he can keep the WMF/EMF/EMF+ when that's what the pasted RTF contains. Of course grabbing the rendered StdPicture from a PictureBox or Form does lose that information.
I'm not sure why he separates out the text unless it is for indexing or searching.
All the StdPicture objects will be converted to PNG before they are stored in the database.
There are several reasons for separating text and images:
1. The original version of the project required only to store text files, and later to increase the picture storage function.
2. The images should be filtered before deciding whether to store them in the database.
3. It is to reduce database storage space.
4. It is also for indexing or searching.
Originally Posted by dilettante
Well I suppose the metafile could be rendered using GDI+ Flat API calls if necessary. Easy enough in concept, he just needs to try it.
I am only familiar with GDI, GDI+ is completely strange to me, and I really do not have time to learn GDI+, just as I do not have time to learn Subclass. In addition, I heard that there are a few problems in GDI+ , such as memory leaks.
Last edited by dreammanor; Mar 9th, 2017 at 05:06 AM.
Yes, dilettante - your example does indeed solve the Unicode problem (tested on Win 10 here), but the "lo-fi" images seem to indicate that any EMF+ features are still being ignored. A tell-tale sign is the bars in the bar graph - in a Dual-EMF file, semi-transparency is emulated with hatch brushes. That's exactly what's happening here, if I understand dreammanor's MyRichText7.bmp file correctly.
The hard thing is that this sample file only contains very basic shapes and figures. A file with more complex charts or imagery could look even worse than just mangled colors and antialiasing differences. It's hard to know if any given "workaround" is going to be acceptable when we only have one file to test!
dreammanor, can you put together a few other RTF files for us? How hard would that be?
Ok, I did some more tests in Win10 and Ms Word2016.
1. When I copied pictures from PPT to RTB, the pictures were seriously distorted.
2. When I copied the picture from the PPT to Ms Word2016, and then copied the picture from Word2016 to RichTextBox, the picture could not be displayed in RTB.
3. When I copied the picture from the PPT to Word2016, and then saved the docx as html, I found that Word2016 saved all the pictures as PNG.
4. When I copied the picture from the PPT to Word2016, and then saved the docx as rtf, then I used RichTextBox to open the rtf file, the picture could not be displayed. I guess RichTextBox can not read PNG.
The new RTF file is placed in the following zip file.
Last edited by dreammanor; Mar 9th, 2017 at 04:39 AM.
Compliments, you all seem to have a lot of experience with the RichEdit control. If you google site:masm32.com riched bugs, you may add some new problems to your list.
The best versions we've seen so far are Office11 (fastest) and Office12 (fast and maybe a bit more complete).
RichEdit 4.1 (msft.dll) is a factor 10 faster than Sys32 in loading RTF sources, but EM_STREAMOUT is broken: it forgets a few bytes on 2048*n borders.
The bugs don't appear with small files, and don't seem to appear with large text files. Until one day you see mysterious compiler messages because the stupid control has suppressed a few characters...
I know this doesn't add much to your debate here - this is just to let you know that others are suffering from this crappy control, too
Your information is very useful, thank you for your reply.
Reply With Quote
Originally Posted by dilettante
