TRichMemo Windows-Only Multicolor Line and HTML Links Issue

[Phil]

I'm looking for something cross-platform so WebView isn't ideal, plus I don't strictly speeding need any editing abilities.  Basically, what I need is whatever you'd use for the chat window in AOL Instant Messenger.  Something that can handle viewing colors, text, links, maybe images and adding new lines.  It also needs wordwrap.

I've looked THtmlViewer and it is very promising.  It definitely can view colors, text and links.  I'm assuming it can also view images, but haven't tested it.  It uses wordwrap.  The only thing I haven't been able to find yet is adding a line.

Compile and run the example FrameDem project to see full capabilities, including display of embedded images in various formats.

I doubt if most HTML viewers would include the ability to add a line to an already loaded page. But I doubt if you would see any lag with a long list. Try loading a large HTML file and see how fast it is and whether the display refresh is fast enough.

Thanks.

-Phil

[evoshroom]

I doubt if most HTML viewers would include the ability to add a line to an already loaded page.

I doubted that too, which is why I hadn't looked into HTML viewers before.  I sort of assumed without this ability, reloading long chats would have notable lag.  I mean web pages don't load instantly, so I figured reloading a web page every time you added a line would be a bad idea.

But I doubt if you would see any lag with a long list. Try loading a large HTML file and see how fast it is and whether the display refresh is fast enough.

I've been testing this and so far you seem to be right, which surprised me.  At least with just formatted text, the performance seems okay in my limited testing and I already know that the HTML is going to prevent the ungodly coloration bugs that seem to plague TRichMemo, so this is looking pretty positive or at least good enough that I can actually integrate it and cross my fingers.  Thanks for the suggestion!!!

One last thing though.  THTMLViewer has a known bug apparently on Carbon where the scrollbar max's value is always 3/4ths down the box instead of all the way down at the bottom where it should be when scrolled to the bottom of available text.  Any idea why that is and if it is possible to fix or work around in any way?

[Phil]

I doubt if most HTML viewers would include the ability to add a line to an already loaded page.

I doubted that too, which is why I hadn't looked into HTML viewers before.  I sort of assumed without this ability, reloading long chats would have notable lag.  I mean web pages don't load instantly, so I figured reloading a web page every time you added a line would be a bad idea.

Many Web sites also download a lot of JavaScript and execute that as well as displaying the HTML (Google "analytics" and the like). If you're using Windows, try Firefox with the NoScript extension installed and see how much stuff it blocks by default. Some pages will download JS from several sites - clearly, this has an impact on loading performance.

One last thing though.  THTMLViewer has a known bug apparently on Carbon where the scrollbar max's value is always 3/4ths down the box instead of all the way down at the bottom where it should be when scrolled to the bottom of available text.  Any idea why that is and if it is possible to fix or work around in any way?

That's a good question. Even though I used a Mac almost exclusively in porting this package, that was one thing I never solved. I haven't looked at the code for this package in about 1.5 years - I'll look at my notes and see if there are any ideas that you could follow up on.

Also, a mouse wheel doesn't work either, on any platform I don't think. That might be easy to fix.

Thanks.

-Phil

[evoshroom]

I doubt if most HTML viewers would include the ability to add a line to an already loaded page.

I doubted that too, which is why I hadn't looked into HTML viewers before.  I sort of assumed without this ability, reloading long chats would have notable lag.  I mean web pages don't load instantly, so I figured reloading a web page every time you added a line would be a bad idea.

Many Web sites also download a lot of JavaScript and execute that as well as displaying the HTML (Google "analytics" and the like). If you're using Windows, try Firefox with the NoScript extension installed and see how much stuff it blocks by default. Some pages will download JS from several sites - clearly, this has an impact on loading performance.

