eric pouech eric.pouech@wanadoo.fr writes:
well, the issue here is that, even in line editing mode, ReadConsole and ReadConsoleInput can be used. the former drops all non keyboard events and produces a string, whereas the later returns the available input records... so, to implement what you propose, the wineconsole would have to know in advance which one of the two functions will be called next:
- in case of ReadConsole, it has to keep all incoming input records, and
release just the string when it's done editing the line
- in case of ReadConsoleInput, all generated input records must be
available in the server to the calling app
OK I see what you mean. Yes this implies that we must be able to tell the server to only return input events to the thread doing the ReadConsole. If I get this right, it also means line editing has to be done in ReadConsole, and that you can't see what you type when the app is not reading. Very annoying, but I guess it's more Windows-like...
Alexandre Julliard wrote:
eric pouech eric.pouech@wanadoo.fr writes:
well, the issue here is that, even in line editing mode, ReadConsole and ReadConsoleInput can be used. the former drops all non keyboard events and produces a string, whereas the later returns the available input records... so, to implement what you propose, the wineconsole would have to know in advance which one of the two functions will be called next:
- in case of ReadConsole, it has to keep all incoming input records, and
release just the string when it's done editing the line
- in case of ReadConsoleInput, all generated input records must be
available in the server to the calling app
OK I see what you mean. Yes this implies that we must be able to tell the server to only return input events to the thread doing the ReadConsole. If I get this right, it also means line editing has to be done in ReadConsole, and that you can't see what you type when the app is not reading. Very annoying, but I guess it's more Windows-like...
yup, that's the way it is... and more, all the echoing is done in ReadConsole... so if you don't call it, you don't get echo of what you type...
so we definitively need the two level approach: - wineconsole generates the input records and stores them in the server - if in line editing mode, a calling thread will ask the server for an exclusive access to the input record queue until the eol is reached
echoing is also requested on client side (and transformed into regular WriteConsole calls)
anyway, I'd like to get back to simple vs complex consoles if I got you right, a simple console handle should be in fact nothing more than a regular file handle which unix fd is set to either 0 or 1 it means that no enhanced mode is used, nothing but the standard libc line editing facilities of the input stream so the use would adequate for a simple program that just uses equivalent of puts/gets (and associated) functions however, I find this very limiting for people who want to use a CUI exe in a pure unix console mode (either when X11 isn't started, or a session done over IP in telnet for example) that's why I was wondering if wineconsole shouldn't also support a (n)curse like interface (in addition to the USER32 one) to help in this area
last but not least, recent exchanges made a simple < 1kloc patch a more serious project of several kloc :-/
A+
-
Alexandre Julliard -
eric pouech