Keyboard Shortcuts Don't Work

[Trent_Schwartz]

I'm hoping I can explain this clear enough, I know I'm missing something, but I'm completely stumped.

Here is the symptom:

• When working in structured view, selecting an element and then using the keyboard shortcut for copy (Ctrl+C) does not work. I get a beep. While the right click menu - Copy does work. Same applies to the keyboard shortcuts for cut, copy, paste, and even the delete key.
• If I click on the desktop, then back to the structure window on an element, it will work one time. For example I can copy the element. Then I have to click on the desktop and back in the structure window where I want to insert the element.
• Another odd behavior is that when this occurs, pressing a single key on the keyboard has the same result as using the Alt+key, but there is no underscore in the menu letters. For example, pressing V drops down the view menu as if I pressed Alt+V. The underlined letters in the menu for the shortcuts do appear when I press the Alt key.
• UPDATE: When the Structure View panel is docked, keyboard shortcuts work. When the Structure View panel is undocked or iconified and expanded, the keyboard shortcuts do not work with the script enabled.

The ExtendScript automates inserting multiple "Model" elements with a specific alpha-numeric value in the "ModelNumber" attribute. There can be anywhere from 1 to 100 or more unique models inserted. The document is a parts manual. Each manual has a list of models it covers, each assembly can include all or any combination of models, and each part in that assembly can contain all or any combination of models applied to the assembly.

When the user inserts, pastes, or double-clicks on a specific container element, a window opens with a list of all the available model numbers that can apply. The user checks off those model numbers to include and then clicks a button to insert a "Model" element with the "ModelNumber" attribute value set for each model the user checked off.

The ExtendScript monitors FA_Note_PreMouseCommand, FA_Note_PostMouseCommand, FA_Note_PostInsertElement to determine the location in the structure and document, and the type of mouse action to determine whether it should load the model numbers to check-boxes and open the window.

A menu is created when the script runs with some commands to refresh the list model numbers, looks for invalid model numbers and generates a report, and enables/disables the notify so the window doesn’t open and doesn’t actively read/load the list of model numbers. The enable/disable command utilizes the check-mark to indicate whether it's enabled or disabled.

When the script is disabled, keyboard shortcuts work fine.

What would cause the keyboard shortcuts to not work, yet mimic the Alt key being pressed? The window, the menu, the notify functions?

Why would the Structure View panel being docked or undocked have any impact on the keyboard shortcuts? Or how would that conflict with the model window?

Any help or direction will be greatly appreciated.

Trent Schwartz

[Russ Ward]

Trent, this is a whole lot of information, but I'm not able to follow it completely. Is this a script that you wrote? And, definitely the script is causing the problem, because without the script running everything is OK? When you start messing with mouse and keyboard notifications, it is definitely possible to cause some unusual behavior. It might be necessary to analyze your code in order to provide any ideas.

Russ

[Trent_Schwartz]

Thanks Russ. I understand, I’m not even sure how to explain it.

This is by far the most complex and complicated script I ever programmed in order to accomplish one task. I originally created the plugin with the FDK back in 2004 and then recreated it with ExtendScript 3 years ago. I never saw the problem when I was developing it because I never undocked my structure view panel.

Trent

[Trent_Schwartz]

I suspect that the cause is in one of 3 areas - the notifications, the menu, or the window that's created. I don't understand how the structure view panel being docked or undocked would have anything thing to do with this, but I'll ignore that for now.

The notifications PostOpenDoc, PostActiveDocChange, and BackToUser are enabled from the start.

PostOpenDoc – If structured document and correct StructuredApplication, then enable Pre & PostMouseCommand, PostInsertElement, PostChangeElement, and PostSetAttrValue notifications. Also loads the documents main list of model numbers into a model list array, prepares the window, and sets various doc object properties.

PostActiveDocChange – For when the user has more than one document open and switches between them, does the same as PostOpenDoc does. Prevents the notifications when document is not structured or different structured application.

