Just downloaded version 9.0.0.8. When I use the keyboard to navigate the File Lister window while the Viewer pane is active, the keyboard will stop responding if I stop at an HTML file.
I suspect it may have something to do with DOpus interaction with Internet Explorer? However, I looked at the IE Add-ons page and it looks fairly clean.
Do the cursor keys not work at all or do they just scroll around in the HTML view until you click back to the file display?
Most ActiveX controls like IE and Acrobat Reader will take the keyboard focus into their own windows when they become active.
I've noticed if the html page contains JavaScript errors, the Opus view pane will hang for quite awhile until it finally pops up the nag box about the error. For error free html pages it works just fine for me.
[quote="nudel"]Do the cursor keys not work at all or do they just scroll around in the HTML view until you click back to the file display?
Most ActiveX controls like IE and Acrobat Reader will take the keyboard focus into their own windows when they become active.[/quote]
Thanks for the quick response!
I should clarify that most of the keys don't work. The arrow keys quit working. And things like Alt+F to try and get the "File..." menu doesn't work. It's as if the entire keyboard is frozen. The only thing that works is the mouse and Alt+Tab. I have to use the mouse to click away from the HTML file and then the keyboard is working again.
If the problem is the IE ActiveX container, is there an alternative viewer? I would prefer not to switch the HTML handler to be a plain ASCII text viewer because (obviously) the HTML files would be much harder to preview.
[edit: ok, I played around with Opus some more and it does looks like IE is stealing keyboard focus. I didn't realize this until I found an HTML file that was longer than screen length --- I then noticed that the up&down arrow keys were scrolling the HTML viewer window. Is there a keyboard combination that will set focus back to Opus Lister?]
On the other hand, viewing Acrobat PDF files does not disable the keyboard at all.
Also, it seems like more people would stumble across this problem so I'm surprised it's not mentioned in any FAQ.
Hmmm... are you using the default Internet Explorer ActiveX viewer?
I am re-writing the ActiveX plugin so I'll take another look but last time I looked I could not find a reliable way to prevent the ActiveX control (IE in this case) from taking the focus.
I didn't realize that you authored the interface to IE ActiveX. Very nice.
So basically, because the Viewer pane is ActiveX, I can't just drop in another executable (Opera, FireFox, etc) to display HTML files. It would need to be some kind of ActiveX control and on top of that, someone would have to write a wrapper around that control so it's a plugin into Opus? As you can see, I'm not familiar with Opus architecture so just trying to understand what type of effort this is.
Also, do you know if this is the same behavior with Vista and IE7?
It's the same on Vista, yes.
Things don't have to be ActiveX to work in the viewer pane but you also can't just use any old program/executable. The program or library or whatever must provide some way to integrate itself into another program (Opus) in terms of both code and windows. ActiveX is one way of doing that but there are others.
In theory a plugin that embeds Firefox (or Mozilla) inside Opus directly could be written but it would be a lot of work and isn't something I plan on doing. Someone who was already familiar with the Firefox code (Gecko, etc.) might be able to do it fairly easily but I've never looked at it and it's meant to take a lot of time to learn.
There is also an ActiveX wrapper for Mozilla but I don't know if it is kept up-to-date or how well it works. Seems to me that such a thing should be part of the standard install and kept up-to-date as part of the main releases if people are going to rely on it for using Firefox or Mozilla inside their apps, else it'll break when you upgrade to a new version of the browser. (Unless it has the entire browser compiled into it and doesn't use the standalone browser you have installed. I don't actually know how it works.) I haven't actually tried it so it might work great.
Perhaps this is related to what happens to me...
When i open a lister with some downloaded rar'd (or other non html) files with .html extension then dopus.exe gets 100% of cpu time and all become unresponsiveness.
Please go through the FAQ called Crash, exit or high CPU usage when viewing certain directories to work out what is causing that problem, and let us know. It could be a number of things.
You are right Leo,
It happens the same when i open this folder with windows explorer. Have to track what is causing it.
Thanks