Directory Opus Resource Centre

by **Dinkelhopper** » 26 Jan 2009, 13:01

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

It should work under 32bit Windows XP and Vista.

Feedback is welcome

Current Version: 1.2.2 (11.02.09)

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

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

by **Ross MacGregor** » 26 Jan 2009, 18:02

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.

Thanks,
Ross

by **leo** » 27 Jan 2009, 03:05

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.)

by **leo** » 27 Jan 2009, 03:39

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.

by **Dinkelhopper** » 27 Jan 2009, 12:01

@Ross
I've realized your requests as best I can.

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

New Release in Post #1.

by **Ross MacGregor** » 27 Jan 2009, 12:50

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.

Regards,
Ross

by **leo** » 27 Jan 2009, 15:39

Ross MacGregor wrote:If I click on another file I can lose my unsaved work.

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.

by **Ross MacGregor** » 27 Jan 2009, 22:28

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.

Cheers,
Ross

by **Dinkelhopper** » 28 Jan 2009, 02:51

leo wrote: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.

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

Any ideas

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

by **leo** » 28 Jan 2009, 04:41

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.)

by **Dinkelhopper** » 28 Jan 2009, 05:14

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)

The same with SourceCodeViewer-Plugin :!:

by **leo** » 28 Jan 2009, 05:27

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.

by **Dinkelhopper** » 28 Jan 2009, 05:57

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.

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

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

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

by **leo** » 28 Jan 2009, 07:24

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.

by **Dinkelhopper** » 28 Jan 2009, 08:16

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

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

leo wrote: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.

Okay, this sounds plausible.

leo wrote:Or does the way SCV does it actually break something?

Yes, it breaks like the RTFViewer does.

leo wrote: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.

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.

Directory Opus Resource Centre

RTF-Viewer (and Editor)

RTF-Viewer (and Editor)