Jamal Mazrui wrote:
I just joined this list, but have searched the archive before posting. I know that keystroke processing issues with a multiline textfield have been discussed repeatedly. Evidently, the fix for the Enter key creating a new line is straight forward: add the ES_WANTRETURN style when creating the textfield.
Indeed. That works as expected. In the next version we'll have a -wantreturn option for Texfield/RichEdit to apply this style.
I'm unclear, however, what the simplest fix is for the Tab and Shift+Tab keys moving to the next or previous control when the textfield has focus.
There's no simple workaround that I know of. I've added code in the message loop for Textfield/RichEdit that will appear in the next release to fix the TAB/SHIFT-TAB behaviour.
I found code that used a hook method. It seemed to address Tab but not Shift+Tab. Also, I'm hoping that a simpler solution may have been developed, e.g., using a char or keydown event, or defining Tab and Shift+Tab as accelerator keys. I've struggled with these latter techniques without success, so perhaps they are not feasible--just want to be sure though before giving up on them. Another issue I found is that the Escape key closes a dialog but it is not trapped by a Cancel_Click event, which the documentation says it should be. Also, when I run a program with perl.exe from the command line, Escape cancels the dialog but leaves a Perl window open. On the other hand, if I use wperl.exe instead, this does not happen--though I'm not sure whether the Perl interpreter is still in memory but hidden. How can I let Escape cancel a dialog but also trap the event so other clean-up code can be run?
All of these issues are down to Win32::GUI 'faking' dialog behaviour by using IsDialogMessage() in it's message loop. For various reasons of (windows) backwards compatibility (with Win3.11 from what I've read) the interaction of this call with multi-line Textfield/RichEdit controls is not what might reasonably be expected.
ESC closing the dialog is a known bug (https://sourceforge.net/tracker/index.php?func=detail&aid=1398896&group_id=16572&atid=116572). As can be seen from the report I know what the solution is, but have yet to work out a clean way to apply it to the codebase. And yes, if you look in your task manager I suspect you'll find the wperl process still running. Nasty :-)
The archives mention a Win32::GUI version that fixes at least some of these problems. Is there a binary test version available? I don't have or know how to use a C compiler at present.
Very soon. I don't like to commit to dates, but soon. Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/
