-
Notifications
You must be signed in to change notification settings - Fork 137
This usually happens after CoRD is updated.
Try this:
- Delete any saved passwords tied to CoRD (specifically the problem sessions) in Keychain Access.
- Delete your
~/Library/Preferences/net.sf.CoRD.plist
file. - Delete and re-create the server.
As always, sanity check things. Just because it worked yesterday doesn't mean everything is the same today. Start with the fundamentals and go from there:
- Is the box powered on?
- Is it properly connected to the network?
- Can I ping it?
- Has the firewall been turned on or reconfigured?
- Can I connect from a different machine (with CoRD or another client)?
- Can I connect to a different machine successfully using CoRD?
- Can I connect from my machine using Microsoft's client?
...the Start Menu has been activated
...the Command Key is "stuck"
...the Control Key is "stuck"
...the Option Key is "stuck"
...the Shift Key is "stuck"
This is a side effect of how OS X handles keyboard input, how CoRD interprets it, and how Windows processes what we send it.
Each time you hit a key on the keyboard, there's a command sent for when the key is pressed down, another for when the key is released. This lets things like repeating characters and key-state conditional things (holding shift for the duration of an operation, etc) work.
Example: When you Cmd-Tab from CoRD to another application, as far as we can tell from our investigations, CoRD receives the key DOWN event for Command and the Tab key, and sends them to Windows accordingly (since we try to stay pretty blind to what is actually being sent to avoid other conflicts). BUT at that point the task switcher receives focus, and CoRD never receives a key UP event. How that results in the start menu popping up doesn't make sense to us either, but doing a line-by-line and blow-by-blow debugging of what is going on that's the rudimentary version of what we were able to ascertain. One would think it would require a complete key press to get the start menu to pop up, but that doesn't seem to be the case.
Regardless, whenever CoRD regains focus, that key is still "down" since no "up" event has been received. It usually takes tapping the offending key once (sometimes more than once, another mystery) to send another key down AND key up, in order to get things back in sync.
This affects all modifier keys, Shift, Control, Option, and Command.
If your server drawer ends up on the “wrong" side, there’s a simple solution: Hide your server drawer (Cmd-Shift-D, or menubar View->Hide Server Drawer), move CoRD close to the edge of the screen, then show the server drawer (Cmd-Shift-D, or menubar View->Show Server Drawer).
In the background, some screen math is taking place so that we[2] ensure the drawer is always visible when it opens, i.e. it will never open off screen if we can help it.
If you had closed CoRD when the server drawer was partially off the screen, when you reopen the math will fail, and we’ll open on the other side. This check happens whenever you show or hide the drawer, so it could potentially happen during normal use.
If you need to back up your Saved Servers, to take to another machine, etc., you can find them in:
~/Library/Application Support/CoRD/Servers/
They will be saved individually as .RDP files, and are interoperable with Microsoft's Remote Desktop Client, on both Macs and PCs.
Alternatively if you want a faster way to get there, you can right click (control click) on any server in your list, and click "Show in Finder," or use the options under the Servers menu item.
If you ever need to remove CoRD for any reason the process is pretty simple.
- Delete (or Trash) the Application:
/Applications/CoRD.app
(or~/Applications/CoRD.app
, or wherever you place CoRD.app) - Remove Preferences file:
~/Library/Preferences/net.sf.cord.plist
- Remove Saved Servers:
~/Library/Application Support/CoRD/
- Remove Log File[1]:
~/Library/Logs/CoRD.log
[1] This Log File may not exist.
[2] By “we”, we mean Apple, not us. They are doing the drawer math...