Sadly, more testing revealed what I feared.  The chat starts to get slow and lag the program when the amount of text in it is large.  However, everything else about this component is absolutely perfect for what I'm doing.  As someone with some experience working with THTMLView, before I start trying to mess with the component itself, do you think it would be possible to code something like I'm looking for, an AppendFromString function?  Basically, I'd want the function to render the HTML independently and then append it to the HTML that already exists in rendered form without re-rendering the whole thing.  That addition would make this the perfect component for me.  Is it remotely possible? 

[Phil]

Sadly, more testing revealed what I feared.  The chat starts to get slow and lag the program when the amount of text in it is large.  However, everything else about this component is absolutely perfect for what I'm doing.  As someone with some experience working with THTMLView, before I start trying to mess with the component itself, do you think it would be possible to code something like I'm looking for, an AppendFromString function?  Basically, I'd want the function to render the HTML independently and then append it to the HTML that already exists in rendered form without re-rendering the whole thing.  That addition would make this the perfect component for me.  Is it remotely possible?

I assume you have a _lot_ of text. And that you're not reading text from a file, but rather loading longer and longer strings, which loads slower and slower.

Try speeding up the parser before doing anything else. Open the htmlcomp.lpk package (Package | Open) and in Options on the Other tab, delete the conditional -dDebugIt. Now rebuild Laz and test your app again. The package should now be compiled with range-checking, etc. turned off. If that speeds up things, then you could look at the code in readhtml.pas where the parsing takes place and see if there are other little changes here that could speed up parsing even more.

To make sure you've built without DebugIt, look at HtmlComp.compiled (text file) under package/units and make sure it doesn't show -dDebugIt.


Note that when you move up to the real deal, WebView, it appears to have the kind of things you need - see the replaceSelectionWithMarkupString: method:

http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/WebKit/Classes/WebView_Class/Reference/Reference.html

Thanks.

-Phil

[evoshroom]

I assume you have a _lot_ of text.

Not really.  I start out with no text and then it gets longer as the chat log gets longer.  The chat log is for an application in which every action in the application posts an entry to the chat log, so it gets long fast, but by the time the slow down starts it isn't that long.  One part of the application has a list of things you can scroll through with a key bind, each item you pass on the list causes a chat entry, plays a sound and activates a graphic.  If I just continuously do this within 20 or 30 seconds it become apparent that each item is taking longer and longer to do and playing its sound slower and slower because the chat log is adding an artificial delay.  After maybe 60 seconds of this, the delay starts becoming apparent in other ways.  For example, if you click an item 4 times that posts to the chat, the posts take time to process and happen visibility after you clicked.

And that you're not reading text from a file, but rather loading longer and longer strings, which loads slower and slower.

That is correct.  It is a chat dialog, not a saved file.

Try speeding up the parser before doing anything else. Open the htmlcomp.lpk package (Package | Open) and in Options on the Other tab, delete the conditional -dDebugIt. Now rebuild Laz and test your app again. The package should now be compiled with range-checking, etc. turned off. If that speeds up things, then you could look at the code in readhtml.pas where the parsing takes place and see if there are other little changes here that could speed up parsing even more.

To make sure you've built without DebugIt, look at HtmlComp.compiled (text file) under package/units and make sure it doesn't show -dDebugIt.

I did all of this.  I'm sure it sped things up but it didn't help the basic issue, which is that a larger and larger section of HTML is being reprocessed, when only the new entry to the list should be processed as HTML and the old parts should be left in their pre-processed states.

Note that when you move up to the real deal, WebView, it appears to have the kind of things you need - see the replaceSelectionWithMarkupString: method:

I mentioned this before.  I can't ever move to WebView.  My code needs to be cross-platform.

I'm going to go digging through the code of THTMLView now itself to see how hard it would be to code a new ApprendFromString procedure.  If you have any further ideas or suggestions, feel free to let me know.  Thanks!

[Phil]

I'm going to go digging through the code of THTMLView now itself to see how hard it would be to code a new ApprendFromString procedure.  If you have any further ideas or suggestions, feel free to let me know.  Thanks!

