Mike Williams wrote: > Hi > > [...] > > Yep, I submitted a patch along these lines. Unfortunately, I still > don't think it's a solution. I still managed to end up with a rogue > sticky command prompt. This was on XP SP2 so using GetConsoleWindow() - > looks like a bug in Windows where the message is getting lost when the > system is loaded. Unless there is a deeper darker Windows way of > ensuring messages don't get lost. >
I don't think this is a bug. According to MSDN (http://msdn2.microsoft.com/en-us/library/ms683175.aspx) GetConsoleWindow() is supposed to return the handle of the console of the calling process. GVim has no console so, GetConsoleWindow() will return NULL. Whenever a console process is started it needs a console. If parent process does not have one then a new console will be automatically allocated and associated with the child process. I think that looking for the console created for the child process is actually incorrect approach to the problem and thus it does not work reliably. If you what a child process to interact with a console your process controls you need to create one in your parent process and ensure that child process uses your console. If child process does not explicitly detaches from the parent console than by default everything should be as easy as: AllocConsole(), GetConsoleWindow(), [HideWindow()], CreateProcess(). It may be possible, to do without the console altogether. The STARTUPINFO structure that is passed into the CreateProcess() call has 3 field that may be filled with input/output handles for the new process (HANDLE hStdInput; HANDLE hStdOutput; HANDLE hStdError;). I think that if the parent process will create 3 pipes and will pass appropriate ends of the pipes to the child process, then the child will not have to allocate a console. If this scenario works it would be nice to have Vim use it as this way we'll get rid of annoying blinking when a child console process is started and, maybe, child startup time will be decreased. Note, that parent process will probably at least have to read both standard input and standard error pipes - otherwise the child process will hung, just as with Unix pipes. > I'll add some debug to record if it failed to find the console handle so > I can check the next time the window sticks again. > > TTFN > > Mike > --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
