Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: no more foobar2000_class ? (Read 7326 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

no more foobar2000_class ?

my friend's mirc dll used to pullup the foobar2000 title by using foobar2000_class but in .8 it stopped working. when we looked into it we found out foobar2000 now used unique id's. what's up with that ?

no more foobar2000_class ?

Reply #1 –
AFAIK, from now on foobar2000 will use the GUID of the selected UI component as a classname.

It is recommended to use command line to control it, and something like foo_text to pass information to other programs.

no more foobar2000_class ?

Reply #2 –
i also used FOOBAR2000 class in my application. Since version .8 there is no such class any more. Anyway, i found some other classname showing same text as before named {D7hdsjshj... something...} which is usable but when foobar is minimized it returns string "uninteresting". Any chance to show window title for that call name even if foobar is minimized?

I guess many application used this simple way to fetch info from foobar (various blogging plugins etc) and this change just breaks them. So any chance to return this back or just show that info in some other class. It would be appreciated. Thanks

no more foobar2000_class ?

Reply #3 –
Also, if there's no chance of a return to the old method, how about a plugin? Alot of foobar control programs probably won't be updated by thier authors. It sucks not being able to upgrade to foobar .8 because none of the control modules for LiteStep support it.

Why was this changed anyway? What benefits does it add?
We're all just noise on the wires..

no more foobar2000_class ?

Reply #4 –
Quote
Also, if there's no chance of a return to the old method, how about a plugin? Alot of foobar control programs probably won't be updated by thier authors. It sucks not being able to upgrade to foobar .8 because none of the control modules for LiteStep support it.

Why was this changed anyway? What benefits does it add?

Accessing foobar using this method was never supported.  If you want to access foobar you should be doing it through supported interfaces, ie the command line or a plugin.  There are multiple plugin's out there that supply a defined interface into foobar, off the top of my head, these names may not be exactly right, foo_mirc, foo_command, both do.  All the developers have stated all along that accessing the fb2k window through the class name could break at anytime, and was not a suported way to control the app.  Especially now that we can have interface plugins, controlling fb2k through that method is a bad idea, as your app won't work with any interface plugin but the default one.

no more foobar2000_class ?

Reply #5 –
foo_winamp_spam also mimics part of the Winamp window message API through a hidden window.

foo_mirc is currently blacklisted as a problematic component.

Hmm, isn't there also foo_remote?

no more foobar2000_class ?

Reply #6 –
jesus, foobar is not a winamp. you should be lucky that someone supports your player, encourage more people to do so and if there's any way to make it easier for them then just do it (or just don't do anything to not break it). You play with people and change things that just don't have to be changed to break everything.

Of course i can write a plugin but most people don't even know how to install plugin. and why i came here is talk about writing plugin but ask about why standard method that worked with any installation of foobar has been broken ... i can't believe that it is something we needed to definitely get rid of to move forward in foobar development.

Maybe it is not a standard method but it was easy to use and lot of programs written in various languages could easily support foobar with couple lines of code.

this is just kind of insensitive approach to anyone who ever gave the foobar a chance.

no more foobar2000_class ?

Reply #7 –
Quote
you should be lucky that someone supports your player...

*yawn*

its free software. They ain't getting paid to work on it.

Try another argument. If people can install plug-ins in winamp, its not any harder to install them in foobar.

no more foobar2000_class ?

Reply #8 –
i know ... my application (about as popular as foobar) is also free software.

what i'm saiyng is that they want it to be popular or not? if they do then why are they cutting off people who support their player?

and as to my previous argument, you don't have to install any plugins to get the song information from winamp. up to now you didn't need any to get it from foobar either. what i'm asking is what was the reason to break it

i'm giving arguments, you don't

no more foobar2000_class ?

Reply #9 –
Relying on class names to make your software interact with fb2k isn't a good idea, because

a) alternate interface modules can be used with fb2k, and they may well have their own classnames => your program won't work with them

b) even if every ui programmer was bullied into adopting the same class name, it would create potential conflicts because of different sets of messages they would support

c) it is possible to make an alternate ui activate as a secondary ui => class name conflicts

no more foobar2000_class ?