The unparsed HTML will be in FDocumentSource; the parsed tags will be in FSectionList. Since the properties that reference these fields are read-only and the fields are in the protected section of the class declaration, you'll need to subclass THtmlViewer to get at them.

But it would appear as though simply appending new unparsed HTML to FDocumentSource and the parsed HTML to FSectionList might be all that's needed (followed by a Repaint or something). But it could also be somewhat more complicated than that.

Thanks.

-Phil

[evoshroom]

The unparsed HTML will be in FDocumentSource; the parsed tags will be in FSectionList. Since the properties that reference these fields are read-only and the fields are in the protected section of the class declaration, you'll need to subclass THtmlViewer to get at them.

But it would appear as though simply appending new unparsed HTML to FDocumentSource and the parsed HTML to FSectionList might be all that's needed (followed by a Repaint or something). But it could also be somewhat more complicated than that.

What I did first was mirror LoadFromString and LoadString into AppendFromString and AppendString.  That fixed the protected problem like you said.  I modified the AppendString version to add to FDocumentSource instead of replacing it with the input Source string.  That part was easy since FDocumentSource is just a string.  At this point AppendFromString can be called from the program and will append a string to the DocumentSource.  However, it still also will parse the whole document leading to my lag issue, as is to be expected, because I haven't quite figured out how to add to FSectionList instead of having the whole document be parsed.

FSectionList is a TSectionList, which is a datatype I'm not familiar with.  I saw some .Add-type properties, but only to add lists, pointers or TSectionBase's.  Also, since it may be relevant the original code has a:

Code: [Select]

if Ft = HTMLType then
    ParseHTMLString(FDocumentSource, FSectionList, FOnInclude, FOnSoundRequest, HandleMeta, FOnLink)
  else
    ParseTextString(FDocumentSource, FSectionList);
The two parse functions seem to also be tied to the display, as if I changed what was parsed to just the input string by changing FDocumentSource to Source I only ever got the input string on the THTMLView.  I also noticed the FSectionList is tied to the display in it's .create, so I guess that makes sense.  I took a good look at ParseHTMLString and ParseTextString procedures, but I find them somewhat confusing to understand.

So, I'm almost there, but could use some assistance.  Any ideas how I can translate the input Source string into something the FSectionList would understand and add it to it?  Thanks for all your help!

[evoshroom]

I've been bashing my head against this all night.    Once you get into the Readhtml.pas so many things are using global variables it's hard to tell what is changing what and what to modify.  It looks like ParseHTMLString is what needs to be copied and reversioned as an AppendAndParseHTML procedure (or perhaps other procedures that ParseHTMLString relies on), but everything seems interdependent instead of modular in this .pas file so I am finding it horribly confusing.  I'm going to take a break and hopefully when you next read this you can maybe give me a clue. 

[Phil]

I've been basing my head against this all night.    Once you get into the Readhtml.pas so many things are using global variables it's hard to tell what is changing what and what to modify.  It looks like ParseHTMLString is what needs to be copied and reversioned as an AppendAndParseHTML procedure (or perhaps other procedures that ParseHTMLString relies on), but everything seems interdependent instead of modular in this .pas file so I am finding it horribly confusing.  I'm going to take a break and hopefully when you next read this you can maybe give me a clue. 

Welcome to the world of porting code.

I don't really see what you mean by global variables. ParseHTMLString is a standalone function that you should be able to call as needed - it's not part of a class.

In your AppendAndParseHTML, maybe parse what you want to append into variables local to AppendAndParseHTML, then append them to the object's FDocumentSource and FSectionList. A section list is just a TList - see FPC docs for more on TList. Also see comments at top of readhtml.pas.

Thanks.

-Phil

[evoshroom]

I didn't mean ParseHTML itself, but all the things inside it like DocS. In any case if TSectionList is just a TList that helps. A TList is a list of pointers though. What do the pointers in the SectionList point to? When I add pointers to the SectionList after I add the appended string to the DocumentSource, where do I get the pointers for the SectionList from?