Responding to WM_SETTINGSCHANGE?

[vefatica]

I have a VBA script assigned to a certain Excel file's "save" event. After setting a few user environment variables, that script does this.

Call SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, 0, _
    "Environment", SMTO_ABORTIFHUNG, 5000, dwResult)

When I save that Excel file, I notice behavior that makes me very curious ... behavior that depends in TCC in a rather peculiar way.

If TCC is not running, or TCC is executing "DELAY 30" or TCC is executing "COPY ftp://..." the script terminates (hourglass disappears) in about 1 second.

If TCC is idling, the script terminates in about 3.5 seconds. (!)

If TCC is executing "COPY \\remote\...", the script doesn't terminate and Excel goes into a "not responding" state (can be 20-30 seconds) until the COPY is finished. (!!)

So I wonder ... Why isn't TCC idling among the best of the scenarios? And why is the last one above so bad?

I save that Excel file every day and I've tested the scenarios above (and a few others) many times.

 

[rconn]

I have a VBA script assigned to a certain Excel file's "save" event. After setting a few user environment variables, that script does this.

Call SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, 0, _
    "Environment", SMTO_ABORTIFHUNG, 5000, dwResult)

When I save that Excel file, I notice behavior that makes me very curious ... behavior that depends in TCC in a rather peculiar way.

If TCC is not running, or TCC is executing "DELAY 30" or TCC is executing "COPY ftp://..." the script terminates (hourglass disappears) in about 1 second.

If TCC is idling, the script terminates in about 3.5 seconds. (!)

If TCC is executing "COPY \\remote\...", the script doesn't terminate and Excel goes into a "not responding" state (can be 20-30 seconds) until the COPY is finished. (!!)

So I wonder ... Why isn't TCC idling among the best of the scenarios? And why is the last one above so bad?

In the last case, TCC is waiting for the Windows CopyFileEx API, so you'll need to ask Microsoft what they're doing.

In the TCC idle case, TCC is in a wait loop looking for a keyboard input event. If there isn't one waiting, TCC gives up its time slice (with a Sleep(20)) and looks again. You'll have to ask Microsoft why Windows doesn't pass the message on to conhost.exe (TCC never sees Windows messages).

 

[vefatica]

TCC must see the messages in order to "update the environment on system change" (which it does). Yes/no?

With Spy++ I've watched the TCC.EXE class window, and both of conhost's top level windows receive the messages. In fact, when all is said and done, those three windows, as well as TCC's other toplevel windows (ipworks) receive 6 of those messages. SMTO() is a strange critter. It seems to keep sending those messages to everyone (even to windows that have responded) until all have responded or until it gives up. In any event, some window process is slow to return. When the "COPY \\remote\..." is in progress, all the windows I've mentioned receive the message ... then receive it again 5000ms later ... then again 5000ms later ... and so on. Someone isn't responding. I have no way of telling who that is but apparently it's one of TCC's windows.

I'm not complaining. The behavior is satisfactory (though, at times, not great). The "COPY \\remote\..." thing was discovered completely by acciddent. Unless I'm doing the two things at the same time, deliberately, for testing, I doubt it'll bother me again.

 

[vefatica]

It seems to have something to do with IPWorks.

I wrote a little plugin to sent WM_CLOSE to the window of my choice. Closing the "TCC.EXE" class window made no difference. So I closed the "__ipworksssh_socket_wnd__" class windows one by one. When I had closed the last of them, a "MSCTFIME UI" class window and one of two "IME" class windows had also closed (on their own?), and the odd behavior was gone. The SendMessageTimeout() in my VBA script returned as if TCC weren't running ... even while TCC was executing "COPY \\remote\..." (which previously had really messed things up). Alas, I couldn't do the "COPY ftp://..." test because IPWorks was rather crippled.

 

[rconn]

TCC must see the messages in order to "update the environment on system change" (which it does). Yes/no?

Yes, but all TCC does is set a flag that the environment changed, then call DefWindowProc (which is handled by conhost).

 

[vefatica]

Yes, but all TCC does is set a flag that the environment changed, then call DefWindowProc (which is handled by conhost).

Yes, I figured TCC only set a flag since the actual update isn't done until the next prompt. I doubt DefWindowProc is handled by conhost since the TCC.EXE window is of your own class ... might as well just return something saying you handled the message. It doesn't really matter, though, because the TCC.EXE class window doesn't seem to be the one that's causing the delays.

OT: Do you know if there's a way to avoid those IME class windows altogether ... system-wide? I have only one input method here (the default, US English). It seems silly that every window class gets an IME class window.