Creo 11 top row number characters (e.g. @) stop working for mapkeys after a new part is created

[CA_10146793]

I am using Creo Parametric Release 11.0 and Datecode11.0.1.0

In Creo 11, after creating a new part (e.g. ctrl-n), the keyboard does not type an "@" character (shift+2) into the lower menu space (where the message log is shown), for example to trigger a mapkey name that contains "@". All shift characters have the same problem after a new part is created. I have confirmed that I can type the @ character into the menu space before creating the new part. The characters can still be typed into the "search" field so it is not a hardware issue. I have also confirmed that Creo 10 does not exhibit this problem.

[MartinHanak]

Hi,

please report described behavior to PTC Support.

[Chris3]

I have confirmed the behavior in Creo 11.0.0 and also confirmed this does not happen in Creo 9.  I agree with @MartinHanak - you should open up a ticket with PTC so they can file a bug report (SPR).

[CA_10146793]

Thank you both, case opened.  I first posted on the forum as per initial action suggested by PTC support "bot".  Additionally:

• Confirmed while on support call with PTC that shift+1, shift+2, and shift+3 keyboard inputs are being ignored in Creo 11 while a part is in session but are received in Creo 10.  Any subsequent keyboard input of "allowed" characters (after the ignored characters are attempted) are received.
• Also I should mention for clarity that I have previously confirmed that the mapkeys with "@" may still be successfully triggered by mouse/menu action in both Creo 10 and Creo 11
• They are working on it

[Mahesh_Sharma]

Hello @CA_10146793 

Just for information, this issue is with R&D now. 

Thanks. 

[CA_10146793]

Thank you Mahesh. 

FYI all:

The cause appears to be that new keyboard shortcuts for shift 1-3 were released in Creo 11.  I did not initially detect the conflict - new keyboards shortcuts; they can be easily seen by "Show/Commands with assigned shortcuts" in Options.  However Creo did not alert me to any conflicts, which was the behavior in Creo 10 where the user was given the option to automatically resolve detected conflicts.  Resetting the keyboard shortcuts to default did reveal conflicts and prompt to resolve.

I am also checking into the reason for why $F2 mapkey can no longer be triggered by the keyboard in sketch mode (have not yet identified keyboard conflict).

[Mahesh_Sharma · Accepted solution]

Hi @CA_10146793 

Thanks for the update. I agree missing Conflict dialog can lead the confusion as in your case. 

About $F2, default assignment of F2 is to Rename, but that can clear from Windows Shortcut. Created a sample mapkey with keystroke F2 and that worked well for me with keyboard input. If possible share the F2 mapkey to review. 

Thanks 

[CA_10146793]

hi @Mahesh_Sharma ,

Thank you for the feedback.  I agree that $F2 in general works for in most mapkey cases, but for some reason it does not work in my unique mapkey case which is only applicable while in a specific menu state or "mode".  I've attached the mapkeys in question.  There are two that are triggered in sequence; OE and $F2.  $F3 is an exact copy of $F2.  Here is an example below to reproduce the issue - the goal is to be able to create a quick offset sketch by complete loop, using mapkeys sequentially to reduce mouse clicks:

1. First, create a sketch feature containing a simple square, and close the completed feature.
2. Create a second sketch feature ("use previous" plane, etc.) and enter the empty sketch.
3. Once inside the sketch, before selecting any entity, press OE to trigger first mapkey to enter "offset" command that brings up the first entity selector dialogue box.
4. Before selecting any entity, press $F2 to trigger the second mapkey that is supposed to bring up the secondary "Complete Loop" dialogue box.  Nothing appears to happen.
5. Repeat step above with $F3 instead, and the mapkey will function as expected, bringing up the secondary dialogue box and allowing the user to pick a single entity to automatically select the loop.

• NOTE: The support team has spent some time investigating and their opinion is that the behavior seems normal and is the same in V10 and V11.  However, that doesn't explain why $F3 does work for me, and I have verified that $F2 DOES work as expected in V10. 

Rather than pursue this further, my workaround is to simply use $F3 and avoid $F2 for this particular mapkey.  I do not know the root cause...it seems like another keyboard shortcut conflict but I can't find any.  It would be good to be able to use $F2 but perhaps my workflow on this offset command is somewhat specialized, so I am OK with closing the case.