That's my desktop which is Vista x64 and by no means a very clean system as I'm always mucking around with it. It also has a fairly clean Vista x32 dual boot so I can try that later and I think that one might have the Logitech keyboard drivers installed. I have a clean Windows 7 x64 on my laptop so I can also try that later on.

Awesome, thanks. I'm really interested to see the results of the Windows 7 x64 test.

It turns out that the laptop already had PhpED 5.9 installed. I can also reproduce your problem on that laptop. It's primarily my gaming computer together with Remote Desktop for work use. So it's very clean; no mucking around install utilities and drivers, etc. It also still has UAC enabled.

I plugged the Logitech keyboard in, then tried the mute/volume controls whilst in a PhpED editing window and they didn't work. Clicking on a PhpED panel did work.

I looked at the 'run as administrator' thing that Sangoku suggested and that doesn't seem to make a lot of sense. I'm in UAC mode on the laptop, PhpED is not run in admin mode as it doesn't need it and the controls don't work. What's winapm anyway? Never heard of it. I've heard of winamp but have never used it.

I also tried remote desktopping from the laptop to the Vista computer and then the mute/volume keys worked fine from the remote PhpED again.

So whilst PhpED editor related, at least in my case it also appears to be Windows 7 related and works fine on Vista.

I'll see if I have time to upgrade PhpED on the laptop to see if that makes a difference.

I've just installed latest PhpED 6.1 on Windows 7 x64 and that also does not work with the mute/volume keys whilst in the PhpED editor window. Seems to work if any other window has focus.

No Logitech drivers are installed and the Microsoft HID Keyboard Device driver is listed as being used for my Logitech keyboard.

I have this same issue on Windows 7 x64. My keyboard is some I-don't-know-the-model which came with Acer. Those music player specific buttons do not work if code editor has focus. They do work if focus is in Workspace, Code Navigator, or Log. Other windows I didn't try.

I don't have any problems with mute/pause/etc

Do you by any chance have logitech mouse or keyboard and/or installed logitech software?
In the past we received some reports with similar problems when logitech drivers were installed.

Hi Dmitri, I don't have any Logitech drivers installed on my Windows 7 x64 laptop and the buttons don't work. I also don't have drivers on my Vista x64 desktop where the buttons do work.

I seem to remember that multimedia buttons are just keycodes just like any key so it is possible that something in the editing window is filtering them. If time permits I'll do a spy on the window messages to see what happens.

I have the same issue: Windows 7 64bit, Microsoft Keyboard + latest driver (Intellitype):

The Calculator/Mute/Volume buttons don't work when the PHPEd "editor" has focus, it works fine in Explorer/FTP Tree or other areas. In addition ALL system wide Hotkeys don't work, e.g. ones I've created with Autohotkey or apps that can create global ones (Foobar, RSSOwl).

Here's info for my drivers:

Keyboard:
Driver Provider: Microsoft
Driver Date: 21.6.2006
Driver Version: 6.1.7601.17514

Mouse:
Driver Provider: Microsoft
Driver Date: 21.6.2006
Driver Version: 6.1.7600.16385

These drivers were automatically installed by Windows, I have not installed any specific drivers for keyboard/mouse.

Intensive investigation of the problem resulted in the following:
The problem has no relation to neither editor the focus was in, nor to phped application. It's Windows limitation -- it stops sending/processing a message as soon as internal kernel stack reacheches some "certain" level. This results in much more problem than just non-working "mute" button. Due to stack limit, Window positioning, scrolling and the other events may not properly propagate as well, leaving some controls unaligned, with wrong size etc.
Kernel stack usage heavily depends on number of windows (controls) stacked one on top of another. It's also known that Vista takes more memory in the stack than XP under exactly the same conditions, and W7 takes more space than Vista. Also -- 64bit OS takes almost as twice memory in the stack as 32bit OS, while the STACK LIMIT is fixed and does not depend on bitness, OS version, or amount of physical or virtual memory. That's why most of you encountered this problem under W7 64bit.

In order to resolve the problem you may want to do the following:
Walk through all tabs (View->Tabs, View) and 1) click on [Pin] button to pin them 2) drag on the header to dock off 3) eitehr close or drag on top of another tab to make composition. Target is to leave editor/main window containing fewer controls.

Also you may want to report to microsoft.
I already reported 6 years ago and got an answer confirming the issue and telling they won't fix it. Perhaps, if they get more reports, they will think about a fix.

PS:
Regarding logitech, their software installs Windows Hook in each process (using special DLL they inject there) and this hook make the kernel stack usage larger. That's why with logitech drivers you may encounter the problem even under XP 32bit.

Thank you for the detailed description.



I've closed all tabs/windows and only see the editor now (with one open, empty file). Hotkeys still don't work.

I understand that there's a limit to resources, normally I only use the "Explorer" tab pinned next to the editor, I'm surprised this pushes windows to the limit. Any other idea what I can try out? Thank you!

I've just closed all panels in PhpED, so I just have a single editor window. Media keys still do not work. Whilst that editor window is showing, if I for example bring up the settings window, media keys work fine.

I did a message trace on PhpED to watch the WM_KEYUP, WM_KEYDOWN and WM_APPCOMMAND messages. With PhpED on Vista x64 I can see the APP_COMMAND messages passing fully up to to a TdxLayoutDockSite window which is 3 levels deep under ClientDockSite and works. On Windows 7 x64 it stops at 6 levels deep and doesn't work, so the messages are not passing as far back up the window hierarchy.

So, I agree that this would likely be a stack related issue. That issue is known to start occuring with nesting depths of 12-15 (with the limit being 50) and sometimes as low as 8 levels. I think the TdxLayoutDockSite window at the point of failure was 13 deep. Forums indicate many developers have been caught by this problem and had difficulty determining the cause.

Based on that theory, floating an editor window might effect the issue, and it does. If you float an editor window then the media controls work again. Whilst that does not prove it is stack related, it would seem to reasonably confirm that the editor window is not itself at fault.

There are workarounds to the problem, such as changing the number of nesting levels (which could be very difficult, particularly when using third-party controls) or manually handling certain messages in some way. Well, PhpED is an IDE not a media player so I'm not really expecting PhpED to handle these messages in a special way and I'm sure there are more important developments to be done.

I don't personaly find the loss of media controls a major issue; I was more interested in the reasons for it happening.