Reply #10 –
i know the method is not perfect. but it just worked. withous any plugins or anything it worked for 99% of people. many application that used this method are no longer developed so they just stop to work.

i understand all your reasoning and but please you try understanding me. please try to answer this simple question. was it necessary to stop sending song info to window with classname FOOBAR_2000. if it was and it was some kind of obstacle in foobar development then i can understand it.

but more likely answer is that some of the programmers considered it useless so just commented out this line of code .. maybe unaware it may cause problems to other people ..

and now you go, lamers who thought this method will be supported forever, recode your stupid little applications lol

no more foobar2000_class ?

Reply #11 –
Quote
i know ... my application (about as popular as foobar) is also free software.

And your application is?

Foobar's design philosophy has always placed good design above absolutely everything else except possibly stability. If there was a movement away from an old method, there was likely some design issue with it, and it's likely been re-implemented in a much more graceful, easy-to-code for manner.

no more foobar2000_class ?

Reply #12 –
Bernis, the foobar2000 is a free application writen by Peter for one purpose only - to write player that satisfies him and him only!!! He will not add / change / consider things just because someone likes them. You/me/everybody should be very glad if he adds some requested feature, and the reason for this is a usability / proper design of this feature/suggestion. Foobar2000 is indeed not Winamp, so your/mine/somebody's willing to use it or not is just not rellevant. Thank Peter for all his hard work and use supported interfaces next time. 
See ya.

no more foobar2000_class ?

Reply #13 –
ok, thanks for friendly welcome.

if Peter is coding it and it's closed source than i'm just wasting time talking with anyone else. but i believe that if he, the one who codes some application for nothing, would read this, he would understand much more what's going on and would be willing to do something about it.

I'm not saying it name has to be provided via old classname. As you might read in one of the first posts, it is still provided via some other classname, only that it is replaced by text saing "uninteresting" when foobar is minimized.

As i see number of posts in your profiles, i don't even expect that you will try to understand what i'm trying to say. And i quite understand that you're defending the developer, that's how good software communities work.

nevermind ... but well ... i can try to direct my users here, so if they want to try using my app with foobar, they can ask what plugin to use. the best is one that mimicks winamp, i'll personally recommend that one. i hope it will be still supported even in the version 0.9 though

no more foobar2000_class ?

Reply #14 –
Is there a list of command line arguements available anywhere? I can't seem to find anything on the official site. Some obvious ones I tried were /playpause, /stop, /next, and /previous, but /previous does nothing, just gives an error on the console.

Edit: Maybe I should use the search function of the forums.  If anyone else wants to know, just type foobar2000.exe /help, a popup will open displaying all available switches.

Edit #2: Is there some way to combine the /show and /hide switch into a toggle?

Edit #3: Found a way, go me. Use (foobar2000.exe /command:"Foobar2000/Activate or Hide").
We're all just noise on the wires..

no more foobar2000_class ?

Reply #15 –
Quote
Is there a list of command line arguements available anywhere?

foobar2000.exe /?

edit: just noticed, that you've already found the command line help

no more foobar2000_class ?

Reply #16 –
Quote
i can try to direct my users here, so if they want to try using my app with foobar, they can ask what plugin to use. the best is one that mimicks winamp, i'll personally recommend that one. i hope it will be still supported even in the version 0.9 though

What is your app? We may be a little more willing to make concessions/changes if we can see that whatever it is would be useful to integrate more tightly with foobar.

You make a claim that it's as widely used as foobar; while I believe that to be unlikely, I'll wait for a response before judging that further.

no more foobar2000_class ?

Reply #17 –
Quote
and now you go, lamers who thought this method will be supported forever, recode your stupid little applications lol

Yes, that's about the idea. This'll sound harsh, but: Make use of unsupported "features" (unstable properties of the program) --> prepare to suffer.

And this is NOT fb2k-specific at all, apparently.


And it has been stated multiple times on here that fb2k ui window class / window message "interface" might be subject to change and aren't supported ways of interfacing with the player. (I dunno whether there's a note on this in the SDK, I for one never paid attention to this aspect..)
A riddle is a short sword attached to the next 2000 years.