Ive set up a dll project right and tested along with a simple 'hello world' return, so the link between foobar and mirc is set.

Looking at some sources, im not sure how to do what i want, which is simply get the info (artist, album, etc..) about the currently playing file.

Also, im not 100% sure im doing everything right - when i tried using play_control and returning something from that, i got mIRC to crash reporting something with core_api::are_services_available() . Am i not creating the dll right ?

Ive been coding C\C++ for several years now, so i have the needed experience, but i havent worked with DLL files much in the past, so any help would be recommanded.

Working under the VS.NET2003 IDE right now.

You could take a look at the source for foo_msn from http://www.myplugins.info

It does some basic track change detection and formatting of the current song. Its fairly simple so should be less confusing that some of the other plugins which do more. Im no expert in fb2k components, but it seems to work ok

Note that it probably wont be much help as far as creating the .dll and setting up the exports. Just help with the API needed to get the song info.

That sounds like you are trying to use a foobar2000 component DLL in mIRC, which will not work. Even if you create a DLL that can be loaded by mIRC and foobar2000, that does not magically enable you to perform calls from one process to another.

But if the DLL works as a foobar2000 component and can grab the needed track info, cant i have a function inside the DLL that mirc can call ?

I dont see any special problem with that aspect, as im not really mixing between mIRC and foobar.

Is there any special initalizing needed to be done in order to use play_control::get() and get_now_playing() ? Those are the only two elements i seem to need. Right now im not even touching the mIRC part, just trying to grab the now playing info from foobar, but are_services_available() always returns FALSE, even that the DLL reports to have loaded fine in foobar2000.

Also, It seems that the info is only available using foobar's events (started playing, track change, etc..). Is it not possible to grab the info on the fly, as in when requested ?

I know nothing about the foobar stuff, but the obvious solution to something like this would be to store that info in your own memory space and hold onto it, changing it when the track change occurs. Then when somebody external requests it, you pull it from your own space where you have it stored. Just a thought.

yea, thought about that, but id much prefer if it was possible to grab it on-the-fly.

Why not use play_control::get_now_playing()? You should check the return value, as it will return null, if no track is playing.

i added the are_services_available() check because it crashed other wise, with either the play_control::get() or the get_now_playing() i believe. Also, get_now_playing() is not static so i need to get a play_control first before i can retrieve that.

Ill try again, though perheps ill post a small text version of my code for someone to look at, because i think im missing something basic.

EDIT: some debugged info. This is what im trying to do in my code:

>> play_control *pcPlay = play_control::get();

Which gets to play_control.cpp:

>> static play_control * ptr;
>> if (!ptr) ptr = service_enum_create_t(play_control,0);
>> return ptr;

And the second line gets us to service.cpp, to the requested function, which fails the following assertion:

>> assert(core_api::are_services_available());
>> return g_api->service_enum_create(g,n);

So, obviously, im doing something wrong here. The DLL is in foobar's components directory, and according to foobar it loads with no problems. It appears on the components list as loaded. When i try to call the function inside the dll (yes, using mIRC, but i dont think thats the issue - im simply calling the function..), the above happens. Any ideas ?

Well, no matter what you believe, that is exactly the problem. foobar2000 loads a copy of the DLL, which it initializes. mIRC loads another copy of the DLL, which is in a different process. The copy in mIRC has no access to foobar2000 services. Please do yourself a favour and get a clue about dynamic linking, processes and interprocess communication.

I see. Are there available API functions to determine the process handle that foobar uses for the DLL within the SDK, or is this done programatticly ?

Read the mIRC help file, there are no less than two interfaces for external processes to communicate with mIRC. A process can use a DDE server (requires activation) or send custom window messages to mIRC's main window (or any of the child windows to control where it goes) so mIRC reads commands from a named file mapping of a memory block.

If you cannot figure those two interfaces out, then you will have to write your own interface, and that means two separate DLLs, or writing your DLL such that it has two interfaces crammed into one, and depending on where it is loaded, will seek the other part out by some inter-process communication.

Right now, The DLL contains functions to return info from foobar. Those functions are exported to use with mIRC according to the info on mirc's /help on dll support. The problem, like you and foosion stated (and i should have known ) is that these are two seperate processes.

I will try to find a way to implement working inter-process communication between the mIRC process and the one foobar allocates for the DLL (even though, frankly, im not sure how where to start right now).

If that fails, ill try using mIRC's Messaging Interface (with the foobar component DLL, as that SHOULD, at least, be able to grab the track info) to achieve the same purpose.

Thanks for the help, Sorry if i make it sound like im doing this half-assedly, but i am trying to do this right and i do understand the involved necessery programming elements.

Though, again, after looking at some more documents, it still seems this is leaning towords event-based action, such as when a new track begins. The whole point of my dll is to provide a way for mIRC to recieve the info when IT wants, and not when an event goes off in foobar (if that is possible).