Nico Heinze wrote: > --- In [email protected], "Brett W. McCoy" <[EMAIL PROTECTED]> wrote: >> On 9/4/07, remarknibor <[EMAIL PROTECTED]> wrote: >> >>> I just run it from the command prompt in that window, so a >>> console one. The code isn't very revealing, but this is the >>> bit in which i'd like to embed the time check: >> As Thomas remarked before, you won't be able to do what you >> want with just plain ol' console code... you will need to >> design come event-handling into your application. There are >> console APIs (like ncurses) that can handle this for you, and >> provide you with text windows, menus, I/O handling, etc. >> Or go the full route and write a Windows application (which >> is event-based to begin with) using one of the many toolkits >> available. I'd start with something like wxWindows or fltk, >> they are relatively easy to use, unless you really want to >> delve into the Windows SDK. > <snip> > > One alternative might be to use a multi-threaded application; one > thread starts a timer which will run 10 minutes; the other thread > invokes getline(). If the timer expires before the getline() thread > has finished, then stop the getline() thread and proceed as you like. > Brute force but the only way I see without diving right into Windows > programming including all its message-based architecture; in this > point I totally agree with Brett and Thomas. > > Regards, > Nico
MSDN Library documentation on forced termination of threads: -------------- TerminateThread is a dangerous function that should only be used in the most extreme cases. You should call TerminateThread only if you know exactly what the target thread is doing, and you control all of the code that the target thread could possibly be running at the time of the termination. For example, TerminateThread can result in the following problems: If the target thread owns a critical section, the critical section will not be released. If the target thread is allocating memory from the heap, the heap lock will not be released. If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent. If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL. -------------- In other words, "We really have no idea why we exposed this extremely dangerous function to user-mode code, but please don't use it." -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* MyTaskFocus 1.1 Get on task. Stay on task. http://www.CubicleSoft.com/MyTaskFocus/
