CRichEditCtrl contents from RTF file
in [MFC]
|
Prev: Task
Next: compile error note
From: Goran on 28 Apr 2010 10:34 On Apr 28, 2:51 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote: > I just reviewed the code, and I don't even SEE anyplace where there is a major disconnect > because of Unicode! Could you try to correlate your comment with particular lines of > text? I tried StreamIn with a file that contains unicode text (BOM and all). This doesn't work. I tried both SF_RTF and SF_TEXT. SF_TEXT gave me s p a c e s e p a r a t e d t e x t (control probably ignored every other 0 from UTF-16). SF_RTF gave me nothing. Vanilla project (Unicode), with rich edit control inside a dialog. I didn't look too much, but there seems to be something wrong WRT RichEdit and Unicode. Or am I missing something? > >>> BOOL CREPage::OnInitDialog() > >>> { > >>> CBasePage::OnInitDialog(); > > >>> if (m_strRTFFilePath.GetLength()) > >>> { > >>> m_RECtrl.ShowScrollBar(SB_VERT, TRUE); > >>> CFile eulaFile(m_strRTFFilePath, CFile::modeRead); > >> **** > >> Note that this constructor must be in a try/catch(CFileException * e) block, since if > >> there is a problem (such as the file does not exist along the path) then it will throw an > >> exception > >> **** No, exception-safety-wise, this is a bad idea. There's potentially a host of exceptions that might be thrown. If nothing else, using catch(CFileException*) is not safe for future changes. See my post above for a better "canonical" OnInitDialog. I am reacting because this is a common mistake when people work with exceptions: they are trying to guess what types of exceptions will be thrown, and they do that way, way too much. You did it here. Well, that's not how it's done. Rather, one presumes unknown exception (which, in context of MFC corresponds to base class, CException*) and acts on the fact that there might be one. Only in specific cases catches a specific exception type. But this ain't such a case. Whatever happens, if there's an error, this dialog should most likely end and display an error message. Hence, e.g. EndDialog(IDCANCEL) and ReportError on a caught __base__ exception type are pretty much OK. Goran.
From: Goran on 28 Apr 2010 10:43 On Apr 28, 3:59 pm, JY <s...(a)nospamgroup.com> wrote: > "Joseph M. Newcomer" wrote: > > Although you test the "remaining" field, I don't see where you set it. > > > Have you single-stepped any of this to see where it is terminating the read, and why? Or > > put breakpoints on the 'return 1' statements? > > joe > > I do it in OnInitDialog(), I missed that line earlier: > StreamInCookie streamIn; > streamIn.file = &eulaFile; > streamIn.remaining = (DWORD_PTR)eulaFile.GetLength(); > > EDITSTREAM es; > ...... > Yes, I've set breakpoints and noticed that the callbacks don't come after > some time. At the last point the callback was received, the "remaining" field > was 36671, and 0 was successfully returned from the callback. > > The size of the EULA RTF file is quite big, about 13 pages (about 140 KB).. > Not sure if it's got anything to do with the size. It seems that file size is the issue. In my test project, I see that I can read exactly 32kB of text, then it stops calling me back. Meh. Is that what you see? Goran.
From: Hector Santos on 28 Apr 2010 12:54 Joseph M. Newcomer wrote: > I just reviewed the code, and I don't even SEE anyplace where there is a major disconnect > because of Unicode! Could you try to correlate your comment with particular lines of > text? I'm sorry joe, I just reacted to the idea that all that was necessary to address the main issue - the OP issue of handling UNICODE RTF files with CRichEditCtrl. > Unicode is important because you can't address a large number of international markets > without having support for it. Well, I understand your point, but I don't agree it a requirement. We have to agree to have different opinions on it. We have international customers and the "pressure" simply isn't there for our products. I think it is somewhat ludicrous that UNICODE continues to be a thorn on the side for coders and in my philosophical opinion, one should not have to pay some much mental attention with coding issues which is really to one small aspects of the total system. It become more of a larger issue than necessary. So while you can make it work for an application coding all the necessary syntax, at some point your interfacing with the outside world and other system or sub-system components can and seems to always do, create conflicts. Now I admit, UNICODE is one of the few items that I am not very keen with (don't have all the nits about it). Yet, I am not looking forward to wasting a few years mastering it when I believe it is a temporary KLUDGE in coding. While newer languages still have interfacing issues, the language syntax itself is less of an issue. > As I regularly tell my students: If your manager comes in and says, "We just made a big > sale to <Korea, Japan, China> and we need Unicode support in the app NOW! How long will > it take?" you have two possible answers: > > 1. Give me a couple days and I'll tell you how many weeks will be required > 2. When can you get the translator in here? Well, look at the other side. If you made a big sale it has to be based on the current english only ANSI production and the sale was for what it was worth for them - not that it spoke their native tongue. It usually means the customer was able to work with english only product line. I believe most foreign customers that deal with american products speak english. We never needed an interpreter, and for the record, we have at least one customer in nearly every civilized country and nation in the world, in fact, during the Bosnian War, I refuse the sale of our product to the "bad side" government run news agency. The CIA, a customer of ours too, really appreciated that. We have language resource files and multi-language editing tools for displays and this is the one area where we have a few demands to make it UNICODE or more specifically UTF8 ready, and its mostly for the web side. So since the stock HTML templates are designed to be customizable, most customers can handle it themselves. The areas were Internationalization is becoming more important, FOR US, is with the email system, like with SMTP in dealing with proper email addresses. The context itself is not an issue since that is controlled by MIME and MIME rendering. But the main products? the configuration tools? the servers? the monitors? the services that have no interface, absolutely little to no pressure to make it UNICODE. Now, if we did design for it and marketed it such, will it help increase the marketability in countries like China? I'm sure it will. But for us, the product itself is the main attraction, not that it can communicate in their native language. It would be nice, but its not the reason for our particular products. I"m sure product vendors are in the same position and thats because most people do know english. Will that change with China? I'm sure it will become more important as China continue to become more prominent in many areas. But just consider one of our larger US customer who deals with China more now, the chinese nor our customer has demanded a chinese interface - yet. If it was available, I'm sure our customers would leverage it because they also have to deal with china more. So it will definitely help in marketing the product there. But there is no requirement or demand for it - yet. > Which do you want to give, you are the programmer? Which do you want to hear, if you are > the manager? I'm the CTO, and quality and performance is more important. As mentioned above, Internalization is becoming more important in the communication product, such as EMAIL (i.e, SMTP, POP3) and more request for stock HTML templates with different languages - none of which the EXE, DLLS themselves require UNICODE compilation. That is only important in the native GUI interfaces, but for remote displays, that is different. Compiling in UNICODE does not fix that problem of dealing with Mix interfaces. In fact, compiling in UNICODE will break the ANSI display interfaces or make it more complex to deal with it in mixed environments. > The reason I don't understand why Unicode is a problem is that I have been writing > Unicode-aware apps since 1996, and I don't know any other way to write an app today. Ok, but unfortunately, for most programmers, it continues to be a repeated issue. Just look at the postings - a good bit of the time the usual suspect is related to UNICODE. > And > a number of those have been transitioned to Unicode seamlessly and painlessly. So I > really don't have any patience when people start whining about Unicode; been there, done > that, it's easy and straightforward! I don't agree it is easy and straightforward. Case in point - the OP issue, the interface issues. Like you, I have vast experience across the board and have a very good feel for whats easy and straightforward. IMTO, UNICODE is not one of them - just look at all the postings related to it. > The mass of code below has NOTHING to do with Unicode and EVERYTHING to do with how > complex the interface to a Rich Edit Control is. Right, it had nothing to do with the OP issue. Does it read in a UNICODE RTF correctly? Anyway, lets not talk pass ourselves. I see your points, I agree it becoming more important, unfortunately, I also believe it is not a requirement and its without a doubt, a PITA! I know what is easy and straightforward and what isn't as much as you do. Do I need to begin considering it more? Yes, do I break everything to make everything exclusively Unicode, absolutely not. -- HLS
From: Goran on 29 Apr 2010 05:26 On Apr 28, 4:43 pm, Goran <goran.pu...(a)gmail.com> wrote: > On Apr 28, 3:59 pm, JY <s...(a)nospamgroup.com> wrote: > > > > > "Joseph M. Newcomer" wrote: > > > Although you test the "remaining" field, I don't see where you set it.. > > > > Have you single-stepped any of this to see where it is terminating the read, and why? Or > > > put breakpoints on the 'return 1' statements? > > > joe > > > I do it in OnInitDialog(), I missed that line earlier: > > StreamInCookie streamIn; > > streamIn.file = &eulaFile; > > streamIn.remaining = (DWORD_PTR)eulaFile.GetLength(); > > > EDITSTREAM es; > > ...... > > Yes, I've set breakpoints and noticed that the callbacks don't come after > > some time. At the last point the callback was received, the "remaining" field > > was 36671, and 0 was successfully returned from the callback. > > > The size of the EULA RTF file is quite big, about 13 pages (about 140 KB). > > Not sure if it's got anything to do with the size. > > It seems that file size is the issue. In my test project, I see that I > can read exactly 32kB of text, then it stops calling me back. Meh. Is > that what you see? > > Goran. Obvious resolution (stupid programmer can't find in online help): LimitText with... well, a bigger limit! Goran.
From: JY on 29 Apr 2010 08:42
Yes, thanks LimitText() with a higher limit works. But one issue that still remains is that the original RTF file that I received from the customer does not show up at all in the control. It behaves the same way even with the sample from CodeProject I mentioned about yesterday. I had to open the same document in WordPad and just save it back, and then use it. I didn't make any other changes in WordPad. But the size of the file dropped from 140 KB to 72 KB when I did this. - JY. "Goran" wrote: > On Apr 28, 4:43 pm, Goran <goran.pu...(a)gmail.com> wrote: > > On Apr 28, 3:59 pm, JY <s...(a)nospamgroup.com> wrote: > > > > > > > > > "Joseph M. Newcomer" wrote: > > > > Although you test the "remaining" field, I don't see where you set it.. > > > > > > Have you single-stepped any of this to see where it is terminating the read, and why? Or > > > > put breakpoints on the 'return 1' statements? > > > > joe > > > > > I do it in OnInitDialog(), I missed that line earlier: > > > StreamInCookie streamIn; > > > streamIn.file = &eulaFile; > > > streamIn.remaining = (DWORD_PTR)eulaFile.GetLength(); > > > > > EDITSTREAM es; > > > ...... > > > Yes, I've set breakpoints and noticed that the callbacks don't come after > > > some time. At the last point the callback was received, the "remaining" field > > > was 36671, and 0 was successfully returned from the callback. > > > > > The size of the EULA RTF file is quite big, about 13 pages (about 140 KB). > > > Not sure if it's got anything to do with the size. > > > > It seems that file size is the issue. In my test project, I see that I > > can read exactly 32kB of text, then it stops calling me back. Meh. Is > > that what you see? > > > > Goran. > > Obvious resolution (stupid programmer can't find in online help): > LimitText with... well, a bigger limit! > > Goran. > . > |