Yes, it is. But using bitwise operators is more straight forward way.
Isn't EM_GETLANGOPTIONS returning a Byte value that represents a Set of operators?
I have wondered all along as to how...
opt:=opt and not IMF_AUTOFONT;
... could work. It may be a Delphi method. Likewise, isn't it testing for a true/false condition instead of a value?
What about the "odd behavior" that I cited on Reply #3, and that it had not turned off the font switching?Remember, you've had a similar problem with spaces and commas.
But one programmer commented that RichEdit 3 had altered the EM_GETLANGOPTIONS method. He said he had to go back to version 2. When he did it operated fine. He did not specify what was changed. Do you think that our current version has assigned a different value to IMF_AUTOFONT.I'm thinking that the solution is very fragile.
But EM_GETLANGOPTIONS returns a single value, and it is 130... very large.That is because the value returned is value that can consist of multiple flags. Those names listed all represent a bit (or bit combination) and as such are flags. Figure out which bit it is that you need and filter it from that return value.
opt:=opt and not IMF_AUTOFONT;
where opt originally is 130, what you get is the following:SendMessage(PageMemo.handle, EM_SETLANGOPTIONS, 0, 0);
To test it I tried to remove Msftedit.dll from my system, but the system just reinstalled it.please don't do such horrible things to your system :) it doesn't deserve it.
I was planning to add explicit dll and richedit class selection for Windows.and now it is done - r5289 allows to override richedit's class used by RichMemo.
But for whatever reason it was not completed.
How do I set the class?You need to use the latest revision.
/* Richedit2.0 Window Class. */
#define RICHEDIT_CLASSA "RichEdit20A"
#define RICHEDIT_CLASS10A "RICHEDIT" // Richedit 1.0
#ifndef MACPORT
#define RICHEDIT_CLASSW L"RichEdit20W"
#else /*----------------------MACPORT */
#define RICHEDIT_CLASSW TEXT("RichEdit20W") /* MACPORT change */
#endif /* MACPORT */
#if (_RICHEDIT_VER >= 0x0200 )
#ifdef UNICODE
#define RICHEDIT_CLASS RICHEDIT_CLASSW
#else
#define RICHEDIT_CLASS RICHEDIT_CLASSA
#endif /* UNICODE */
#else
#define RICHEDIT_CLASS RICHEDIT_CLASS10A
#endif /* _RICHEDIT_VER >= 0x0200 */
)I am looking at r5289. It doesn't have anything in it for RichEdit20W or RICHEDIT_CLASSW nor anything called for in your post.The change itself is to make win32 implementation more dynamic, so any class could be used.
Isn't RICHED32.DLL for RichEdit version 1? Wouldn't I want to try RICHED20.DLL first?You're right, you should try RICHED20.DLL first
Also, should I still do those edits to Win32RichMemoProc?No, please revert any changes made to Win32RichMemoProc.
raised exception win32richmemo line 494makes sense. r5290 fixes the issue.
On attempting to switch back to MSFTEDIT for a test it raised an exception...The combination of .dll and the class name doesn't exist. The proper class name is RichEdit50W
code used...
LoadLibrary('MSFTEDIT.DLL'); // 'RICHED32.DLL' 'RICHED20.DLL' 'MSFTEDIT.DLL'
RichEditClass:= 'RichEdit20W'; // specifying the class
I tracked down the problem. RICHED20.DLL was built prior to Syriac entering the Unicode system. Since its index values are higher than what existed at the time of RICHED20.DLL, it refuses to access them... another "better idea" by Microsoft.
How to prevent crashes when pasting into the text editor - Kinook Software Forums.url
MSFTEDIT - (v7.5) 10.0.10240.16386.dll
Probleem-versies.txt
RICHED20 - (v3.0) 5.30.23.1230 (winXP).DLL
RICHED20 - (v3.1) 5.31.23.1229 (win7).DLL
RICHED20 - (v3.1) 5.31.23.1230.DLL
RICHED20 - (v3.1) 5.31.23.1231 (win10).DLL
RICHED20 - (v4.0) 5.40.11.2210 (OfficeXP).DLL
RICHED20 - (v5.0) 5.50.99.2050 (Office2003).DLL
RICHED20 - (v6.0) 12 MSPTLS.DLL
RICHED20 - (v6.0) 12.0.6606.1000.DLL
RICHED20 - (v6.0) 14 MSPTLS.DLL
RICHED20 - (v6.0) 14.0.4750.1000.DLL
RICHED20 - (v8.0) 15 MSPTLS.DLL
RICHED20 - (v8.0) 15.0.4420.1017 (b) msptls.dll
RICHED20 - (v8.0) 15.0.4420.1017 (b).DLL
RICHED20 - (v8.0) 15.0.4420.1017.DLL
RICHED20 - (v8.0) 15.0.4659.1000.DLL
So you could try the 5.4, 5.5 or even 12 through 15 versions.I have found that my system will not permit me to install different versions for MSFTEDIT and RICHED20. It lets me copy/paste and overwrite, but then it politely reinstalls the original version without giving any notice.You don't have to install/reinstall RICHED20.DLL. You can just put it in the .exe directory (with your program) and it will be loaded. The program directory has priority over the C:\WINDOWS\SYSTEM32 or any other directory.
I forgot to stress... they disabled the function that will turn off Font-Binding. They don't want us to rely on RTF.Do you have documentation of the fact that they "disabled" this function?
Just yelling that they disabled it and are working against some feature isn't going to fix it. Especially if it was done accidentally.
I am building a Unicode editor that uses the MSFTEDIT.DLL. My application is for Biblical languages (English, Hebrew, Syriac, and Greek), and they need to be typed as mixed language paragraphs for comparison and explanation. The editor displays the mix with no malfunction, but when I save the file and load it again, it switches the fonts. Curiously the biggest issue is with a Unicode English font (Calibre), but it also happens with Greek texts. It will switch to the English in the first Non-English font that was used. By my objective this is unacceptable. The English font is named in the RTF file, and the font is present in the system folder… So why switch the font?
I have tried to eliminate this behavior by using the EM_SETLANGOPTIONS function. The following is how I have implemented this:
SendMessage(PageMemo.handle,EM_SETLANGOPTIONS,WPARAM(0),LPARAM((SendMessage(PageMemo.handle,EM_GETLANGOPTIONS,WPARAM(0),LPARAM(0)) and not(IMF_AUTOKEYBOARD))));
SendMessage(PageMemo.handle,EM_SETLANGOPTIONS,WPARAM(0),LPARAM((SendMessage(PageMemo.handle,EM_GETLANGOPTIONS,WPARAM(0),LPARAM(0)) and not(IMF_AUTOFONT))));
SendMessage(PageMemo.handle,EM_SETLANGOPTIONS,WPARAM(0),LPARAM((SendMessage(PageMemo.handle,EM_GETLANGOPTIONS,WPARAM(0),LPARAM(0)) and not(IMF_DUALFONT))));
The above procedures establish the settings, but they do not stop RichEdit from switching fonts.
Specifically I am using the RichMemo component by the Lazarus FreePascal compiler, and am operating on a Windows XP PRO SP3 computer. RichMemo serves as a wrapper for the MSFTEDIT DLL.
Can you help me with this issue?
Rick
RICHED32.DLL: v1.0
C:\Windows\System32\RICHED32.DLL
Wrapper Dll for Richedit 1.0
In XP: File version: 5.1.2600.0
In W7: File version: 6.1.7601.17514
In W10: File version: 10.0.10586.0
ClassName: 'RICHEDIT'
RICHED20.DLL: v2.0
C:\Windows\System32\RICHED20.DLL
Rich Text Edit Control, v2.0
5.0.150.0
Microsoft RichEdit Control, version 2.0
ClassName: 'RichEdit20A'
RICHED20.DLL: v3.0, in XP:
C:\Windows\System32\RICHED20.DLL
Rich Text Edit Control, v3.0
Product version: 3.0
File version: 5.30.23.1230
ClassName: 'RichEdit20A'
RICHED20.DLL: v3.1, in W7, W10:
C:\Windows\System32\RICHED20.DLL
Rich Text Edit Control, v3.1
Product version: 3.1
File version: 5.31.23.1230
File version: 5.31.23.1231
ClassName: 'RichEdit20A'
Windows XP, Windows 7 : v4.1
C:\Windows\System32\MSFTEDIT.DLL
Rich Text Edit Control, v4.1
Product version: 4.1
XP SP3: File version: 5.41.15.1515
W7: File version: 5.41.21.2510
ClassName: 'RichEdit50W'
My question is whether the 20A suffix might make them perform better, and if so, is there a function that will format Unicode input as ANSI code to match the 20A parameter? It is only a question on my part, and I assume that you are the best person to present it to.This is unlikely.
Andrew West on 11 Jul 2007 7:45 AM:
There are a couple of reasons why I personally think that an option to show characters with fallback/substitution/linking applied would not be such a cool idea.
Firstly, I'm sure that I am not the only person who loathes the way Microsoft's font substitution works. When I select a specific font to render my text with then what I really want is the application to respect my choice of font and not act as if it knows better then me and use some different font.
For example, in Notepad or Word if I select Code2000 to display some Syriac text it will be displayed with Estrangelo Edessa and there is no way I can get it to use Code2000 even though Code2000 supports Syriac just as well as Estrangelo Edessa does (and even worse in Word the font dropdown box shows Code2000 as the selected font when you click on the text, deceiving users into thinking that they have successfully
applied the font to the text when they haven't). If there was a registry setting where the user could define the font to use as a fallback for each script (or if there was an option to disable font substitution at the application level) then it wouldn't be so bad, but as it is, from a user's perspective the font substitution behaviour is unpredictable and often unwanted.
Secondly, font substitution behaviour is application-specific. Microsoft apps such as Word and Notepad do apply font substitution and linking, but many non-Microsoft apps such as OpenOffice.org and BabelPad do not. Thus if charmap showed characters with fallback/substitution/linking applied this would not necessarily be what you will get if you select the same font in some other application.
Incidentally, when you told us in September (http://blogs.msdn.com/michkap/archive/2006/09/03/737553.aspx) that charmap on Vista would still not display anything beyond the BMP and would still only display the
very limited list of Unicode blocks (nothing beyond Unicode 2.0 for @%#'$ sake !!!) I was stunned. How hard could it possibly be to update charmap to show everything up to and including Unicode 5.0 ?
So I think that a far more useful feature for charmap would be the ability to display all currently defined Unicode characters.
His remark about the font changing, but the font box still shows it by the original name, is also something that I have experienced. It's a sanctioned virus.Well, this is not a virus. This is an intentional behavior of the system.
In Google's own words... The name "noto" is to convey the idea that Google’s goal is to see “no more tofu” (no'to).
I assume that none of them are vegetarians.