customizing keyboard shortcuts

One way is to use application code that is executed at startup by way of #earlySystemInstallation events.

update: aSymbol with: arguments from: anObject

                "Things to do when image status is changing"

                anObject == ObjectMemory

                ifTrue:[

                                "At image startup"

                                (aSymbol == #earlySystemInstallation)  ifTrue:[self initializeKeyBoard]. 

                ...

initializeKeyBoard

                InputState interruptKeyValue: -2.            "Ctrl-b"

                ParagraphEditor initialize.

                DispatchTable allInstances do:  [:ea |

                                ea bindValue: #deleteKey: to: Character del.

                                ea bindValue: #acceptKey: to: (Character value: 1).         "Ctrl-a"

                                ea bindValue: #printItKey: to: (Character value: 16).        "Ctrl-p"

                                ea bindValue: #formatKey: to: (Character value: 17).      "Ctrl-q"

                                ea bindValue: #pasteKey: to: (Character value: 22).         "Ctrl-v"

                                ea bindValue: #cutKey: to: (Character value: 24).              "Ctrl-x"

                                ea bindValue: #copyKey: to: (Character value: 3).             "Ctrl-c"

                ].

                TextAttributes initialize.

                VariableSizeTextAttributes initialize.

                InputBoxController initialize.

                InputState doubleClickTimeout: 400

You can use #bindValue:to:modifiers: to specify actions using modifier keys, or application code can check the modifier keys:

                (InputState default ctrlDown and: [InputState default shiftDown])

                                ifTrue: [...]

Paul Baumann

It is legacy code.  I guess we are just fortunate there have been no bugs in it. I'm glad there are better ways.

Why would you do that during earlySystemInstallation? It seems like the biggest effect of that would be that if there was a bug in your code the entire image would be unstartable rather than bringing up a debugger.

I just looked into that code a little more. The code I showed was cut down from the original, and I cut out an important part without looking at it. The code actually used sends #atStartup from the system event, and the #atStartup method does the initialization. The important thing I cut out was that #atStartup has a fork to avoid the P100 process set by #preSnapshot. That is how the code avoids the problems that Alan mentioned. Good catch Alan. I'd forgotten about the workaround to avoid the P100 startup. That workaround is as recent as 2006 so that the application process we launch isn't also at P100.

atStartup

                "On image startup restart the ORB, and a server"

                [

                | win |

                Processor yield. "Yield to other image startup activities"

                win := Window popUpAtActiveWindowWith: ' Initializing...  Please wait. ' asComposedText.

                ...

                self initializeKeyBoard.

                ...

                win close.

                ]

                                forkAt: Processor userSchedulingPriority.             "Avoid P100 activePriority set by #preSnapshot"

Why do it at startup? I suspect it is just so the key definitions are effective early in a runtime image start.

It is legacy code.  I guess we are just fortunate there have been no bugs in it. I'm glad there are better ways.

Why would you do that during earlySystemInstallation? It seems like the biggest effect of that would be that if there was a bug in your code the entire image would be unstartable rather than bringing up a debugger.

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.