View Issue Details

IDProjectCategoryView StatusLast Update
0001855Ham Radio DeluxeBugpublic2017-09-18 00:08
Reporteruser47 
Assigned ToK7ZCZ 
PrioritylowSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.4.0.787 
Summary0001855: Neither of Ctrl-V or Shift-Ins work for callsign field in logbook filter window.
DescriptionNeither of Ctrl-V or Shift-Ins work for callsign field in logbook filter window.
Right-click and then 'Paste' option works.
Steps To ReproduceClLick on the Filter button
try to paste in a callsign to the callsign text box using keyboard shortcuts.

Only Right click>paste seem to work.
TagsNo tags attached.
ModuleLogbook
Sub-ModuleFunctional
TestingNot Started

Relationships

Activities

WA9PIE

2017-03-05 18:22

administrator   ~0003100

I reproduced it tonight. Not only does Ctrl-V not work, it also can cause a crash if someone tries it.

K7ZCZ

2017-09-04 20:15

manager   ~0004107

The problem is that CTRL+V and Shift+INS end up being routed to the frame window, not the edit control. On the frame, they cause the application to (try to) paste a row into the logbook directly.

There's a lot of undesired behaviour here:

1) command routing isn't working correctly. It'll be hard to fix because there are lots of windows involved, in two or three layers. Focus won't be easy to track down or correctly fix.

2) Even when we intend to paste into the logbook, the code will add the new row and then completely drain memory of all records, then re-load the database. This takes an unacceptably long time.

3) Same problem with cut commands (like CTRL+X)

I think the issue may be compounded by the design of the window layout, which hides and shows the filter bar rather than creating and destroying it.

If you're able to create a crash, please provide a minidump.

K7ZCZ

2017-09-04 21:41

manager   ~0004108

Looks like this is caused by the main frame window having an accelerator that includes CTRL+V, CTRL+INS, CTRL+X, and so on. PreTranslateMessage ends up interpreting the accelerator and routing the the command to the main frame, always.

I'll have to figure out if the easiest fix is to ditch the entries in the accelerator table; doing so will let the edit control handle its own focused keystrokes. But then we'll need a hook to handle the keystrokes for the desired row-by-row copy pasta.

K7ZCZ

2017-09-07 16:46

manager   ~0004132

Fixed with this change set
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/3835

g3ucq

2017-09-08 03:13

viewer   ~0004137

Fixed

WA9PIE

2017-09-18 00:08

administrator   ~0004229

Closed as part of the 6.4.0.787 release.

Issue History

Date Modified Username Field Change
2016-01-11 03:16 user47 New Issue
2017-03-05 18:22 WA9PIE Note Added: 0003100
2017-08-16 16:50 WA9PIE View Status private => public
2017-09-04 20:15 K7ZCZ Note Added: 0004107
2017-09-04 21:41 K7ZCZ Note Added: 0004108
2017-09-04 21:41 K7ZCZ Project 2 - Next Dev List (Holding Area) => 3 - Current Dev List
2017-09-04 22:06 K7ZCZ Assigned To => K7ZCZ
2017-09-04 22:06 K7ZCZ Status new => assigned
2017-09-07 16:46 K7ZCZ Status assigned => resolved
2017-09-07 16:46 K7ZCZ Resolution open => fixed
2017-09-07 16:46 K7ZCZ Testing => Not Started
2017-09-07 16:46 K7ZCZ Note Added: 0004132
2017-09-07 18:18 K7ZCZ Fixed in Version => 6.4.0.784
2017-09-08 03:13 g3ucq Note Added: 0004137
2017-09-11 21:32 K7ZCZ Fixed in Version 6.4.0.784 => 6.4.0.785
2017-09-14 19:23 K7ZCZ Fixed in Version 6.4.0.785 => 6.4.0.787
2017-09-18 00:06 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2017-09-18 00:08 WA9PIE Note Added: 0004229
2017-09-18 00:08 WA9PIE Status resolved => closed