I'm intermittently encountering a frustrating bug in Xcode where the copy CMD+C does fails with the following symptoms:
It clears existing item in the pasteboard
It fails to copy content into pasteboard
Upon pressing CMD+V a sound is playing and nothing gets pasted (no previous or current item)
Both CMD+C or Edit>Copy can fail the same way.
I've seen a number of suggestions to kill the Pasteboard process and restart Xcode, however this does not seem to work (well). The problem persists and is quite annoying and intermittent. I encountered it on multiple devices(Multiple iMacs, Macbook Air 2011, Macbook Air 2018) with multiple versions of OS (High Sierra/ Mojave).
How do I permanently fix/restore Xcode 10 copy/paste functionality?
It might be my superstition at this point, but it appears that if I hold the CMD+C longer than usual by 0.3 seconds or so, it is more likely to actually work. If I press the buttons normally (rapidly), it gets stuck in the broken state with the existing pasteboard item gone(so something did register), but the item I wanted to copy not available.
Turning off the 'Automatically Sync Pasteboard' option in the Edit menu of the Simulator.
Ref: Apple Developer Forums
I've just published a new Mac App and it is working correctly on my MacBook which is running OS X 10.8.2. However, I've been getting emails from people saying they only see a blank grey screen when the app launches. All these users are running OS X 10.7.5.
Is there a known issue that would cause something like this. I can't really go into specifics as I don't have a clue what could be causing this to happen or where the problem is.
Thanks
How can you simulate a retina display (HiDPI mode) in Mac OS X 10.8 Mountain Lion on a non-retina display?
Search for, download, and install Apple's free Additional Tools for Xcode 8 (for previous Xcode releases search for Graphics Tools for Xcode according to your version).
Note: free Apple Developer account required.
Launch Quartz Debug application.
Go to menu: Window ---> UI Resolution.
Check Enable HiDPI display modes.
Quit Quartz Debug.
Open System Preferences.
Select Displays icon.
If using multiple display, select the configuration window on the display you wish to simulate HiDPI mode on.
Under Resolution:, select Scaled radio button.
Find a desired resolution postfixed with (HiDPI) and select it.
Your display is now running in HiDPI mode, simulating a retina display.
Source: High Resolution Guidelines for OS X
I found the following instructions. It seems to work, and it is much easier than the Quartz Debug approach.
"Enable HiDPI mode in Mountain Lion w/o Quartz Debug"
https://gist.github.com/3191869
In brief, run the following commands, log out, log on, and the HiDPI resolutions are available in the display preferences:
sudo defaults write /Library/Preferences/com.apple.windowserver DisplayResolutionEnabled -bool YES
sudo defaults delete /Library/Preferences/com.apple.windowserver DisplayResolutionDisabled
(In my case the first command was enough; the second command just prints an error message.)
Edit: (5/31/2016)
For users trying to do this on El Capitan, please read the FAQ on SwitchRes's website. Also, if something's still not working after you did all the steps in the FAQ, consider uninstalling and reinstalling SwitchResX. That solved the issue I was having on one of my laptops.
Original:
After reading through several forums, websites, blogs.
I am here to present a solution for users with 15" MacBook Pro with Retina display connected to a Thunderbolt Display.
First of all,
Terminal command of modifying plist
Quartz Debug
Holding option and select "Scaled" in System Preferences
ResolutionTab (Mac App Store)
These methods DO NOT work for MBPr with Thunderbolt Display, for whatever reasons.
You will not see the HiDPI options to be selected.
The only tool I found that actually gives us the options is SwitchResX.
However another problem exists here.
Most users with this setup, I believe, are trying to use 1280x720 HiDPI because it's half the native resolution of the TBD.
According SwitchResX's FAQ, in some cases it is not possible to set to this resolution because of a bug within OS X itself.
Here's a screenshot for your reference:
After contacting the developer, he presented a workaround - adding one more pixel - which worked for me.
Install SwitchResX and open it from System Preferences.
Go to Thunderbolt Display tab, and add a Custom Resolutions with Scaled Resolution at 2562 x 1440
Here's a screenshot
Save using command + s. (or simply close the window and use the prompt up)
Restart the laptop.
Go to SwitchResX and select the new custom resolution in the Current Resolution tab. (Sometimes it doesn't show up right away, play around with it and it should.)
Here you go.
I hope this answer gets to users with this setup because it is really frustrating to use 16:10 resolution on a 16:9 display.
For those unable to enable HIDPI on rMBP or new MBA, I experienced the same on my rMBP 15" with Air Display. I solved the problem by installing SwitchResX. With the boolean setting enabled as shown in the referenced gist, the HIDPI setting shows up.
Dragging seems a little laggy in Air Display, but otherwise works great.
Try this
sudo defaults write /Library/Preferences/com.apple.windowserver DisplayResolutionEnabled -bool YES
[from here]
If your monitor supports it, it may also be worth setting the DisplayPort version to 1.1 instead of 1.2.
I have a late 2010 Mac Air with a Samsung S27D850 display and had all sorts of intermittent resolution switching issues until I made that change.
As for me its pretty good app that give you opportunity for changing resolution any that you want.
SwitchResX for Mac and MacBook.
This app resolved all my problems with resolution.
Perhaps I'm going crazy here, but I have a desktop mac application which, in one of its windows, has an NSImageView placed in a specific spot (using Interface Builder).
When I run the app on a Mac Mini it appears in the right spot. But when I run it on a Macbook Pro the image view is offset quite noticeably.
I've tried on both Lion and Snow Leopard on two different macbook pros and two different mac minis. The OS version doesn't seem to be a factor. It seems the only difference is that one machine is a laptop and the other is a desktop, but I have no idea why this would affect the positioning of elements.
Is there any reason an app's UI elements would not appear in the right spot when running on a laptop vs desktop?
Or perhaps there's another reason this is happening?
If your display is smaller on the Mac Mini and the window is larger than the display then it could be automatically resized. If that is the case then you should look at the view's autoresize mask to make sure they are correct.
I have created Perl/Tk application for OS X compiled using ActiveState PDK PerlApp 8.2.1. The application requires X11 to work properly on OS X, and everything works fine on my own computer (OS X 10.4.11) and others report it working well on OS X 10.5 and 10.6.
But, I have also received several reports from users, for example on 10.4.11 and 10.6.7, that after starting the application, the program seems to run but no main window appears.I have created Perl/Tk application for OS X compiled using ActiveState PDK PerlApp 8.2.1. The application requires X11 to work properly on OS X, and everything works fine on my own computer (OS X 10.4.11) and others report it working well on OS X 10.5 and 10.6.
But, I have also received several reports from users, for example on 10.4.11 and 10.6.7, that after starting the application, the program seems to run but no main window appears.
(Just to clarify the meaning of "seems to run", users can launch X11 (so it's installed!). Also, after launching my application, a new X11 menu bar appears and they can click "About..." and can see the "About..." window for my application.)
I cannot replicate the bug here and the users say that no errors appear on the Terminal command line when they launch the application.
Has anybody experienced a similar problem and know a way to fix it? It seems to be an issue with X11, but I am happy to change my own code to avoid this issue.
I guess the first thing to check is that they are launching from the X11 terminal, rather than the normal one. (and that they have X11 installed).
PerlTK might be hiding the errors in that case?