Re: [wsjt-devel] WSJT-X Hotkeys Alt1-6 broken functionality
On 23/09/2014 22:55, Laurie VK3AMA wrote: Hi Laurie, Tested with 1.3 and latest 1.4 rc1 The Hotkeys Alt 1-6 fail whenever the cursor is in an edit field of the WSJT-X window. Any edit field, not just the TX1-6 fields. The "Alt" gets consumed and the number (1 to 6) gets input into that field. Alt 1-6 work correctly if the cursor is not in an edit field. Other Alt Hotkeys are not affected by this behaviour and correctly perform their functions regardless of where the cursor is positioned. That may be standard Windows behaviour, in an input field the Alt+number sequences are usually reserved for entering characters that are not on the users keyboard. I'll have a look and see if there is a way of disabling that for WSJT-X. de Laurie, VK3AMA 73 Bill G4WJS. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X Hotkeys Alt1-6 broken functionality
Hi Bill, I don't think this is Standard Windows behaviour. I just tested about a dozen different Windows Apps, a mix of Microsoft and other developers. None of them reacted to an Alt number sequence when the cursor is in an edit field. Since these are hotkeys, I would have thought that the Hotkey code would just consume the hotkey combination and not pass it on to the edit field. That is what I do with any Hotkeys I define for apps I write. If this can't be corrected, I will code a workaround (this is for JTMacros) and just perform a mouse-click on the WSJT-X Band Activity or RX Frequency lists which removes the Cursor from the edit field and then issue the Alt number hotkey. That works but is a bit of a hack. de Laurie, VK3AMA On 24/09/2014 7:59 AM, Bill Somerville wrote: On 23/09/2014 22:55, Laurie VK3AMA wrote: Hi Laurie, Tested with 1.3 and latest 1.4 rc1 The Hotkeys Alt 1-6 fail whenever the cursor is in an edit field of the WSJT-X window. Any edit field, not just the TX1-6 fields. The "Alt" gets consumed and the number (1 to 6) gets input into that field. Alt 1-6 work correctly if the cursor is not in an edit field. Other Alt Hotkeys are not affected by this behaviour and correctly perform their functions regardless of where the cursor is positioned. That may be standard Windows behaviour, in an input field the Alt+number sequences are usually reserved for entering characters that are not on the users keyboard. I'll have a look and see if there is a way of disabling that for WSJT-X. de Laurie, VK3AMA 73 Bill G4WJS. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X Hotkeys Alt1-6 broken functionality
On 23/09/2014 23:24, Laurie VK3AMA wrote: Hi Bill, Hi Laurie, I don't think this is Standard Windows behaviour. I just tested about a dozen different Windows Apps, a mix of Microsoft and other developers. None of them reacted to an Alt number sequence when the cursor is in an edit field. Maybe they don't react until three or more numbers have been entered. Possibly Qt is less forgiving. Since these are hotkeys, I would have thought that the Hotkey code would just consume the hotkey combination and not pass it on to the edit field. That is what I do with any Hotkeys I define for apps I write. It's not like that. They are not hot keys as such, we just filter key press events on the MainWindow widget and look for Alt+1 etc.. The problem is that if the widget with focus or any of its parents handle the key press event it never bubbles up to the MainWindow widget itself. If this can't be corrected, I will code a workaround (this is for JTMacros) and just perform a mouse-click on the WSJT-X Band Activity or RX Frequency lists which removes the Cursor from the edit field and then issue the Alt number hotkey. That works but is a bit of a hack. OK, I am still wading through the Qt code trying to find where the event is being consumed. de Laurie, VK3AMA 73 Bill G4WJS. On 24/09/2014 7:59 AM, Bill Somerville wrote: On 23/09/2014 22:55, Laurie VK3AMA wrote: Hi Laurie, Tested with 1.3 and latest 1.4 rc1 The Hotkeys Alt 1-6 fail whenever the cursor is in an edit field of the WSJT-X window. Any edit field, not just the TX1-6 fields. The "Alt" gets consumed and the number (1 to 6) gets input into that field. Alt 1-6 work correctly if the cursor is not in an edit field. Other Alt Hotkeys are not affected by this behaviour and correctly perform their functions regardless of where the cursor is positioned. That may be standard Windows behaviour, in an input field the Alt+number sequences are usually reserved for entering characters that are not on the users keyboard. I'll have a look and see if there is a way of disabling that for WSJT-X. de Laurie, VK3AMA 73 Bill G4WJS. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X Hotkeys Alt1-6 broken functionality
Bill, Something weird with those hotkeys. Using Alt and the numeric-pad numbers works correctly, it is only when the numbers 1 to 6 across the top of the keyboard that the problem occurs. For my purposes using the numeric pad numbers is trivial and I have already coded the JTMacros change. Thanks de Laurie, VK3AMA On 24/09/2014 8:30 AM, Bill Somerville wrote: On 23/09/2014 23:24, Laurie VK3AMA wrote: Hi Bill, Hi Laurie, I don't think this is Standard Windows behaviour. I just tested about a dozen different Windows Apps, a mix of Microsoft and other developers. None of them reacted to an Alt number sequence when the cursor is in an edit field. Maybe they don't react until three or more numbers have been entered. Possibly Qt is less forgiving. Since these are hotkeys, I would have thought that the Hotkey code would just consume the hotkey combination and not pass it on to the edit field. That is what I do with any Hotkeys I define for apps I write. It's not like that. They are not hot keys as such, we just filter key press events on the MainWindow widget and look for Alt+1 etc.. The problem is that if the widget with focus or any of its parents handle the key press event it never bubbles up to the MainWindow widget itself. If this can't be corrected, I will code a workaround (this is for JTMacros) and just perform a mouse-click on the WSJT-X Band Activity or RX Frequency lists which removes the Cursor from the edit field and then issue the Alt number hotkey. That works but is a bit of a hack. OK, I am still wading through the Qt code trying to find where the event is being consumed. de Laurie, VK3AMA 73 Bill G4WJS. On 24/09/2014 7:59 AM, Bill Somerville wrote: On 23/09/2014 22:55, Laurie VK3AMA wrote: Hi Laurie, Tested with 1.3 and latest 1.4 rc1 The Hotkeys Alt 1-6 fail whenever the cursor is in an edit field of the WSJT-X window. Any edit field, not just the TX1-6 fields. The "Alt" gets consumed and the number (1 to 6) gets input into that field. Alt 1-6 work correctly if the cursor is not in an edit field. Other Alt Hotkeys are not affected by this behaviour and correctly perform their functions regardless of where the cursor is positioned. That may be standard Windows behaviour, in an input field the Alt+number sequences are usually reserved for entering characters that are not on the users keyboard. I'll have a look and see if there is a way of disabling that for WSJT-X. de Laurie, VK3AMA 73 Bill G4WJS. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X Hotkeys Alt1-6 broken functionality
On 23/09/2014 23:43, Laurie VK3AMA wrote: Bill, Hi Laurie, Something weird with those hotkeys. Using Alt and the numeric-pad numbers works correctly, it is only when the numbers 1 to 6 across the top of the keyboard that the problem occurs. OK, that makes some sense as it seems to consume all modifiers on the main keyboard and do something with them. I can see a fix but it is very messy as I'd have to subclass all the input controls and grab their keyPressEvent and explicitly ignore the Alt+n keys. For my purposes using the numeric pad numbers is trivial and I have already coded the JTMacros change. OK I'll forget about this then as that seems solid and simple ;) Thanks de Laurie, VK3AMA 73 Bill G4WJS. On 24/09/2014 8:30 AM, Bill Somerville wrote: On 23/09/2014 23:24, Laurie VK3AMA wrote: Hi Bill, Hi Laurie, I don't think this is Standard Windows behaviour. I just tested about a dozen different Windows Apps, a mix of Microsoft and other developers. None of them reacted to an Alt number sequence when the cursor is in an edit field. Maybe they don't react until three or more numbers have been entered. Possibly Qt is less forgiving. Since these are hotkeys, I would have thought that the Hotkey code would just consume the hotkey combination and not pass it on to the edit field. That is what I do with any Hotkeys I define for apps I write. It's not like that. They are not hot keys as such, we just filter key press events on the MainWindow widget and look for Alt+1 etc.. The problem is that if the widget with focus or any of its parents handle the key press event it never bubbles up to the MainWindow widget itself. If this can't be corrected, I will code a workaround (this is for JTMacros) and just perform a mouse-click on the WSJT-X Band Activity or RX Frequency lists which removes the Cursor from the edit field and then issue the Alt number hotkey. That works but is a bit of a hack. OK, I am still wading through the Qt code trying to find where the event is being consumed. de Laurie, VK3AMA 73 Bill G4WJS. On 24/09/2014 7:59 AM, Bill Somerville wrote: On 23/09/2014 22:55, Laurie VK3AMA wrote: Hi Laurie, Tested with 1.3 and latest 1.4 rc1 The Hotkeys Alt 1-6 fail whenever the cursor is in an edit field of the WSJT-X window. Any edit field, not just the TX1-6 fields. The "Alt" gets consumed and the number (1 to 6) gets input into that field. Alt 1-6 work correctly if the cursor is not in an edit field. Other Alt Hotkeys are not affected by this behaviour and correctly perform their functions regardless of where the cursor is positioned. That may be standard Windows behaviour, in an input field the Alt+number sequences are usually reserved for entering characters that are not on the users keyboard. I'll have a look and see if there is a way of disabling that for WSJT-X. de Laurie, VK3AMA 73 Bill G4WJS. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X Hotkeys Alt1-6 broken functionality
Hi Bill, Contrary to my last post, the Alt numeric number Hotkey alternative works but leaves a garbage character in whatever edit field contained the insertion point prior to issuing the HotKey. I have hacked a workaround so don't spend any time on this. Thanks de Laurie, VK3AMA -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X Hotkeys Alt1-6 broken functionality
On 25/09/2014 03:57, Laurie VK3AMA wrote: Hi Bill, Hi Laurie, Contrary to my last post, the Alt numeric number Hotkey alternative works but leaves a garbage character in whatever edit field contained the insertion point prior to issuing the HotKey. Yes, that's the mechanism for entering non-standard or different locale characters I referred to before, I had forgotten that the sequence is Alt+n where 'n' is a sequence of keypad numbers. I have hacked a workaround so don't spend any time on this. Good because I still don't see an easy solution for undoing this seemingly strange Qt input field processing of characters with modifiers like Alt, Ctrl etc.. Thanks de Laurie, VK3AMA 73 Bill G4WJS. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X Hotkeys Alt1-6 broken functionality
On 25/09/2014 03:57, Laurie VK3AMA wrote: Hi Bill, Hi again Laurie, Contrary to my last post, the Alt numeric number Hotkey alternative works but leaves a garbage character in whatever edit field contained the insertion point prior to issuing the HotKey. I have hacked a workaround so don't spend any time on this. Looking at this has uncovered a few minor defects in the special key handling so I will fix those. Also the odd characters should not be allowed in the message fields anyway, there needs to be a validator on them to limit the characters to those that can be used in JT65/JT9 messages. I have put a validator on them. That should save you needing the hack you have selected. If your fix involved deleting the "garbage" character then you may have a version compatibility issue to deal with since they will no longer be appearing in v1.4. Thanks de Laurie, VK3AMA 73 Bill G4WJS. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
