foo_lirc plugin, LIRC compatibile remote control plugin! Options

[levsh]

Hello!

I want to announce foo_lirc plugin for controlling the FooBar2000 from a remote control. It is in the alpha stage of the development, but it already has the support for this features:

- configurable LIRC/WinLIRC server address and port
- supported player controls: play, pause, stop, prev.track, next track, track position and volume.

The plugin and its source code is available at SourceForge page, you may download binaries from here:
foo_lirc binary and sources

I'm waiting for comments and list of missing actions

Screenshot

This post has been edited by levsh: Mar 3 2004, 13:01

[jay7]

ding-ding, bug report here!
Well, may be I'm the last man on Earth still using eons ancient W95OSR2, but foo_lirc has problems under this OS-alike.
First, if i close and restart WinLIRC while foo_lirc is enabled and then press 'Connect' - fb2k crashes badly, often with the pitiful w95
If i set `enable` off then on and press 'Connect' - it is ok.
As i can see, that's because of setting a hook in StartLircClient() when StopLircClient was not called and the hook is already hooked. The simplest solution I see is to keep a flag like HookSet and act accordingly not to try set hook twice.
That was simple. Now to the sad part:
The plugin does nothing in my case! It configures perfectly, seeing all commands from WinLIRC and highlighting assigned actions. But besides that it does nothing.
Spy++ shows those 'DEAD FEED' messages pass to fb2k main window.
It is something with those hooks too, I feel it but the only w32 compiler i have is LCC and it knows nothing 'bout C++ so I'm just sitting aside
BTW, is all this hooking The Only Right Way, or it can be done more straightly?
slight offtopic
The only reason I keep windows on that ancient box for - fb2k.
Digged the net many times, coudn't find nothing comparable to it.
But don't expect me to buy a new box with bloody XP inside just to control fb2k with remote.

This post has been edited by jay7: Aug 1 2004, 20:26

[Phi]

ding-ding, bug report here! 

OH NO!S!1 I'll have a look when I get a chance. Most of my "bugfixes" have just been hacks on existing code, so I'll take the time to rewrite it in the next few days.

BTW, is all this hooking The Only Right Way, or it can be done more straightly?

There are definitely better/easier ways to do it. Posting messages to the main foobar window is pretty dodgy.

PS. come on, at least upgrade to an OS thats still supported by MS

[jay7]

OH NO!S!1 I'll have a look when I get a chance.  Most of my "bugfixes" have just been hacks on existing code, so I'll take the time to rewrite it in the next few days.

Oh, I'm really sorry to bother you, but it's definitely unreal to run MSVC++ on my p1-166. There's no need to rewrite, just several fixes.

There are definitely better/easier ways to do it. Posting messages to the main foobar window is pretty dodgy.

Then let's take away all those hooks!
patch can be as following, although I can't check it

CODE

*** foo_lirc.cpp.old    Tue Jun 29 15:40:42 2004
--- foo_lirc.cpp    Tue Aug 03 23:55:22 2004
***************
*** 32,38 ****
 bool config_mode;
 HWND hConfigWindow;
 HWND hMainWindow;
- HHOOK lirc_hook;
 
 static HWND status_wnd;
 
--- 32,37 ----
***************
*** 129,135 ****
       }
       else
       {
!        SendMessage(hMainWindow, WM_REMOTE_KEY, 0xDEAD, 0xFEED);
       }
   }
     }
--- 128,134 ----
       }
       else
       {
!        g_actions.process_keypress(lirc.key_name);
       }
   }
     }
***************
*** 331,348 ****
 
 static cfg_action g_actions("Assigned actions");
 
- LRESULT CALLBACK LircHook(int nCode, WPARAM wp, LPARAM lp)
- {
-  PCWPSTRUCT msg;
-  msg = (PCWPSTRUCT)lp;
-
-  if (nCode == HC_ACTION && msg->message == WM_REMOTE_KEY &&
-      msg->wParam == 0xDEAD && msg->lParam == 0xFEED)
-  {
-      g_actions.process_keypress(lirc.key_name);
-  }
-  return CallNextHookEx(lirc_hook, nCode, wp, lp);
- }
 
 bool StartLircClient()
 {
--- 330,335 ----
***************
*** 355,366 ****
   return false;
     }
 
-  lirc_hook = SetWindowsHookEx(WH_CALLWNDPROC, LircHook, NULL, GetCurrentThreadId());
-  if(lirc_hook == NULL) {
-      MessageBox(hMainWindow, "Failed to set Hook", szAppName, MB_OK);
-      return false;
-  }
-
     lirc.thread_id = _beginthread(LircClient, 0, &lirc.socket);
     if(lirc.thread_id == -1) {
   MessageBox(NULL, "Failed to create thread, foo_lirc will be disabled.", szAppName, MB_OK);
--- 342,347 ----
***************
*** 371,377 ****
 
 void StopLircClient()
 {
-  UnhookWindowsHookEx(lirc_hook);
     lirc.client_running = false;
 }
 
--- 352,357 ----

[Phi]

OH NO!S!1 I'll have a look when I get a chance.  Most of my "bugfixes" have just been hacks on existing code, so I'll take the time to rewrite it in the next few days.

Oh, I'm really sorry to bother you, but it's definitely unreal to run MSVC++ on my p1-166. There's no need to rewrite, just several fixes.

It's no bother, I've actually already done most of the work.

Then let's take away all those hooks!

Well, the whole point of posting messages to the main window (and hooking it to intercept them) was to ensure that process_keypress() (and subsequently, menu_manager::run_command()) was called from the main thread. I'm not sure how mm::run_command() actually works, and whether its safe to call it from the socket thread as you have done here.

Anyway, I've rewritten the code to use an asynchronous socket so this won't be an issue in the next release.