Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[paul1970]

I'm trying to write a visualization plugin.

I've downloaded the Display SDK from here so I figure that the best start is to build the ImpactFill, get it working and maybe see if I can run it in debug to see exactly what's going on. So I've built it in VS and successfully registered it. What I would have expected is that I would then find it as an entry under 3D in the context menu on the Display View. I don't. Should it be there? Should it be somewhere else? I'd be grateful if someone could give me a start.

Registration seems to have worked correctly from the info in the project, but the confusing thing is that I can find no registry info related to existing stock visualizations. So question #2 is 'where are they getting picked up from'?

[paul1970]

Ah, OK. I think I fixed a problem by amending REGISTRY_PATH_MJ_PLUGINS_IMPACTFILL to point to MC18 (instead of 12!).
So now I think it really is correctly registered, BUT when I right-click in the Display View the application crashes (in my impactfill.dll). Is this a case of the SDK files/example I've downloaded being out-of-date?

[paul1970]

It's crashing on the return statement of STDMETHODIMP CImpactFillImpl::Init(IDispatch* pMJ), with what looks like a calling convention issue. I'm not experienced with ATL. Anyone know what's going on there?

[paul1970]

So, now I've found this. But this isn't referred to in DevZone at all.
Which one of these two APIs should I be using guys?

Also, it's not clear to me how the plugin is scheduled through the above API. Is the plugin responsible for scheduling itself by launching its renederer in a thread? Please advise!

[Matt]

The COM interface is still supported, but it would be better to use the newer C++ interface (which we moved to for cross-platform):
http://yabb.jriver.com/interact/index.php?topic=56967.msg482438#msg482438

The redraw loop should be managed by the plugin itself.  A simple timer is a good way to start.

Other than G-Force, we haven't had a lot of developers thinking about visualizations.  For this reason, the SDK is a little crusty.  I'm sorry about that.

Plugins register here (look at the stock plugins for an example):
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JRiver\Media Center 18\Plugins\Display

[Matt]

To take a step back, we have an issue with SDKs right now.

If we were to write a simple visualization, it might be 100 lines of code and be set to work cross-platform.  It'd be fun to be able to share samples like this.

But to do this, we link into the JRiver code framework.  This has a mixture of static and dynamic components.  Since our core engine is evolving, the dynamic linking portions effectively link a binary to a specific build of Media Center.  This means it's not a good thing for a third-party to link to.  And it's not well documented, since it's for our own use.

That means we need to reinvent the wheel to do window, string, etc. handling in a sample.  Or use ATL, MFC, or some other wrapper that we don't use and that isn't cross-platform.

I'd love to be able to write code that looks exactly like third-party plugin developers code would look.  It would make it easy to share in both directions.  I just don't know how to do it.

The only solution I can think of is to run a public SVN and require third-party components to be open-source so that we could compile them with each build or as needed.  However, I'm not sure if this would float with developers.

[paul1970]

Thanks for responding. I understand your issues. Isn't your C++ interface already tied to windows though (since it uses HWND, LPCTSTR, BSTR etc)?

If I were to produce a Visualization plugin that is absolutely Windows-specific would I be breaking any rules/license terms by distributing it (non-commercially)?