• jan@cosmigo.com

File I/O Plugins Questions


#1

Ciao Jan,

I have a couple of questions about plugins.

Registering File I/O Plugins

The documentation is not clear about this point, and I couldn’t actually test it since I don’t have nay file i/o plugins to experiment with — the sample file_io_plugin_samples.zip doesn’t actually contain the DLL binaries, although the documentation says so!

So, do these DLLs need to be registered in the plugins.ini file too? (i.e., like DDE plugins) or is it just enough to drop them inside Pro Motion plugins/ subfolder? (i.e., PM automatically loads and initializes any DLLs found therein)

NOTE — If you could add the precompiled sample DLLs to the downloadable Zip archive it would be really useful. I don’t have MSVS, and the sample project only comes with MS-style solution files, no makefile (so I’m not sure how to compile it with GCC).

PM NG, DLLs and Bitness

Because file I/O plugins are DLLs, unlike DDE plugins they need to match the bitness of the Pro Motion application. Currently, PM NG is only available as a 32-bit app; are there plans for x64 version too, in the future?

If this was the case, then 32-bit DLL plugins won’t work with the x64 version, this being the reason I’m asking this.

File I/O Functions

A couple of questions about the DLL plugin functions.

setProgressCallback()

The documentation states:

void __stdcall setProgressCallback( ProgressCallback progressCallback );

Use this function to define a progress callback that is called by the plugin to give user feedback about the progress of loading/saving image data. A percent value of 0 should make the progress display to hide and values between 1 and 100 should make the display visible.

Parameters:

  • progressCallback — A function to be called when progress changes.

I just need a confirmation on this. If I’ve understood correctly, PM calls the DLL function setProgressCallback() during initialization to provide the plugin with a pointer to the progressCallback() function used to show (or hide) some progress status bar during file I/O (or data manipulation) operations.

The progressCallback() function resides in (and is handled by) Pro Motion, right? The plugin only has to invoke this function whenever it needs to update the user on the progress status, by passing the appropriate integer value.

How does it work, PM shows a progress bar (1-100)? Does it appear inside the file I/O dialog, or is it a windows on its own? Does it show some text relating to the plugin it refers to?


#2

Ciao Tristano,

indeed the zip file did not contain the DLLs. I upodated the file. No there is a folder “Release” containing the release compiled binaries.

Dropping them into the plugins sub folder is enough. No registration is required.

You can get a free copy of MS Visual Studio here https://visualstudio.microsoft.com/vs/community/

At the moment DLLs and program are working on 32Bit architecture. I think I’ll check 64Bit support next year.

As for the progressCallback your assumptions are correct. Today there is no true progress bar in PM anymore because it’s mostly useless. The most important thing is that the user has feedback that an operation is just running and this is done with a small emphasized panel at the bottom of the main window along with the cursor turning into an “busy” shape.
But, you still should call this callback with a progress indication from 1 to 100 if you can, but at least set it so some non-zero value when the process is running and to zero when you are done.

-Jan


#3

Thanks Jan! As you where replying to my question I was also about to post this reply with my findings …

OK, after various tests I’ve managed to make my file I/O plugin show up in the Load/Save dialogs. It seems like DLL plugins only need to be placed inside the plugins folder to be detected (and the various DLL init procedures will be used by PM to establish in which dialogs to show the plugin).

I’m currently working on a PureBasic file I/O plugin DLL interface, which is going to make writing file format plugins really easy. PureBasic is a simple yet powerful language that ships with lots of useful native libraries.

My intention is to publish as open source a file I/O and DDE plugins interface that wraps and hides complexity by providing some simple interfaces to handle all the nitty-gritty aspects of communicating with PM, leaving the end user free of the cumbersome parts, so that he might focus on writing just the code that manipulates the data.

I can’t say how long it will take, for time is always in short supply. Right now I’m halfway through with file I/O inteface; then I want to reproduces the same sample plugins that are found in the ZIP files, but in PureBasic — so that code comparison can help understand the parallels and difference.

You can get a free copy of MS Visual Studio here https://visualstudio.microsoft.com/vs/community/

I have a copy of the MSVS 2010 iso file, I had installed it in the past, it’s just that I haven’t installed it since my last PC crash because, beside the SDK documentation (which is really helpful), I find it a rather cumbersome package.

Nowadays you can compile Windows applications with MinGW-64ìs GCC compiler, as it handles well WinAPI stuff, and it doesn’t impose restrictions on usage (the free edition of MSVS only allows non commercial projects).

Also, I like working with Sublime Text as an editor, and switching to other editors would just slow me down production-wise.

But probably I should reinstall it, just to have the SDK and all the various CLI tools (debugger, resource editor, etc.).

As for the progressCallback your assumptions are correct. Today there is no true progress bar in PM anymore because it’s mostly useless. The most important thing is that the user has feedback that an operation is just running and this is done with a small emphasized panel at the bottom of the main window along with the cursor turning into an “busy” shape.
But, you still should call this callback with a progress indication from 1 to 100 if you can, but at least set it so some non-zero value when the process is running and to zero when you are done.

Thanks for the precious info! I’ve noticed that in some places the plugins documentation seem to refer to interfaces which are not present in PM NG, I guess this is because they were written for older versions of PM.


#4

Sounds great.

Can you point me some places? I’d then update the docs. Indeed it’s not easy to keep documentation up to date.


#5

Can you point me some places?

For example, in the DDE plugin doc:

pluginX_type
is the section the plugin is added to: “export”, “import”, “manipulation”.
Each section has a submenu in the menu ‘Plugins’.

PM NG doesn’t have these submenus any more. But there are a few other places which might be referring to older versions of PM (right now I can’t remember them).

I’d then update the docs. Indeed it’s not easy to keep documentation up to date.

By the way, did you get my last email with the HTML docs attachment? (often emails with attachments get blocked, in fact I had to use another account, not GMail).

Instead of duplicating efforts, we could use the AsciiDoc file I’ve prepared, which can then be coverted in any format you need. I’d be happy to help with this, via the project we talked about (just waiting for your greenlight).


#6

Oh yes, I forgot … the plugins documentation still says that only the Pro version can load plugins, but now also the free version can!


#7

Yes, you are right. In the past the DDE plugin interface also covered file i/o, but this has been replaced by the separate interface definition. Will update this.
I got the email, but did not find the time to check it out :frowning: Hope to get this done tomorrow. Thank you for your support.