<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 29, 2016 at 5:13 PM, Tomas Hajny <span dir="ltr"><<a href="mailto:XHajT03@hajny.biz" target="_blank">XHajT03@hajny.biz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
1) Instead of using the special handler registered via<br>
SetConsoleCtrlHandler (invoked in a special thread), isn't it possible to<br>
process this event in the exception handler (running in the same thread<br>
probably)?<br></blockquote><div><br></div><div>Not that I'm (or MSDN) aware of.  </div><div>Instead there is a flag ENABLE_PROCESSED_INPUT that's on by default for a console.<br></div><div>It would suppress the handler for Ctrl+C and would pass it as a regular key combination (bringing the desired #3 keychar).</div><div><br></div><div>(as I noted in my comment in the bug tracker, clearing ENABLE_PROCESSED_INPUT flag was used originally. See TurnMouseOff procedure. However it was removed at some point, causing the regression?)</div><div><br></div><div>Windows is raising an exception only if a process is being debugged, so a debugger would be aware of it. That's the only time, whenever the exception is used. MSDN however doesn't specify at what thread the exception is risen. </div><div><br></div><div>So the newest patch removes all threading-related concerns.</div><div><br></div><div>thanks,</div><div>Dmitry</div></div></div></div>