Is there anybody out there who planned to develop such a plugin? I'm asking, because I don't want to do things twice...so please reply if someone is working on this thing!
Last weekend I made a simple test implementation of Scintilla for DirOpus to get an overview of the effort and what is possible. Looks like, x64 and Windows 7 support is easy to realize. But I'm not an expert in Windows programming. Supporting different languages (and styles) and a nice configuration GUI will be more time consuming I think.
I was a real fan of the well known Sourcecodeviewer plugin, though it had some bugs in it. As the source code is not available and I was missing some features, I plan to rebuild it. But as I am currently very busy, don't expect too much.
My motivation:
Create a simple source code editor within Opus (not more or less than the first Sourcecodeviewer plugin)
Make it stable
Make language styles configurable (via configuration files)
Try to find a way to transfer the search string of the Opus simple search to my new plugin to automatically mark text occurences
Thanks for your help. Indeed I need your help earlier than I had hoped :
Is the GUID of the plugin a generated GUID by GPSoft? I tried to change the name of my plugin, but it stays to be reported as "nfo" (which is the plugin my code is based on). Even modifying some numbers of the GUID doesn't seem to make a change.
Where can I change the name, which is listed under "Viewer Plugins/Plugins" ?
For some reason, after I developed a long time and had some crashes in DOpus (in combination with TASKKILL and VisualStudio) I'm now unable to start or - even more - register the plugin. So DOpus doesn't want to list my plugin anymore. Do you know how I can solve this? I tried to reboot several times but it doesn't help . If I press the plugins reload button, DOpus freezes and has to be killed. As soon as I remove my plugin, the plugin reload works, but this way I can't test my plugin.
DOpus seems to lock my plugin dll. Probably this is the way it works in Windows! But due to this fact, I can't overwrite it and "shutdown" (means: close all windows) my new plugin doesn't help. Is there a better way than kill DOpus to overwrite the plugin and restart it? I tried your "dopusrt.exe /flushplugins" mechanism, but that wasn't working.
Is it a problem to put the Scilexer.dll and Scintilla.dll in the "Directory Opus\Viewers" folder? AFAIK I read, that this isn't a good idea... is this correct?
The GUID Is one you generate yourself. It has to be unique to the plugin, and shouldn't be the same as the NFO plugin's GUID.
If you're using Visual Studio, you can use Tools -> Create GUID to open a small tool that can generate a GUID for you to paste into your code.
The plugin name comes from your DVP_Identify function and is part of the LPVIEWERPLUGININFO structure that you fill in. One of the fields in the structure is a string buffer, and another tells you how big the buffer is; just copy the name string into there. (Check that the buffer is not null; sometimes Opus will pass null buffers when it wants some information but not that particular info.)
The fields and flags of the structure are described in detail in the plugin sdk:
You may be seeing problems because the plugin is using the same GUID as the NFO plugin. (See #1 above.)
It's also possible that the plugin's code is crashing when loaded. You can attach a debugger to dopus.exe and then set breakpoints in your DLL's functions to step through the DLL as it is called. (If you're having problems with the plugin identifying itself, you'll probably want to exit Opus (see below) and then launch Opus under the debugger from the start, so that you can break into your code as soon as it is called during startup. Once that is all working and you just want to debug functionality, you can run Opus normally and then attach and detach a debugger to the running process at will, without having to restart the process under a debugger each time (which is handy if you run into unexpected behaviour and want to jump straight into debugging it without having to start again and try to work out how to reproduce what just happened).)
Closing all windows won't exit Opus; it stays running in the background by default. (Although you can configure it to exit when all windows are closed if you want.) You can use File->Exit Directory Opus, or "dopusrt.exe /cmd Close Program" to exit the program fully, which will release the DLL.
To speed things up, you can make a simple batch file that exits Opus, copies the new plugin DLL over, then restarts Opus.
It's fine to put Scilexer.dll and Scintilla.dll into the viewers directory, assuming the components themselves are happy to live there.
Thanks Leo, you saved my night ! I was getting crazy with my plugin. May I ask you, if you are a virtual person ? Or are you not sleeping? It doesn't matter whether I write a comment in the forum at day or night, I get an answer within a few minutes. And it was really early in the morning at my location (about 3:30am ).
Very helpful! I wasn't aware of that tool. I changed the GUID before (just two chars), but was not sure, if there is more to do
Well, that's REALLY surprising: Of course I changed all that information within the plugin, but nevertheless it was identified as NFO. With your information I debugged into LeoHelpers::CopyVersionResourceToViewerPluginInfo() and now I can see, that some strings are overwritten/translated by the DOpusPluginHelperUtil. As soon as it gets called, my identification strings get overwritten . So I have to disable this. That drove me crazy as well, because I searched for the string NFO and didn't find the file it is located in. Now I know!
Launching Opus from the debugger was the best tip . I wasn't aware that this is possible (without debug info). After I did that, I analyzed really fast, that my plugin is crashing for some reason. I commented out some stuff and had a second problem with the Scintilla DLLs lying in Windows\system32 AND the DirOpus folder, which I deleted in system32. After that the plugin got listed under the plugins view again.
With your tip I now have a very stable and comfortable debug environment. I just have to activate "Build" and "Debug" and everything is done automatically (what I have missed before).
Some programs will probably put the Scintilla DLLs in System32 so the plugin will probably need to cope with that. You should be able to call LoadLibrary with the full path to the DLLs to ensure the correct versions get loaded.
It might be worth having a look at the Targa plugin that comes with the Opus plugin SDK (not the Targa plugin that's on my personal website), since that is a very simple and self-contained plugin, without any helper functions etc. to confuse things. The helper functions are good, and the Targa plugin on my website is a better plugin, but they also make things harder to understand when your aim is to understand how plugins work, not to have the best Targa code. So it's worth checking out. And once you understand that, it may be worth looking at the other Targa plugin and understanding why it does some stuff differently, which will be easy once you're familiar with the basics.
It's a bit of both. There is a search-field control in Opus that the plugin re-uses there, but the plugin is creating the control at the bottom of its main window, and resizing its main window to make the room.
The search-field control is pretty low-level and isn't currently documented or part of a public API, but we could change that if needed. It works fairly similarly to a Win32 edit control, taking window messages to tell it which mode to be in (e.g. turn red if the string isn't found) and sending notification window-messages to its parent when keys are pressed or the X button is pushed.
TBH, it's probably easier to use a normal edit control and button, at least to begin with. The code to make them will be very similar to the code to make the search-field control, and the main difference will be cosmetics. It should be easy to swap the edit control for the search-field later if needed. (Or we could provide some functions to e.g. draw the different parts like the gradient background and the close button in a consistent way, if that is easier than using our custom control.)
@Leo: OK, thanks! I think I'll implement it first with a common EditCtrl and perhaps we can later exchange it.
Unfortunately I have the next question for you :
Scintilla needs a lot of external configuration stuff - at least, if it should deal with a lot of different languages. So, you have to define ALL the i.e. keywords ("if, else, this" for C++) for ALL languages and a lot of defines. My first approach was to compile some default languages in (so the plugin is generating a XML config, which the user can modify) but to provide the user with all possible languages from scratch I don't think this approach is a good idea. I would prefer to read in a XML file, which is generated by me, delivered with the plugin and provides all the necessary Scintilla input config and is not modifiable by the user. Additionally a common Opus config will exist, which is user modifiable of course.
I didn't find a plugin, which uses external (XML) input files. Where is an appropriate folder for this file (Viewers folder as well ?) ? Is this method recommended or do you prefer to generate this config by the Opus plugin (paying attention to be USB safe)?
@xbprm: Hehe, don't thank me before the baby is ready . Nevertheless I hope there are some more people who are interested in such a plugin!
There's a GetConfigPath function in the Plugin Helper API which plugins should use to get the location for storing their config files. It's usually /dopusdata/ConfigFiles/Plugins, but using the API is best in case it varies.
The full details are in Plugin Support API SDK.pdf under, Configuration Functions section. There is also an API for reading and writing XML config files, but you probably won't want/need that if Scintilla has its own code for doing so.
Thanks, I was aware of GetConfigPath(), but I wasn't sure, if I'm allowed to place some config files there, which are not modified by Opus (as mentioned, they are just READ by my plugin and has to be copied by the user or later by some kind of installer, if any will exist in the near future ).
I will definitely have to use the API for reading XML files, as Scintilla is not able to read in some kind of configuration. It's up to the application, which uses Scintilla.
Yes, I need this plugin as well and sorry for no progress yet. It is still on my TODO list and must be completed, but I'm still under heavy load. Reading more information about the Scintilla component showed, that the user interface and saved config structure must be more complex, than I thought: The user must be able to change colors, fonts and other settings for different languages and even for different textblocks of that language. Additionally the commands to change these settings are generated and not static. So I have to setup an infrastructure which can handle all these things.
If there is any progress, I'll write news in this thread!
Would it be possible to make it not require copying SciLexer.dll to system32? Is there a reason it can't be loaded from the same directory as the plugin DLL? (If it's loaded via LoadLibrary, you can give the full path to the DLL; it doesn't have to be in the system path.) That will make it possible for it to work with portable installs, and also avoid clashes with other things that want a different version of SciLexer.dll in System32. (And System32 should only contain parts of Windows itself really.)
Compiling for a static C++ runtime is also nicer for people using portable copies of Opus, since they cannot depend on the CRT being installed.
Supporting portable/USB copies also needs one more thing, which is a USB-safe manifest in the resources, which tells Opus the plugin is safe. (This should only be set if the plugin doesn't modify the registry or anything else outside of the Opus config folder to store its configuration etc.)
Got it working.. somewhat. I agree with Leo, that looks really promising! o)
I have some issues:
the config dialog does not seem to work for me (anything I setup is lost).
it does not detect *.js files for some reason (no syntax-highlighting kicks in)
the config dialog does not seem to reflect the current filetype (it always shows "default" for language and style, though it did hightlight a powershell script e.g.).
the find (great that it's there!), is still a bit inconvenient - but hey for a v0.0.0.1 not bad at all! o)
:
. If I press the plugins reload button, DOpus freezes and has to be killed. As soon as I remove my plugin, the plugin reload works, but this way I can't test my plugin.
).
. So I have to disable this. That drove me crazy as well, because I searched for the string NFO and didn't find the file it is located in. Now I know!
. I wasn't aware that this is possible (without debug info). After I did that, I analyzed really fast, that my plugin is crashing for some reason. I commented out some stuff and had a second problem with the Scintilla DLLs lying in Windows\system32 AND the DirOpus folder, which I deleted in system32. After that the plugin got listed under the plugins view again.
:
. Nevertheless I hope there are some more people who are interested in such a plugin!