Definitive Crash Caused by Pasting Images
 

One definitive way to crash UR since UR3 is to paste an image into a text item. Kinook has been explaining UR uses the same DLL from Microsoft. From a user standpoint, it may be unacceptable.
One interesting way to avoid the crash I discovered accidentally is to first paste the image into a Word 2003/2007 doc/docx. Then from there copy (ctrl+C) the image again and paste it into a UR text item. It works fine. But, given it's the same image, why is the difference? How could UR discriminate against the images directly copied from the webpage?
Armstrong

After deleting riched20.dll from C:\Program Files\Ultra Recall, copying an image into a text item stops causing crash so far.
Thanks, Kinook.
Armstrong

The problem I'm facing with the downloaded RichEdit DLL from your website is that I'm not able to edit tables anymore.

To be precise: I cannot change the width and height of the cells anymore.

using the Office DLL I'm however able to change the layout.
Since I'm using tables very often inside UR, what is the best way to edit tables internally?

Will you by any chance, change the built-in editor in a future release?

Hi Michael,
IMHO, UR is not designed for fancy text editing.
As far as your issue is concerned, you may edit in Word 2003/2007 your tables whatever way you like and copy the results back to UR.
All things copied from Word, including images, won't cause crash in UR.
Armstrong

Armsys,

thanks for your reply! Of course I don't want a full replacement of Word inside UR ;-) however some basic features like modifying a table layout would be fine.

When using the Office RichEdit DLL I can edit the tables, however, I'm encountering exactly the same issue, you have reported in your initial posting.

Hi Michael,
In my case, deleting C:\Program Files\UltraRecall\riched20.dll will likely stop crashes caused by copying images into a text item.
Armstrong

Ok, if you deleted the file from the UR installation folder, UltraRecall uses the one it could locate here C:\WINDOWS\system32\RichEd20.dll version 5.30.23.1230 (in my case).

Unfortunately this DLL version is the one which is not capable of editing tables :-(

When using the Office RichEdit DLL, I've told UR setup to use it, I can find this one in the UR installation folder: riched20.dll version 12.0.6413.1000 (Office 2003 installed here).

This is obviously the version which crashes UR when pasting any images from clipboard - just re-tested again.

I wonder if the Office 2007 RichEdit DLL would do a better job?

I sorry I didn't realize my UR couldn't create/edit tables. Yes, you're right. I didn't realize because, as mentioned above, I prefer to use Word 2003/2007 to edit the tables.
A lot editing functions are simply not available in UR, such as control merging the cells.
The version of my C:\WINDOWS\system32\RichEd20.dll is same as yours, that's, 5.30.23.1230.
Armstrong

Hi Michael.

This post by Kyle in the FAQ forum explains a lot of the issues involved with different versions of the MS RTF engine:

http://www.kinook.com/Forum/showthre...&threadid=2853

It appears that later versions are better with tables and some other advanced formatting but are also more prone to crashing, while the older versions are more stable but less feature-filled.

BTW, if you search the files on your computer you can probably find ~5 or 6 versions of riched20.dll.

Jim

Hi Jim.
Thanks for your feedback.
We all know about the crash.
The only question: Why? Why does it happen? Do you think it's acceptable?
Armstrong

Acceptable by me. Unless Kinook is going to develop a new RT editor for UR, which I don't see happening.

If I really need to format my text in a way that UR doesn't handle well I do it outside UR and then import or copy it into UR. If I couldn't do that it would be more of a concern to me. But since I can, well, it's a pain but not a deal-killer for me. Not even close!

Just my opinion... :)

Jim

ctrl+j to edit externaly, no need to import or copy ...

Even though I always edit text in Word, I didn't use this convenient shortcut until now. Thanks, quant.
Armstrong