BackToUser – Turns on or off the Pre & PostMouseCommand, PostInsertElement, PostChangeElement, and PostSetAttrValue notifications based on whether the current position/selection is in the main flow of structure tree or not.

PreMouseCommand – Determines whether mouse action was a left click, right click, or double click; and whether mouse action was on element or insertion point. If mouse action was a double click, determines whether the current element is a container for model elements to open the window.

PostMouseCommand – If mouse action was a single left click, determines what element is selected. If the mouse action was a double click on a model container element, show window.

PostInsertElement – If element inserted is a container for model elements, show window. If the element inserted is in the documents main model list, the models are reloaded into the model list array.

PostChangeElement – If the element changed is in the documents main model list, the models are reloaded into the model list array.

PostSetAttrValue – If the user changed the model number in the attribute value for one of the model elements in the documents main model list, the models are reloaded into the model list array.

Each event is occuring at the correct time and correct order.

The enable/disable menu command enables/disables the Pre & PostMouseCommand, PostInsertElement, PostChangeElement, and PostSetAttrValue notifications; and is used in some conditional statments in PostOpenDoc, PostActiveDocChange, and BackToUser.

The window is created, but not shown until it's needed. Could that have something to do with it?

Trent

[Trent_Schwartz]

So if I add the following in the BackToUser notification, keyboard shortcuts work:

     GVdoc.IsInFront = true; //GVdoc = app.ActiveDoc object reference for the current document

Take the line out, keyboard shortcuts stop working as described in the initial post. I'm not sure if it's a fix for the problem or covering it up.

Anyone have any thoughts?

Trent

[Russ Ward · Accepted solution]

[edited, accidentally hit Ctrl+S again before I was finished. I hate that shortcut!]

Trent,

Sorry for the delay on this. I needed a minute to review all the information.

Although I can't possibly know anything for sure without a deeper analysis, I suspect that you have fixed the problem. And, I do think that the Structure View being docked vs. undocked is significant. In the object model, the Structure View is represented as an open document object. In other words, if you iterate through all open documents with your code, you'll eventually get to the Structure View. It has an empty Name property but the Label property is "Structure View". Anyway, you can't make it the app.ActiveDoc, but you can capture it as a document object. If you've been working with FM for a long time, you might know this already, or at least recognize how this quirk makes some sense when you think about the old Structure View, back in the day.

Anyway, my guess is that somehow you might be getting the focus locked on the Structure View, rather than the original doc, with all the fancy operations you are doing. Then, your shortcuts stop working right, because the Structure View isn't really a document per se. When you toggle the entire application focus to the Windows desktop and back, FM correctly restores focus to the active doc, but just one time before your code messes it up again. With your new GVdoc.IsInFront = true; line, you effectively restore the proper focus and all is well again.

Added to all that, maybe somehow the Structure View pod just works differently with regard to focus when docked vs. undocked. Maybe there is some holdover, backdoor way to accidentally (programmatically) give the Structure View focus when it is undocked. I don't know.

Anyway, these are all just my suspicions, mostly speculation based on experience. I hope it helps.

Russ

[Trent_Schwartz]

Thanks Russ, your answer did led me to the real cause. My solution of forcing the active doc resulted in other issues. I didn't have a chance to follow up because I was put on other hot projects right away.

Anyway, the problem was caused by the the dialog window I was creating. The window would be created, populated, and sized based on the ActiveDoc, but not shown. The objects in the window would be modified based on user navigation in the document and the window would be shown only when it was required. The window was always left with the focus every time the user would click in the document, even if the window wasn't shown. By eliminating the pre-loading and creation of the window, it's working fine. Since everything is put into arrays and collections before it's applied to the window (including size and position of the objects), the hard work is already done, so the window is now created and populated each time it's shown. There wasn't any noticeable difference in speed by not creating, sizing, and populating the window ahead of time. If this makes any sense...

For the last 8 years or so I only get to dabble in code for maybe a couple days here and there once every 4-6 months, the rest of the time is completely unrelated to any programming. Even when I am working with some code, it's constant interruptions and side tracks with non-programming stuff.

Trent Schwartz