Re: [PDCurses] Update to Win32a posted
William McBrine wrote: Actually resizing works in SDL (both kinds -- user-driven and program-driven). DOS, OS/2 and Win32 console all do program-driven resizing (i.e. the user can't resize by dragging the window). (Groan) I _thought_ that was the way it worked... I tried an SDL app and couldn't get it to user-resize. Now it's working just fine. Dunno how I messed that up. I have corrected the Win32a page to mention that the SDL flavor is user-resizable, and have also posted fixed code that lets you use PDC_set_resize_limits() if you want to be Win32a specific, or use ttyname[0...3]. All explained on the page. (Still need to Sourceforge everything. That will probably be my next step; I can't think of anything I really want/need to do with the code in terms of features or bug fixes.) -- Bill
Re: [PDCurses] Update to Win32a posted
Hi Anatoly, anatoly techtonik wrote: ... If you want to have user resizable windows, you have to set ttytype[0] = 1; Looks magical. Is it possible to make it a "property of the window" or more obvious API switch? I didn't like that very much either. My preference was to make use of the PDC_set_resize_limits( ) function. A call such as PDC_set_resize_limits( 20, 55, 70, 100) will tell Win32a that the window can be 20 to 55 lines high and 70 to 100 columns wide. Make it PDC_set_resize_limit( 20, 55, 80, 80), and the window will be fixed at 80 columns and cannot be resized horizontally. If the first and second arguments are equal, and the third and fourth are equal, you have a non-resizable window. The problem is that, at least at present, PDC_set_resize_limits( ) is available only in Win32a. I rather like the fact that if one compiles PDCurses as a DLL, you can swap between the SDL, Win32 console, and Win32a flavors just by swapping DLLs, no recompiling required. But if your program calls PDC_set_resize_limits( ) and you try using the SDL or Win32 console DLLs, you get a "function not found in DLL" problem. _However_, I think I've found a way to have our cake and eat it too. You can now call PDC_set_resize_limit( ) before initscr( ), as described above. This will mean you're stuck with Win32a only, though. _Or_, you can add lines such as ttytype[0] = 20;/* Window must have at least 20 lines in Win32a */ ttytype[1] = 55;/* Window can have a max of 55 lines in Win32a */ ttytype[2] = 70;/* Window must have at least 70 columns in Win32a */ ttytype[3] = 100; /* Window can have a max of 100 columns in Win32a */ This remains a little magical. But you can do it without causing trouble when using non-Win32a DLLs. I've made this change, and am testing it out. Seems good so far... with luck, I'll post it shortly. Yet another solution would be to add PDC_set_resize_limit( ) to all other flavors of PDCurses. It would do absolutely nothing in Win32 console, SDL, DOS, and OS/2, where resizing can't be done. It _could_ work as advertised in the X11 flavor. Thanks for mentioning this. As I wrote, I really didn't like the ttyname[0] = 1; solution. The above looks somewhat less ugly. -- Bill
[PDCurses] Update to Win32a posted
Hello all, I have posted a pretty significant update to the Win32a flavor of PDCurses: http://www.projectpluto.com/win32a.htm In particular, I fixed some problems caused by the fact that by default, the Win32a window was user-resizable. The only other flavor of PDCurses for which this is true is the X11 one, and there are plenty of programs out there (including most of the demo ones) that don't handle user resizing. In Win32a, if the user resized a window and the resulting KEY_RESIZE message wasn't handled, you could get garbage or crashes. I fixed this. But I then made non-user-resizable windows the default. If you want to have user resizable windows, you have to set ttytype[0] = 1; before calling initscr(). This essentially makes the promise to Win32a: "Yes, it's OK for users to resize the window; I'll handle the KEY_RESIZE event correctly." -- Bill
[PDCurses] Win32a update posted: internationalization, drawing fixes
Hello all, Following some advice both on- and off-list, I've fixed the internationalization issues in Win32a. In the process, I figured out some of the problems in the wide-character (Unicode) flavor, and got that to work as well. I'd not realized this, but some previous improvements involving cursor display had not been posted. So you'll get those with this update as well. See http://www.projectpluto.com/win32a.htm for info and code. I think this is all ready for merger with "official" PDCurses. (I've been using it in several projects, under both Windows and Linux/Wine, for quite a while now.) If you see any problems, though, please let me know! -- Bill
Re: [PDCurses] Extended ASCII character encoding
>> Is there any particular character encoding associated with PDCurses? No. In the case you're talking about, the input comes from ReadConsoleInput(). It's Windows itself that determines the active console code page. (The tables in win32/pdckbd.c are all just for things like ALT and function keys.) You could set it to a so-called ANSI page if you wanted. Thank you; this does clear things up. With a little experimenting, this is all starting to making sense to me. With the current Win32 scheme, it looks as if one could switch to, say, Russian, and have Russian text entered and displayed. In theory, my Win32a version should be able to do the same thing. After which, I think the only internationalization issue would be bi-directional text for Hebrew, Arabic, etc. I'll leave that problem for another day. The exception is if you're using the WIDE build. In that case, you always get Unicode. That's actually what I'd recommend. I'm increasingly seeing why. Handling 8-bit chars has all sorts of strange nuances to it I'd not fully appreciated before. Though I think, between your replies and some testing at my end, I'm seeing how to get all this to work... it'll probably result in an update to Win32a in the next few days. > I should add, there is one issue with this: The box-drawing > characters. In the Win32 console port, these are defined in terms of > CP437 -- both because that's the default console code page (for the > U.S.), and because there aren't any box-drawing characters in the > "ANSI" code pages. But this problem is obviated if you use the WIDE > build. Also obviated in Win32a. If the A_ALTCHARSET flag is set, we know to show a suitable Unicode character. The actual display of text is handled using TextOutW (wide-char function) even in the non-WIDE build. So at least I don't have that problem to fix as well. Thanks! -- Bill
[PDCurses] Extended ASCII character encoding
Hello all, Just got an inquiry recently about a problem in my Win32a flavor of PDCurses, which has led to a more general PDCurses question. The inquiry came from a gent using a Swedish keyboard layout. Win32a was insisting on treating it (at least partly) as being on a US layout. I think I've worked through these problems. There were also some issues in how extended ASCII (characters 128 to 255) were rendered. Swedish uses characters such as "a-ring" (a with a small ring over it), a-umlaut, and o-umlaut. Accented characters such as these (and similarly accented characters in French, Italian, etc.) were shown completely wrong. I'd shown extended ASCII using the old DOS/IBM encoding, and realized they really ought to be shown in Latin-1. Which leads to a problem. The plain ol' console flavor of Win32 uses DOS/IBM encoding. If you've a Swedish layout and hit a-ring, a-umlaut, and o-umlaut, getch() returns 0x86, 0x84, and 0x94. Output those same values on screen using addch(), and you get a-ring, a-umlaut, and o-umlaut; i.e., DOS/IBM encoding is consistently used. Do the same in Win32a, and those values become 0xe5, 0xe4, and 0xf6, following the Latin-1 (and Unicode) values. Which leads, at last, to my question. Is there any particular character encoding associated with PDCurses? (Presumably the IBM/DOS encoding.) If one hits, say, a-ring on a Swedish keyboard layout, is it "acceptable" for getch( ) to return 0x86 on one PDCurses implementation, but 0xe5 on another? Thanks! -- Bill
[PDCurses] Updated/fixed Win32a flavor of PDCurses
Hello all, I've updated my Win32a (PDCurses in a "for-real" GUI window) page at http://www.projectpluto.com/win32a.htm and highly recommend that if you're using Win32a, you get the current version. The most significant change is that Thomas Cool directed me to a (rather embarrassing) bug that was causing crashes when some Win32a-using programs closed. But in addition, there are a variety of small improvements, including such niceties as support for tilt-wheel mice (*) and triple mouse clicks. I do have hopes of getting this folded this into "official" PDCurses eventually. Just having this on a Web page of its own has some shortcomings. If you see any issues with the new version, please let me know; I'd obviously like to clobber all bugs before trying to merge things. And we'll probably want to change the name to "WinGUI" or "Winses" or something like that. -- Bill (*) Tilt-wheel mouse support also exists in the development version of "official" PDCurses for Win32, SDL, and XCurses; I just borrowed what was going on there.
[PDCurses] Update to Win32a
Hello all,
I've a request for comments from anyone currently using the Win32a
(Windows GUI) flavor of PDCurses. This is described and downloadable from
http://www.projectpluto.com/win32a.htm
I regard it as almost entirely ready to just get merged in with the
other flavors of PDCurses, except for one nagging issue that has been
reported by two users: they have been seeing crashes when their software
exits. That's at _exit_: endwin() has been closed and in theory,
PDCurses is done doing anything it's going to do.
This has happened in Windows 7. I've been unable to duplicate it. If
anyone else has seen this issue and can shed any light on it ("gee, it
happens when I do X but doesn't when I don't do X"), could you please let
me know off-list?
You should probably try it with the latest and greatest version. This
does fix a bug or two, adds support for fourth and fifth mice buttons and
triple clicks, hotkeys for changing the font size, and so forth.
Thanks! -- Bill
Re: [PDCurses] cursor on white background is invisible (xcurses)
Hi John, I may have shot off my mouth too quickly. My experience is mostly with the DOS, Windows, and my own Win32a (Windows GUI) flavors of PDCurses. In these, the cursor always just inverts colors, and blinks. The only difference between curs_set(1) and curs_set(2) is that the former causes the bottom line of the character cell to blink, whilst the latter causes the entire cell to blink. (And curs_set(0) shuts the cursor off.) SDL does the same thing, except the cursor doesn't blink. Sounds as if XCurses fills the cursor block, instead of inverting it, which would differ from the above cases. (I only used XCurses briefly, some time ago.) I'd think inversion would be greatly preferable to filling. -- Bill
[PDCurses] Re: New 'real Windows' PDCurses
Hello all, Improvement continues to Win32a, and I've posted another update. I could easily be cluttering up this list with a post every few days, but since this is supposed to be a low traffic list, I've done what I perhaps ought to have done from the beginning: I've started a page at http://www.projectpluto.com/win32a.htm describing what I've done, known problems, list of changes, thoughts of what's to be done, and so on. Henceforth, I'll post news on that page, rather than pestering everybody here. Win32a basically works now. There are a few bugs to be ironed out, though, and some small improvements I'd like to make. More about that in the above page... comments are welcome. -- Bill
[PDCurses] Re: New 'real Windows' PDCurses
Hello all, I've gotten a little more feedback, and have posted a revised 'real Windows' PDCurses at http://www.projectpluto.com/win32a.zip (now up to about 50 KBytes). As described in the 'to_do.txt' file, this includes various fixes. Mouse movement events are now reported. I realized that the middle and right buttons were swapped. The window now resizes properly, not leaving a little partial-character sliver at the right and/or bottom edges. Marking text by dragging with the mouse doesn't leave garbage on the screen anymore, and flickers less. If you set the LINES and COLS environment variables, they actually get used now. Things are looking pretty good for this version, but there are a few minor issues (described in 'to_do.txt'). Bug reports/comments welcome (and my thanks to those who have sent them in thus far). Incidentally, if you've a particular issue to report, I'd appreciate it if you can e-mail an executable linked to a DLL. The nice thing about that is that I can swap in the Win32 DLL, or the SDL one, or my new DLL, and see what changes. I can also fix my DLL and try it out with your program right away. -- Bill
[PDCurses] Re: New 'real Windows' PDCurses
Hello all, I got a bit of feedback via private e-mail, and have done a bit of further work, which has resulted in an updated http://www.projectpluto.com/win32a.zip I found and fixed a bug or two, and there's now a menu bar with options to increase/decrease font size, and to paste from the clipboard. Click that option, and any text in the clipboard is fed through getch(). To put text into the clipboard, just drag a rectangle with the left mouse button pressed. I may add the ability to disable this behavior, since there could be times when you want that action to do something completely different, specific to your program. 'to_do.txt' lists assorted remaining issues and thoughts. -- Bill
[PDCurses] New 'real Windows' PDCurses
Hello all, I've been working on creating a "for-real" Windows version of PDCurses. That is, instead of using the current Win32 version that works using a console, I'm creating a window and drawing text to it using the GDI and so forth. It appears to be working Just Fine. (It helped, of course, that I was able to use much of the original Win32 version, some of it completely unaltered. For example, 'pdcclip.c' didn't change at all.) For the nonce, at least, I'm calling this 'Win32a', to distinguish it from the console-based Win32 version. I did this because I wanted a full implementation of PDCurses. It has underlining, side-lining, bold and italic fonts, and blinking text. It has 256 colors and 256 color pairs. All mouse events, including wheel mice events, are supported. You can resize the window by dragging it with the mouse, or programmatically with resize_term(). About the only things that aren't supported are mouse triple-clicks and certain deprecated alternate character set bits (ALT_S1 through ALT_S9). The current source code is at http://www.projectpluto.com/win32a.zip (about 35 KBytes) Comments/thoughts for improvements are welcome. Hope it's useful, or at least interesting, to somebody other than just me. 'to_do.txt' in the above ZIP contains some of the following comments, but I'd like to raise them here... just a few questions that arose in my mind in the process of writing this code, and I'm hoping somebody with more knowledge of Curses can shed some light on them. In both this version and the SDL one, if the user clicks the Close button, exit( ) is called. This seems rather graceless. It would be nice if at least the option of perhaps the Close button putting a KEY_EXIT on the queue would be welcome. The app would then be responsible for responding appropriately to that key. I think X11 does this same sort of graceless exit. Before taking it upon myself to mess around with something this basic, though, I thought I'd ask for thoughts from this list. Also: what's the point of invisible text? I note that A_INVIS = A_ITALIC. At least for the nonce, I'm assuming that italic text is more useful than invisible text (after all, one can always fake the latter using spaces, or by setting a color pair where foreground = background). -- Bill
