RTF-Viewer (and Editor) (32-bit only)

This ViewerPlugin lets you view and edit RichText-Files within the Dopus-ViewerPane.

It should work under 32bit Windows XP, Vista and above.

It won't work with 64bit Windows, sorry.

Feedback is welcome :slight_smile:

Current Version: 1.2.2 (11.02.09)

Please take a look at these files:
readme.txt => further information and usage
history.txt => changelist

Referring to this post, please use my PlugIns only with DOpus or higher! I'll limit the usage to this version in a further release. Thanks.

RTFViewer.zip (353 KB)

Thanks Dinkelhopper, it's working great so far!

If there is anything I'd like to see, it would be a settings for the right indent so my paragraphs can wrap.

A method of indenting/unindenting my bullet points would be nice. Great if they were buttons too, because I would like to use this with my tablet PC.

Of course you could just implement the right, left, first line, and hanging indents as it's done in Wordpad and Word, but I really don't enjoy messing with the ruler.

And maybe a small toolbar icon option would be nice.

I am just planning on using it for basic note taking purposes. So the functionality is almost complete for my needs.


Hi Dinkelhopper, great work with the plugins.

I found a problem with the file in the attached zip. If I select it and open the viewer it seems to go into a 100% CPU loop until I kill the process.

(I only waited a minute or so before killing it so I'm not sure if it's looping forever or just taking a long time. Seems like something is wrong though since WordPad opens the same file very quickly.)

It's a fairly long document which contains embedded images. The file was made by loading a random .doc file I had into Word 2007 and saving it as .rtf format. (I also tested a simple RTF document saved from Word 2007 and that was displayed okay so the problem isn't Word 2007 RTF files in general.)
WindowsVistaUACDevReqs.zip (943 KB)

I also got some crashes in the dopus_fileinfo thread which generates the Description column. I'm not certain but they might be caused by the plugin.

The dopus_fileinfo thread will call plugins to see if they recognise files and can provide any Description information.

The crash seems to happen a while after I refresh a folder containing various documents (RTF files and other files). My guess is it's a stack corruption since it seems to be causing the thread to crash when it exits. (I think the dopus_fileinfo thread hangs around for a while in case it's needed again, and if not it exits. Might be wrong though.)

I hadn't seen the crashes before installing the plugin and they seem to have gone away after removing it, but since they happen a while after doing something I can't be 100% certain what's causing them. I'll wait for an update on the issue above and then investigate some more. Maybe the two problems are related, since that problematic file is one of the ones that the plugin will be asked to try and describe.

I've realized your requests as best I can.

I fixed the bug with loading large files. I hope, the second bug will be fixed as well.

New Release in Post #1.

Wow, that was a quick update! Thanks Dinkelhopper.

This has everything I need now, it's very usable with its basic set of features. I love the indent feature, thanks!

Now I can see there is one more thing that needs a better solution. If I click on another file I can lose my unsaved work.

Now speaking for myself, I'd like to see an auto-save-on-exit setting in the INI file. This way I could jump quickly from one note/document to another without having to remember to save it or deal with a pop-up dialog asking me to save it. The whole point of using a DO plug-in for note taking is the ability quickly switch between files and this feature would make that a smooth process.


FWIW, the SourceCodeViewer plugin tackled this by displaying a modal "Save changes? Yes|No" message-box if it was asked to exit or load a new file after one had been edited.

Autosaving changes seems dangerous to me since it's so easy to accidentally type or paste garbage into a window, then close it either due to not knowing what else to do or due to not realising you had done it. Then again if it's an option nobody is forced to turn it on.

The save dialog would be the standard way to handle the situation and what most people would expect. So this should probably be it's default behavior.

However, looking at the way I will be using it for note taking on my tablet, an auto save option may be convenient. The new note taking applications auto save, but I think they also have unlimited undo - even across sessions. So this feature wouldn't be perfectly implemented without the undo capability to go with it and I can see that as a reason not to add it, but I'd prefer to use it that way myself. Please consider it a low priority feature request.


IMHO Dopus' PlugIn-Interface does not publish an event/message that notifies me, that the PlugIn should exit.
When my Viewer-Form will destroy, it's too late - than the RichEdit has already been destroyed :confused:

Any ideas :question:

For FileChanges I use the DVPLUGINMSG_LOADA-Message -> that works!

You should get a DVPLUGINMSG_CLEAR before the window is closed, guaranteed. (The ActiveX plugin depends on this as well since shutting down as the viewer window is closed would be too late.)

Thats right, but when I show the Save-Confirmation-MessageBox at this time, DOpus will hang up (only in Viewer-Pane-Mode; Standalone-Mode works fine) :frowning:

The same with SourceCodeViewer-Plugin :exclamation:

Isn't that just the modal messagebox dialog disabling its parent window until the user says yes or no? That's fine, IMO.

Making that message modeless would take a lot of work on your part and doesn't seem worth it for this situation.

If the message is modeless, the Viewer will be closed before the user has a chance to make his coice, whether to save changes or not.

Btw: thats not right in Delphi's case - then you have to design the message from scratch - and thats not what I want - for modal messages you have predefined classes :wink:

And as I mentioned the SourceCodeViewer-Plugin has the same problem here. Strange that I'am the only one who noticed that :open_mouth:

I'm saying, IMO, you should make it modal, the same as SCV does. The way SCV does this seems fine to me.

When I said making it modeless would take a lot of work I meant it would take a lot of work making it work with the Opus plugin architecture since you'd have to spawn your own UI thread (or even process if you want the "Do you wish to save?" message to work when Opus is shutting down) which doesn't seem worth it in this case. A modal message box is fine in this situation, IMO.

Or does the way SCV does it actually break something? Maybe I've misunderstood but I thought that if you closed SCV it would ask you if you want to save and you can then click yes or no and it then closes, saving if you asked it to.

Ok, I misunderstood you. I already made it modal, but that causes the problems I mentioned.

Okay, this sounds plausible.

Yes, it breaks like the RTFViewer does.

I open SCV (or even the RTFViewer) in the viewer-pane, edit the file, and close the viewer-pane.
Now SCV (or RTFV) asks me whether to save the changes or not. But I am not able to make my choice, because DOpus hangs up.

If I close DOpus completely (TrayIcon -> Exit) I am able to make my choice and SCV (or RTFV) saves the changes correctly.
When I open SCV (or RTFV) in standalone mode instead of the viewer-pane everything works fine.

Oh oh, you're right. It's odd that I haven't noticed this bug yet. I guess I am just too disciplined with my edits.

Hmm, very strange.

If I close the viewer-pane by Hotkey DOpus hangs up, when the Save-Message appears.

If I close the viewer-pane by clicking a button with the same commands everything works fine :open_mouth:

The same with the SourceCodeViewer.

By now I assume that DOpus causes this behavior; not the PlugIns.

Used commands:

Toolbar "Drives" TOGGLE STATE=center LINE=1

Ok, I released the current version.

Time will tell whether DOpus or the PlugIn causes the problems with the Save-Confirmation-Message :slight_smile:

Bugfixrelease (Post #1)

Thanks for adding the auto save feature! I turned it on immediately and seems to be working great so far - I'll let the others play with the save dialog :slight_smile:

Now if you are still looking for more to do -hehe- it would be nice if it would remember my word wrap setting, or maybe if I could just set the default value to on or off in the INI file. That would work fine too.

Great plug-in, thanks!