I posted the solution to the .PNG Challenge on Code Project.
Every article posted in Code Project has to be approved by members above a certain level.
Assembly Language articles take longer to be approved because most experts have no expertise at all in ASM.
In addition, during the submission phase, I have to deal with comments like this:
"Why have you done this Assembly language? If you wanted low-level you could do it in C". A bit painful. :shock:
Here is the link:
https://www.codeproject.com/Articles/1360569/Embedding-PNG-images-into-a-RichEdit-document
Quote from: AW on April 05, 2019, 04:35:49 AM
I posted the solution to the .PNG Challenge on Code Project.
Every article posted in Code Project has to be approved by members above a certain level.
Assembly Language articles take longer to be approved because most experts have no expertise at all in ASM.
In addition, during the submission phase, I have to deal with comments like this:
"Why have you done this Assembly language? If you wanted low-level you could do it in C". A bit painful. :shock:
Here is the link:
https://www.codeproject.com/Articles/1360569/Embedding-PNG-images-into-a-RichEdit-document
great work :t
we C a more skilled and unique coder because he dare to use masm :greenclp:
Its a good article Jose but you will have to improve that photo. :P
Thank you all.
I believe the photo is eye catching, so you noticed it. :badgrin:
LinkedIn notified me this morning about the article :t
I wonder whether EM_INSERTIMAGE works under Windows 7 with the Office versions of RichEd20.dll. Will test it if I find the time.
Hardly, it don't even support RichEdit50W, as it have RichEdit60W
EDIT: Office 2013 have v8 and RichEdit50W, but works only with RichEdit60W.
My idea is create pics from unicode characters + colorization them and bevel some of them and maybe test other effects too
After that starts a gdi based game
Timo, Richedit50W is certainly not a problem on Win7.
I got the idea now.
Office 2016 has:
Riched20.dll
File Description: Richedit version 8.0
File Version: 16.0.11328.20068
Product Version: 16.0.11328.20068
I have Office 2019 in one machine but can't see any difference, Microsoft also says:
"Retail versions of Office 2016 C2R and Office 2019
The following information applies to retail versions of Office 2016 C2R and Office 2019, which share the same release dates and version numbers."
Probably Office 365 has innovations but I have not purchased that. However, I believe there is no real innovation at all, the product is stagnated and they are milking the cow as much as possible.
So Murray was talking about the File Description not about version-version.
But let's see Windows 8.0:
Windows 8 has:
Msftedit.dll
File Description: Richedit version 7.5
File Version: 6.2.9200.16657
Product Version: 6.2.9200.16657
But let's see Windows 8.1:
Windows 8.1 has:
Msftedit.dll
File Description: Richedit version 7.5
File Version: 6.3.9600.18818
Product Version: 6.3.9600.18818
What about Windows 10?
msfted.dll
File Description: Rich Text Edit Control 8.5
File version 10.0.17763.1
Product version: 10.0.17763.1
So, someone is drinking too much wine!
On the other hand, Murray is now posting about Richedit 9.0. Where is that one?
Windows 7-64:
5.0 5.50.99.2050 C:\Program Files (x86)\Common Files\Microsoft shared\Office11\RICHED20.DLL
6.0 12.0.678.5000 C:\Program Files (x86)\Common Files\Microsoft shared\OFFICE12\RICHED20.DLL
6.0 14.0.7155.5000 C:\Program Files (x86)\Common Files\Microsoft shared\OFFICE14\RICHED20.DLL
3.1 5.31.23.1230 C:\Windows\System32\riched20.dll
4.1 5.41.21.2510 C:\Windows\System32\msftedit.dll
Where possible, I use the Office12 version. Office11 is ok but some features are missing, Office14 is buggy.
I have good reason to stick with Rich Edit 2/3, it works from old 32 bit OS versions up to current Win 10 64 bit. I have few aspirations of more complex tasks but if I did it would be a version that was available from Win 7 64 bit upwards.
It's complete now.
WINDOWS RICHED20.DLL MSFTEDIT.DLL
File Description File Version Product Version Class Comment File Description File Version Product Version Class
Windows NT Rich Text Edit Control v3.0 5.30.23.1200 3.0 RICHEDIT20W na na na
Windows 2000 Rich Text Edit Control v3.0 5.30.23.1227 3.0 RICHEDIT20W na na na
Windows XP Rich Text Edit Control v3.0 5.30.23.1230 3.0 RICHEDIT20W Rich Text Edit Control v4.1 5.41.15.1515 4.1 RICHEDIT50W
Windows Vista Rich Text Edit Control v3.1 5.31.23.1229 5.0.0.0 RICHEDIT20W Rich Text Edit Control v4.1 5.41.21.2509 5.0.0.0 RICHEDIT50W
Windows 7 Rich Text Edit Control v3.1 5.31.23.1230 3.1 RICHEDIT20W Rich Text Edit Control v4.1 5.41.21.2510 4.1 RICHEDIT50W
Windows 8.0 Rich Text Edit Control v3.1 5.31.23.1230 3.1 RICHEDIT20W Rich Text Edit Control v7.5 6.2.9200.16657 6.2.9200.16657 RICHEDIT50W
Windows 8.1 Rich Text Edit Control v3.1 5.31.23.1231 3.1 RICHEDIT20W Rich Text Edit Control v7.5 6.3.9600.18818 6.3.9600.18818 RICHEDIT50W
Windows 10 Rich Text Edit Control v3.1 5.31.23.1231 3.1 RICHEDIT20W Rich Text Edit Control v8.5 10.0.17763.1 10.0.17763.1 RICHEDIT50W
OFFICE
Office 2002 (Office 10) Rich Text Edit Control v4.0 5.40.11.2220 4.0 RICHEDIT20W na na na
Office 2003 (Office 11) Rich Text Edit Control v5.0 5.50.99.2070 5.0 RICHEDIT20W na na na
Office 2007 (Office 12) RichEdit Version 6.0 12.0.6768.5000 12.0.6768.5000 RICHEDIT60W +msptls.dll na na na
Office 2010 (Office 14) RichEdit Version 6.0 14.0.7155.5000 14.0.7155.5000 RICHEDIT60W +msptls.dll na na na
Office 2013 (Office 15) RichEdit Version 8.0 15.0.4599.1000 15.0.4599.1000 RICHEDIT60W +msptls.dll na na na
Office 2016 (Office 16) RichEdit Version 8.0 16.0.11425.20024 16.0.11425.20024 RICHEDIT60W +msptls.dll na na na
Office 2019 (Office 16) RichEdit Version 8.0 16.0.11425.20024 16.0.11425.20024 RICHEDIT60W +msptls.dll na na na
No change in versions between Office 2016 and Office 2019, latest updates I got today. Very weird, but I just confirmed that is the way Microsoft is doing it. I have not noticed any difference at all between Office 2016 and Office 2019, except the Splash Screen says 2016 in one and 2019 on the other. But am not a real Office user.
I can't test Riched20.dll versions of Office until I make a 64-bit program because I have no x86 versions of Office.
Actually, my Office 2019 is x86, and it works for the CodeProject demo when I add msptls.dll and class RICHEDIT60W
Quote from: hutch-- on April 06, 2019, 12:35:22 AM
I have good reason to stick with Rich Edit 2/3, it works from old 32 bit OS versions up to current Win 10 64 bit. I have few aspirations of more complex tasks but if I did it would be a version that was available from Win 7 64 bit upwards.
thanks for the info,good for compability reason to stick to a older rich edit,so I can use it from windows 1.0 to the coming windows 3000 :)
I want to get asian rich edit version,it supports IME and vertical unicode characters ala japanese
actually I suspect I have a ml newer version problem,when 16bit coding it annoys me with requiring cs:,ds:,es: with all mov's to memory adresses otherwise it reports error,but my older code I seen I getaway with none of that???
I have had no problems with rich edit 2/3 in 64 bit Win10. Its good for about 750 meg so its big enough. The last time I wrote 16 bit MASM code was for MS-DOS back in about 1994 so I would be a bit out of date there but if you are going to write bigger that 64k COM you are stuck with segment addressing which I always hated. Unless its a touch of nostalgia or perhaps 16 bit demos, I don't see much reason to write 16 bit real mode code.
Any modern version of rich edit will handle the unicode range so multi lingual editors are no big deal to do and with a late version of Windows, you have the font support as well.
Quote from: hutch-- on April 06, 2019, 03:40:55 AM
I have had no problems with rich edit 2/3 in 64 bit Win10. Its good for about 750 meg so its big enough. The last time I wrote 16 bit MASM code was for MS-DOS back in about 1994 so I would be a bit out of date there but if you are going to write bigger that 64k COM you are stuck with segment addressing which I always hated. Unless its a touch of nostalgia or perhaps 16 bit demos, I don't see much reason to write 16 bit real mode code.
Any modern version of rich edit will handle the unicode range so multi lingual editors are no big deal to do and with a late version of Windows, you have the font support as well.
judge for yourself if its fast enough and read whats my intention with why get away with only 16bit code
http://masm32.com/board/index.php?topic=7324.0 (http://masm32.com/board/index.php?topic=7324.0)
and about unicode,the idea of gdi game based on unicode characters was inspired from discover there is also unicode chess pieces,cards and mahjong pieces on unicode site among all the other pdfs about for arabic,chinese,japanese... and the need to stack mahjong pieces ontop of each other to make a mahjong game
but you need to tell the user to install foreign language packs,needed to use your for example a japanese version of qeditor
Magnus,
Have a look at an editor in MASM32 called "uniedit.exe". It ran on XP and if you are using an OS from Win7 upwards, all of the east Asian fonts are present. On XP you had to load language packs but not on later OS versions. QE is an ASCII code editor, it will never be multi-lingual.
Quote from: hutch-- on April 06, 2019, 10:32:48 AM
Have a look at an editor in MASM32 called "uniedit.exe". It ran on XP and if you are using an OS from Win7 upwards, all of the east Asian fonts are present. On XP you had to load language packs but not on later OS versions. QE is an ASCII code editor, it will never be multi-lingual.
Thanks
In a way qeditor becomes multilingual when it's used by a multilingual coder,comments in their native language,, 5000+Japanese unicodes in. Data section, use it for java
I have updated the article with a table of RichEdit controls by Windows OS and MS Office. People interested can also download the respective Excel sheet I am attaching here. I have also found a better way to advance the caret after embedding the image and have updated the article with that.
I have been talking that for older versions of the RichEdit we can embed .BMP files. I wasn't meaning display clickable links but show the real image. I also mentioned that it is difficult, in particular for bitmaps in the resources (it is easier when loaded from file or dropped from the clipboard). I know how to do it in C++ and in Delphi but I think it is extremely difficult to do it either in ASM or in C.
May be somebody want to try. :idea: :t :biggrin:
Quote from: AW on April 08, 2019, 03:25:26 AM
I have been talking that for older versions of the RichEdit we can embed .BMP files. I wasn't meaning display clickable links but show the real image. I also mentioned that it is difficult, in particular for bitmaps in the resources (it is easier when loaded from file or dropped from the clipboard). I know how to do it in C++ and in Delphi but I think it is extremely difficult to do it either in ASM or in C.
May be somebody want to try. :idea: :t :biggrin:
Let me answer to my own post :lol:
I have solved it for C, which means that it is automatically solved for ASM, but I will not do it.
The real problem is that C does not handle classes. However, C handles structures :biggrin:
For people that want to try I will leave here a C++ reference link:
http://www.ucancode.net/VC_Library_Control_Tool/Insert-a-bitmap-file-HBITMAP-into-Rich-Edit-Control-COleDataSource-CF_BITMAP-STGMEDIUM-vc.htm
I will not post the C solution here, may be I will on CodeProject.
Those who want to see C, a simple example of InsertBitmap and IDataObject in C code.
It just insert a one bitmap to richedit.
Quote from: TimoVJL on April 09, 2019, 06:32:24 AM
Those who want to see C, a simple example of InsertBitmap and IDataObject in C code.
It just insert a one bitmap to richedit.
Well done. :t
People could confirm that there is no easy way to do it.
Quote from: TimoVJL on April 09, 2019, 06:32:24 AM
Those who want to see C, a simple example of InsertBitmap and IDataObject in C code.
It just insert a one bitmap to richedit.
Excellent, Timo :t
What's the difference between the two versions? Attached a version by Mike Lytle, unfortunately I can't get it to work on my C installations. There is also the old MSDN Q220844: HOWTO: Insert a Bitmap Into RTF Document Using RichEdit Control (https://jeffpar.github.io/kbarchive/kb/220/Q220844/)
Last one is just a bit cleaner ;)
How to Use OLE in Rich Edit Controls (https://docs.microsoft.com/en-us/windows/desktop/Controls/using-rich-edit-com)
EDIT: OleCreateFromFile() needs full path name.
That's it:
(https://www.dropbox.com/s/qtbprfa47iaryt2/crappybmps2.png?dl=1)
I have updated the article with a demo, now using the TOM2's TextRange2::InsertImage() method.
The demo loads a text then when you press the button replace spaces with .pngs.
(https://www.dropbox.com/s/1jwqzy3k515m8ev/preinsert.png?dl=1)
(https://www.dropbox.com/s/pndkbwrzmlv4ucg/posinsert.png?dl=1)
The demo is in C++, but is easily translated to C and then to ASM, as usual. :lol:
The real difference between C++ and C, in this case, is in the syntax for calling the interface methods.
For example, in C++:
hr = pDocument2->GetSelection2(&pSelection2);
in C:
hr = pDocument2->lpVtbl->GetSelection2(pDocument2 ,&pSelection2);
In ASM, using the coInvoke macro, it will become similar to the C syntaxe. If you don't use the coInvoke macro, it is a lot of fun but is difficult to figure out.
Nice demo. Your program is Windows 8+ only, though. Depending on the Office installation, a Win7 user (like me) may find the ITextRange2 interface in C:\Program Files (x86)\Common Files\Microsoft shared\OFFICE12\RICHED20.DLL but not in C:\Program Files (x86)\Common Files\Microsoft shared\OFFICE12\RICHED20.DLL
I don't know if the problem for Windows 7 is the ITextRange2 or the ITextSelection2 interface, would need to check. I have used the ITextSelection2 to reach the ITextRange2 but it can be reached as well from the ITextDocument2.
You may be right, although I have doubts you can use InsertImage from pRange2 with Office 2007/Office 12. It is so old.
MS Office 2013 riched20.dll is version 8, insert image works.
const GUID IID_ITextDocument2={0xC241F5E0,0x7206,0x11D8,0xA2,0xC7,0x00,0xA0,0xD1,0xD6,0xC6,0xB3};
IID_ITextDocument2 was exported from that dll.
In TLB InsertImage was hidden by missing line after GetMathFunctionType() HRESULT (STDMETHODCALLTYPE *InsertImage)(ITextRange2 *This,LONG,LONG,LONG,LONG,BSTR,IStream*);a silly test if (pDocument) {
IStream *pStream = NULL;
ITextRange2 *pTextRange2;
HRESULT hr = SHCreateStreamOnFile(L"test.png", STGM_READ | STGM_SHARE_DENY_NONE, &pStream);
hr = pDocument->lpVtbl->Range2(pDocument, 0, 0, &pTextRange2);
hr = pTextRange2->lpVtbl->InsertImage(pTextRange2, 1000, 1000, 0, 0, L"test.png", pStream);
}
BTW: Tested in Windows 7.
For Office 2016, and probably 2019, InsertImage was the latest method added to ITextRange2. It seats just after GetMathFunctionType.
I have an old computer with Office 14 and its Riched20.dll has no InsertImage method. The latest one is GetMathFunctionType.
If EM_INSERTIMAGE works, InsertImage might be there too.
15.0.4693.1000 was under test.
deleted