Writing Java Plugins for Total Commander

[djorge]

Thanks for the images. Sorry to bother you again about the images, but could you improve the image quality a litle bit?

Don't know why but i can't make the wfx plugins work. I commented all the wlx plugins in the ini file, and left one wfx uncommented, but i always get a memory violation message box.

Regarding the lister not being closed. I get the same behavior with all the plugins of the latest realease.

[kenchis]

Hi all together,

I worked a lot at the weekend and now the WLX lister plugin interface is complete. (Next is WFX)

You can search, print, send commands, etc for your plugin.
The Disassembler is again a good example for the new features.

Java API documentation is included also (the content is from the .hlp file)

The bug with the lister (opened with F3) is gone now.

Only the screenshots are of lower quality, but now its too late for today.
Coding in Java is fun

Kind regards,
Ken

P.S. Perhaps someone of you want to use it for his own plugin project?
I would be very happy
P.P.S. uploading is in progress about half an hour

[frenky]

Hi *,
I'm back
Last week has been hectic for me, and this one has some inclination to be the same. I'll try to steal some time for tc java plugin...

As I read through the thread, I see that one extension to TC plugin API should be made?

A call for unload/destroy is not implemented in the wlx plugin interface.

This would solve current problems of managed plugins when cm_unloadPlugins is called?

As for plugin, I found no bugs so far (did not test is thoroughly though), and the instalation of plugin is much easier with this version, however maybe one suggestion?
You curretly have in your config file following line:

Code: Select all

JVM_DLL="C:/Program Files/Java/JRE1.5.0_06/bin/client/jvm.dll"

