My three main plugins at the moment are FuelPrices, Traffic cameras and Fiel Synchronisation.

Have a look in the RoadRunner and Centrafuse Pugin subforums for my threads on them.

By looking at your work, I need to do a few adjustments to the core and extend the
scripting language a bit further to be able to read data from the plugin into a layer.
Not too much work I think.. But I still need to have a look (with a technical eye) to the
plugin structures of RR. Maybe there is a way to make them load in CM.

Also, I need to figure out the best way to display those cams.. We're going to use some
webcams built into the car too, but thats the next chapter of CM I guess.

-- edit: forgotten part --

Also, there's no navigation yet.. Will be, soon I think.. but there are some technical
difficulties with some of the nav-apps (garmin f.i.) to be solved.. the most generic
would be to start the app and position it above the CM-window or something...
But that's for later...

RR's dll basic has set routines which RR will check whenever something is needed for a particular skin, or a command is issued.

The main ones being

Buttons (or commands) which the plugin receieves and if it belongs to that plugin in acts on it.

Labels which again if it belongs to the plugin is updated by the text sent back by the plugin

Indicators, these can be on/off or a path to an image file.

Indicators can also be clicked so act a bit like buttons.

Whereas CF

is more form based, it inherits certain things from CF, but also has a command return or request for info, but this has to be called directly by another plugin, although with CF3 it can also be called by a skin command

Well enough! I understand both ways, not the technical details of both products, but at least the concepts.

My question to you, which way do you prefer?
I can define a small amount of exports for you to implement in a DLL,
or the more ActiveX/.NET/COM way? (they won't be exactly like CF or RR, but
at least I can try to make it an easy job to port your plugins)

Buttons/Commands, Labels, Indicators (although this is basically buttons with images), Buttons with labels.

And a way of sending commands back to control the frontend. Fuel prices only needs to communicate with the navigation engine which you don't have at present but other plugins may need to control the Frontend, eg iBus for Steering Wheel control etc.

Also an ability to have GPS coords routed through the frontend as well would be good, whether you have a navigation engine or not.

Most important is the callback system.. The framework already uses a kind of messaging system.
Objects/layers/plugins/etc can subscribe to events. But this is all Delphi based interfaces.
I need to think of a wrapper-plugin, which also implements some callback to 3rd party plugins.

An event is based on enumerations and integers, so that's easy to transfer between the plugin and the host.
But strings are a different story.. They work very different from VB, C#/++ or .NET
based languages and are the cause of most serious headaches for developers
(but maybe transfer via memory-mapped files or xml's are an option?
need to investigate that later, unless someone has a great idea ofcourse )

Right now, I'm finishing the Silabs USB FM Radio plugin. It's finished within a few hours.
I'll start setting up a basic framework for loading other-than-delphi plugins after that.

I think i have found my front end. I really like CarMa. But possible bug?
Not displaying the artists first name on any tracks. Am running WinXP Pro. If you need any other info about my system let me know.

I think i have found my front end. I really like CarMa. But possible bug?
Not displaying the artists first name on any tracks. Am running WinXP Pro. If you need any other info about my system let me know.

Thanks!

But that's an odd issue.. It reads the ID3 v2.x or v1.x data when a new mp3 file starts .
Could you check if Winamp displays the same amount of data (ctrl-I in Winamp)?
It should, if not, it's probably loading the wrong data from the mp3 and I need to fix that