On 09/08/2007 14:49, Ilya Bobir wrote: > 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().
The code in if_cscope does AllocConsole-GetConsoleWindow-HideWindow. What I am wondering is if under a suitable load, the call to GetConsoleWindow fails to return a handle due to the console not having been created - I cannot see any other reason why the command prompt window would remain other than no handle was returned (unless the message to hide gets lost). As I said, I have added some code locally to track what is happening and will see what happens on my machine over the next week. I haven't ruled out user error just yet. ;-) The problem was regular but not predictable. > 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. Sounds like a cunning plan, which I did start looking into. Part of the issue is that the connection to cscope is created via a call to spawnlp() and it was getting into more than I could solve in a couple of hours one evening. IIRC the cscope code was originally unix only and has been hacked to add Win32 support where necessary to be able to use the original posix calls (many apologies to whoever if I am doing them a disservice) which makes changing how the connection is done under windows non-trivial. It would be nice to use CreateProcess to avoid the call to spawnlp() altogether, but note that CREATE_NO_WINDOW cannot be used with Win ME/9x so it is not a complete solution - they will still need the window title hide hack to remove the 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. Agreed. >> 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 >> > > > > Mike -- A 50lb bicycle doesn't need a lock. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