It might be easier for instalation to make this parametar optional (do not remove it's existance all together, just make it optional and if available, use this setting) and read java version from registry:
1. Read REG_SZ "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\CurrentVersion"
2. Data red from (1) has some value: 1.5, 1.4, 1.3 (1.2?). This value can be used now to build full path to the e.g. 1.5 JRE:

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.5
within this path there are following values:

"JavaHome"="C:\\Program Files\\Java\\jre1.5.0_06"
"MicroVersion"="0"
"RuntimeLib"="C:\\Program Files\\Java\\JRE1.5.0_06\\bin\\client\\jvm.dll"

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.5\RuntimeLib is of interest to you.
With this implemented, instalation of the plugin is the same as any other plugin, IMHO much more easier then now?

What do you think? Feasable?

[Lefteous]

2kenchis

uploading is in progress about half an hour Sad

Hi,

Here are some tips to decrease your upload and user download time.

Remove the following files before you pack them:
*.suo;*.ncb;*.obj;*.lib;*.exp;*.pdb;*.idb

All these files can be created from source! These are just the most common buid files. I guess there are even more. These files are not required for the plug-in to run.

Some remarks about used techniques:
Creating dependencies is not a good idea in general. So java plug-ins only make sense if an installed JRE is really standard for all Windows installations.
Based on this assumption I'm not really sure if the additonal dependencies introduced with SWT native and java libraries are really a good idea.

Some remarks about the sample plug-ins. Two of them look great (saving them as png could also help to decrease package size) but they are not really Lister plug-ins. You are using prg as extension... They are just programs in a window. Lister plug-ins should display a certain file in a meaningful way.
Anyway I'm sure plug-ins will be created which are really Lister plugins - really sure

Anyway keep up the great work!

[frenky]

Based on this assumption I'm not really sure if the additonal dependencies introduced with SWT native and java libraries are really a good idea.

They are bundled with the plugin.

[Lefteous]

2frenky

They are bundled with the plugin.

What is your message

[frenky]

2Lefteous
Dependencies that are installed with plugin are bad idea? Why? If so, than splitting plugin to let's say two dlls is also a bad idea as they depend on each other.
No user instalation in this case is required... When plugin is installed SWT and jars that are required are installed, and there are no downside of this (IMHO that is why this mechanisam is made??). That is my point.

Only bad point with managed code is required runtime. Regardless if it is JRE or NET framework.

[Lefteous]

2frenky
It's just an even larger package with SWT and I don't really see why it should be used.
Java applets for example don't use SWT and are displayed inside a native window.

The SWT native libs seems to be inside the SWT jar and in the archive directory. Is it really required twice?

[frenky]

The SWT native libs seems to be inside the SWT jar and in the archive directory. Is it really required twice?

AFAIK yes (unles install procedure can decompress jar), because when swt libraries are opened, they are searched within FS, not jar files:

Code: Select all

FASTIO_QUERY_OPEN	C:\Program Files\Java\JRE1.5.0_06\bin\swt-win32-3139.dll	
FASTIO_QUERY_OPEN	C:\totalcmd\Plugins\java\swt-win32-3139.dll

But the way they are loaded depends on SWT java implementation. I guess System.loadLibrary is pretty straight forward?

If this can be made differently, please someone state so. This is one thing I would be glad If I'm wrong.
I guess one way that could be done is to force constructor to decompress jar file before calling any other SWT component...

[tbeu]

Some comments on this masterpiece of work:

* Plugin crashes if JVM_DLL is an invalid path.
* After manually changing JVM_DLL to the correct jvm.dll (I use JRE 1.5.0_01) I did not observe any problems at all.
* Please provide file version information in Total Commander Java Plugin.dll.
* You could also provide a main icon for the WFX.

Thanks for your plugin,
tbeu

[kenchis]

Thank you altogether for your tips and feedback,

1. @Frenky: Reading JVM DLL from the registry seems to be a very good idea. Installation is then very simple.
2. As Lefteous said I wil remove the binaries not needed for the plugin to work
3. @tbeu: SWT is not needed to make a TC Java plugin work. But it makes the GUI much simpler to implement (my first attempt was to use Swing). AWT has too less GUI features to impress anybody If You implement a Java plugin without SWT, you can remove SWT specific JARs from the installation.
4. @tbeu again: If JVM DLL is invalid i would like to create an error message in the lister window(possibly without using a seperate Rich Text window, any alternatives you know?). The same is for all other error situations, that can occur. For the WFX plugin requirement (providing an image), the plugin interface for that type is still in progress, but soon...

I have not much time to work on my homepage for the pictures, but i will make it next time.

Today i forgot my external hard disk drive at work,
so i cannot work this night.
What a black day

Best wishes and
Regards, Ken

[kenchis]

Hi *,

I made the next version. Some of your suggestions are reality now.
No configuration of INI file required anymore (unless you want to change the Java plugin class).
The download size of the Source is much smaller now.
The WFX API has more methods (implemented in Java).
You can see the History of Changes on my Homepage now: Click on (Hobbies/TC Change History)
at http://www.haendel-junior.de
I hope you will be patient with me and test the new version (even if i made one version after another these days). But I want to be finished with WFX this WeekEnd *hopefully*

Open JavaDoc with Lister Plugin to see the progress

Thank you again for your support.

Best wishes,
Ken

[kenchis]

Hi all together,
the next version is available again now at the well known place.
I changed much internals, that you can not see in Total Commander,
but it was nessecary.

An error message dialog appears, if something goes wrong in the C Plugin:
- JRE not installed
- TC Java Plugin is not installed at the right place
- class/method/field not found, etc.

Method fsRenMovFile was reimplemented with error codes. The FileTime instance in the RemoteInfo object (lastModified field) is corrected to the correct time base (ms since 1.1.1970).

BTW
I informed Christian Ghisler, that i need the possibility to install a MultiPlugin (WLX+WFX+...), to make a correct installation (right installation path plugins\java and not plugins\wlx\java).
I found out, that if i change the Plugin class, the C method getDetectString is not called again, so one must remove the plugin temporarily and add it again, if the new class has a different file extension

I thought i would be ready with WFX API this weekend, but now i know better

Best wishes,
Kenchi

[kenchis]

Sorry to bother you with one update after another,

but i had some time to work on the project.
Almost all functions of WFX plugin type are supported yet.
Please refer to the API documentation and read the notes on my homepage for Changes history.

It seems no one is interested anymore? I will work on this task until both plugin types are full supported and then make a pause until december 2006. There is another project waiting for me. It is about making old family pictures bring back to life as DVD videos.

I got no answer from Christian Ghisler until today. Perhaps i will change installation of the plugin in the future. No idea yet. Also i must find a workaround of the bug, that a JVM cannot stopped and restarted within the same thread

Please be patient with me.
Best wishes,
Kenchi

[majkinetor !]

It is about making old family pictures bring back to life as DVD videos.

You need 10 months for that ?