Suggestion: Support for East Asian code pages
A free, cross-platform emulator for GW-BASIC, PCjr & Tandy BASIC
Brought to you by:
robhagemans
Menu
▾
▴
I don't really think cut & paste will currently work on my Win8.1 x64 system. It may be because of these keys are in conflict with Win8.1 system keys (Windows 8/8.1 obviously extended the use of Win-key combinations for shortcuts, see for example here: http://productivity.ben61a.com/windows/windows-8-shortcut-keys.php), or may be because of other reasons. However, this feature will certainly be useful if it indeed works.
Perhaps the Windows shortcuts can be switched off to check?
Do you get any warnings on the command line? I suspect the default download of Pygame for Windows doesn't actually support cut & paste at all; if that's the case you should get a warning message that tells you so. You'd have to work with a custom build to solve the issue.
I have tried to turn off all Win-key shortcuts by following this page (http://superuser.com/questions/670731/how-do-i-disable-windows-k-shortcut-key-on-windows-8), but after editing the item in the Local Group Policy Editor and restarting the PC, keys such as Win+C are still assigned to system shortcuts, and I am not sure why. On the other hand, disabling a certain Win+X hotkey remapping via the registry may actually disable the scan code for the key completely. Also, I don't get any warning messages on the command line, so I expect that it will not be a Pygame problem.
OK, it'll have to wait for my new hard drive to arrive before I can check on Windows.
I have a suggestion: why not try to support the selection and/or cut & paste of texts by mouse? This will probably be much more convenient and will also avoid the issue of keyboard shortcut conflicts.
It's a good suggestion - I'll have to avoid conflicts with the PEN implementation which uses the mouse and it will be confusing on Unix because I can't find out how to support the usual 'mouse clipboard' that X11 provides, but perhaps there's a way around that. Maybe just use the right mouse button and leave the keyboard shortcuts in for people without a right mouse button.
I have uploaded the GW-BASIC program which includes a few smaller programs as I mentioned earlier. Before uploading it I have removed some unnecessary code for easy testing. Some of these included smaller programs (such as the 8-puzzle game) were already uploaded as individual programs earlier in this thread. The main menu is also very similar to the sample menu program that I uploaded earlier, but for some reason the UP and DOWN arrows do not work properly in the menu if the program is run by PC-BASIC, but it will work fine if it is run by GW-BASIC. Also note that the program may ask for password sometimes, and in such case just enter "pass" as password (you can actually change the password in the program too).
The actual program in the attachment. It is named WERSPEC.BAS because it is a special version of the WER program I have made earlier after making some simplifications.
Thanks! I'll try and figure out what's up with the menu.
That was an interesting bug, only triggered when you'd try to swap two array elements and there exists a variable of the same name. It's fixed now.
When I try to run the latest build in git, it always shows the following error (no matter what codepage I select), and I don't know why:
File "D:\test\pcbasic-code\backend_curses.py", line 55, in <module>
curses.KEY_F1: '\x00\x3b', # F1
AttributeError: 'NoneType' object has no attribute 'KEY_F1'
Fixed that, it should work now
The latest version has copy & paste under windows (and linux), using the left mouse button to copy and the middle mouse button to paste.
Thanks! The good thing is that it does work. But I think using middle mouse button to paste is a bit awkward. The middle button of my wireless mouse is like a wheel, which is easy to scroll but very hard to press, not to mention that many mice may not necessarily have a middle button (but I believe over 99.9% of all mouses would have a right button), so I think pasting by right mouse button would be a better and more natural option. In case that you have not, you may look at how copy & paste works in a Command Prompt in Windows, and I think it would be better to make the copy & paste in PC-BASIC work in a similar way as in Command Prompt, which would be familiar to users. It will be also fine to use just the right mouse button to copy & paste if you want to avoid conflicts with the PEN implementation.
Copying with the left button and pasting by middle mouse button is the standard in Linux and anything that runs X11; people have been doing it for decades with scrolling mouse wheels. You get used to it quickly, it's fast and efficient.
By default, copying and pasting on Windows command prompt requires the use of a menu option, then using the mouse and the shift key at the same time. Frankly, it's clunky and inconvenient. I'm not sure if you're asking me to implement a drop-down menu system here (which is not going to happen) or if you're referring only to the hidden mode where you can paste with the right mouse button. Not many people are aware of the latter mode, whereas all Unix users know they can paste with the middle mouse button.
Anyway, I've added a
--mouseoption which you can use to assign mouse buttons to your preferred function. The default is now--mouse=copy,paste,pen(with the pen assigned to the right mouse button) but you may perhaps prefer--mouse=copy,pen,pastein which case you can set that as your default inPCBASIC.INI.OK, the new --mouse option will work too. As for the Windows command prompt, I was indeed referring to the latter mode where you can paste with the right mouse button. I always set the QuickEdit mode as default on my own computers, so I forgot it was in fact not the default setting in a standard Windows installation. Sorry I have no real experiences with Unix systems, so I was completely unaware that pasting by middle mouse button is the standard on such systems as you suggest. But indeed it is very hard to press the middle "button" of my wireless mouse since from its shape it is easy to tell that it was designed to be mostly used for scrolling instead of functioning as another mouse button. You can see an image of my wireless mouse (Logitech M325) from the following link, and you will understand why I said its middle button is like a wheel that is easy to scroll but very hard to press:
http://www.newegg.com/Product/Product.aspx?Item=N82E16826104625
Also, I find that pasting will not work properly if I want to replace some existing text with DBCS characters when the codepage is set to gbk or big-eten for example. It will work if it is not replacing anything though.
Replacing text with DBCS is always going to be trouble, as the new characters combine with the existing ones. For instance, if you have existing box drawing, then this may be interpreted as a lead byte and the lead byte of your pasted DBCS character will be seen as a trailing byte. This is a consequence of how DBCS works and there's no reasonable way to solve it. Unfortunately DBCS, as a way to define Chinese characters, is an ugly hack; which is why Unicode was invented.
I'd say just don't try to replace text but insert instead, or paste into empty space.
It seems that even inserting DBCS characters will not work properly yet, unless it is currently in an empty space. I can understand it is a difficult issue when trying to replace box-drawing chars with DBCS chars (yet I hardly see any real need of doing this, although it might help to look at how TSRs such as TW handle this), but perhaps it will be much easier to solve the problem of replacing simple text like English letters (i.e. A-Z) with DBCS characters?
Well, box drawing was just an example off the top of my head, but the same thing happens with normal ASCII text. If you look at the GBK codepage, you'll find that almost any byte can be a trail byte, including most normal ASCII characters. So as soon as a lead byte is coming in through the keyboard buffer, it combines with what's there to form a fairly random character. This also happens in insert mode, as you pointed out.
Now keep in mind that pasting characters is handled through the keyboard buffer, so there are many differences with printing characters through LOCATE and PRINT, which I think works as expected. The problem seems to be that the cursor doesn't move, in this particular case, after the lead byte has been read and printed to the screen. That behaviour has to do with getting the correct behaviour on DBCS bytes for backspace and delete - the cursor must always be on a lead byte or an SBCS character for this to work as expected; visually it covers the whole two-byte character. There may be a way to implement this differently, but it's not easy as the knock-on effects on deleting and backspacing text must be taken into account.
Bottom line: this may be solved at some point but for now I would suggest pasting only into empty areas, which works fine. Alternatively, you can always edit program files in a text editor and load them, especially now that PC-BASIC can read in UTF-8 encoded files.
OK, I see the problem that is encountered now. Since I met similar issues when I added LFN and DBCS support to Paul Houle's Enhanced DOSKEY (http://paulhoule.com/doskey/) last month, I have some experiences with this. With these additions Enhanced DOSKEY 2.5 can now handle DBCS characters properly in both overwrite and insert mode, while also supporting editing keys such as BackSpace and DELETE to remove a DBCS character consisting of two bytes instead of one (see Change #14 there for more details). The key for this is to check if the entered character in the keyboard buffer is a DBCS leading byte (through Int 21/AX=6300h in assembly language), if yes, move the cursor, and if the next entered character in the keyboard buffer is a DBCS trailing byte (with ASCII code >=40h), accept the two bytes as a DBCS character. If the insertion of the trailing byte failed, remove the leading byte as well and restore the original character. There are many details of course, such as when trying to overwrite a DBCS character when the current character is a SBCS one and the next character is a DBCS one, and in such case DOSKEY 2.5 would delete the SBCS char and then insert the DBCS char, so that the leading byte of the next DBCS character would not be overwritten by the trailing byte of a DBCS character that is entering, but I think PC-BASIC may not necessarily need to handle such cases. While this way of handling may not be 100% perfect, it usually works pretty well during my testings, so you may adopt it too if it works fine.
Just to let you know, I've released 14.10 with all the hard work on CJK and box-drawing included. The issue with pasting into existing text has also been resolved.
Thanks for your help with getting CJK to a good level of functionality!
I've taken the liberty of adding your name to the acknowledgements, I hope I got it right.
Thank you so much for the new release! I am going to try it now!!
There was a little delay because I was working on adding cross-platform mouse copy/paste support (along with Long File Name support) to DOSBox (see http://www.vogons.org/viewtopic.php?f=41&t=41179) in the last a few days. I'd like to say that the idea of mouse copy/paste support in PC-BASIC had motivated me to add similar feature in DOSBox. I will add your name to this DOSBox build's README file (which I am going to make soon) as acknowledgements too. Thanks!