The Mac App store seems to refuse to let you update existing apps if it can't find those applications in the Spotlight index. This affects any user who has turned off Spotlight completely, or has just turned off the indexing of the Applications folder.
This problem has been much discussed on the Apple Support Communities pages and the following solution has been mentioned by several people there (so credit is due to them rather than me).
If Spotlight indexing of your Applications folder is disabled then the 'Updates' tab of the Mac App Store will not list any updates. However, you will see those updates if you click on the 'Purchases' tab. If you try clicking on 'Update' button from this tab, an error message appears indicating that you are not signed into the correct Apple account.
In my case, I only have one account, so this message seemed to be erroneous. I tried signing out and back into my Apple account, but this didn't help. Note that this problem was not fixed by the 10.7.1 update.
Following advice in this Apple Discussion thread I checked my Spotlight indexing rules and discovered that I had turned off indexing of the Applications folder (see the 'Privacy' tab of the Spotlight preference pane).
Removing the rule on ignoring the Applications folder fixed the problem. I waited until Spotlight could now find all of my applications, and then reopened the Mac App Store and was able to update applications.
[crarko adds: This was suggested in the comments to this earlier Xcode updater hint, and this provides confirmation of that.]
The goal of this hint is to automate the process of re-creating an Equation Editor equation in Microsoft Word.
Note: This hint applies to equations created in Microsoft Word using Equation Editor. It does not apply to the new kind of equations that can be created in Office 2011.
We have many large documents that contain hundreds of equation objects each. When attempting to revise some of these documents in Word 2011, the equation objects appeard to be corrupted. Double clicking on them would open the object in Equation Editor, but changes were not reflected in the document. In addition, the baselines for each equation object did not line up with the surrounding text. The most frustrating part is that we had just invested several tens of thousands of dollars re-typesetting equations.
The only solution I could find was to open each equation object, select all of its contents and copy it, close Equation Editor, create a new equation object, and then paste the contents of the old equation. The new equation could then be edited, with changes reflected in in the document as expected. Also, the baselines were correctly aligned (although the character immediately after was usually messed up). Unfortunately, this meant that thousands of equations had to be updated.
Although Word 2011 can be controled by Visual Basic, Equation Editor cannot. Nor does Equation Editor support Applescript. I'm not a huge fan of Applescript, but in this case, UI Scripting came to the rescue. I have been able to automate the entire process.
Below is a script that I have applied to one of our documents, and it seems to work quite well. It could certainly be improved (such as updating equations in the current selection instead of the whole document), but it does what I need.
A few notes: There are a couple delays embedded in the script. These are necessary to make sure the script doesn't get ahead of the user interface. Maybe someone can come up with a more elegant solution. Also, Equation Editor doesn't seem to respond to the 'keystroke' command, so menu actions had to be used. If there are 'empty' equation objects in your document, Equation Editor will issue an alert that needs to be dismissed. I suppose the script could try to detect this situation (another opportunity for improvement). Finally, in my test case, lower-case 'phi' gets converted to an alternate form.
I hope this is helpful to someone else that runs into a similar situation.
tell application "Microsoft Word"
set myFrontDoc to front document
set idx to 1
set myField to field idx of myFrontDoc
repeat while (myField exists)
tell me to ReconstructEquation()
set idx to idx + 1
set myField to field idx of myFrontDoc
on ReconstructEquation() -- Assumes an equation object is currently selected
delay 1 -- Give Word a chance to update the menus
tell application "System Events"
set theEditMenu to menu 1 of menu bar item "Edit" of menu bar 1 of process "Microsoft Word"
set theEqnMenu to menu 1 of menu item "Equation Object" of theEditMenu
click menu item "Open " of theEqnMenu -- note the space
repeat until process "Equation Editor" exists
delay 2 -- Equation Editor process exists, but we need to give it a chance to open
tell process "Equation Editor"
set theEEFileMenu to menu 1 of menu bar item "File" of menu bar 1
set theEEEditMenu to menu 1 of menu bar item "Edit" of menu bar 1
click menu item "Select All" of theEEEditMenu
click menu item "Copy" of theEEEditMenu
click menu item 2 of theEEFileMenu -- Menu item name depends on the document being edited
-- For some reason, keystrokes don't work:
--keystroke "A" using command down
--keystroke "C" using command down
--keystroke "W" using command down
repeat while process "Equation Editor" exists
click menu item "Paste" of theEditMenu -- Overwrite the selected equation
[crarko adds: I haven't tested this one; I don't really have the type of document this applies to. I did make sure the script compiles without error in the AppleScript Editor.]
I cannot get the hang of 3-finger drag especially when trying to select a row(s) of text. The obvious method is to put the cursor at the beginning and drag, or hold down Shift as you select the last character. Here's a better way, I think.
Double-tap the first word (using two fingers) to select it, then hold the Shift key and double-tap the last word -- all is selected in between. Subtle but to me much better, and it requires much less finger coordination.
[crarko adds: This works fine with the Magic Trackpad; and also seems to me a bit easier than aiming with the 3-finger drag, although that works too with some practice.]
If you are like me you saw the 4 GB Xcode installer the Mac App Store dropped in the Applications folder and promptly moved it to an external drive (Xcode installed is another 8 GBs or so making its footprint around 12 GB).
I have good news for those who want to keep the installer (to avoid having to download it again) while not having it on your primary drive. If the drive it is on is mounted when you run the App Store updater, the App Store will find it and update it. This way if you need to update the installation, you have the latest installer.
On that note, it looks like from the warnings and popups from today's Xcode update, large applications which require updating the installer and not the app (like Xcode) will be delta updated in their installer. Then to actually update the installation, one will have to run the installer which then will update the installation.
So rest assured, moving that large installer out of the applications folder onto a secondary drive should work just fine.
[crarko adds: I haven't re-downloaded the Xcode installer to put on another drive to try this, but it would be a very sweet and intelligent updater if it works this way. Also, can people confirm if this works on any other App Store installed software? Please share your results in the comments.]
Upgrade from an older version of MS Office (at least V.x, 2004) and documents opened in MS Office 2011 may appear to be blank or empty. Sometimes closing (not quitting the application) and re-opening the document allows you to see the content. The crux of the problem seems to be a problem with multiple copies of fonts.
Use Font Book to resolve duplicate fonts.
Manually remove the older versions of duplicated font files from ~/Library/Fonts.
Restart the Mac.
I recently upgraded several machines to Snow Leopard (10.6.8) and simultaneously moved them from MS Office v.X to the latest version of Office 2011 -- admittedly a big leap. Suddenly, everyone was complaining that their documents appeared to be blank when opened. All the text was missing (or simply not displayed) in Word documents and Excel spreadsheets. A very frustrating thing, when you know you spent hours creating it.
A little web research pointed me in the direction of a font problem -- a genuine bug in font handling within the MS Office 2011 suite. The work-arounds all mentioned using Font Book to resolve duplicates and even use the Reveal In Finder feature to locate and completely delete the older font files. Sadly, these steps, while necessary, do not completely solve the problem. Another step is required.
MS Office v.X (and 2004) had a bad habit of installing it's own fonts in each user's Library folder: ~/Library/Fonts. That means that copies of the fonts would be installed for each user account on a machine, leading not only to some duplicates with system fonts, but also multiple, user-specific copies of the same font, wasting disk space.
Font Book in 10.6.8 does not seem to really disable duplicate fonts located in the ~/Library/Fonts folder, or perhaps, MS Office just searches for them there anyway. To really resolve the duplicate fonts, I had to go to the ~/Library/Fonts folder and manually delete about a dozen older version font files that had newer versions already present in the /Library/Fonts folder, such as: multiple Arial files (the single largest problem since it is a common default font in Excel), Comic Sans MS, Edwardian Script ITC, Lucida Handwriting, Tahoma, Times New Roman, Wingdings and more.
After clearing out the duplicates, a restart is required to get the system to rebuild its font cache. When launched, MS Office will compare it's own font cache to the system's and upon finding a mismatch will rebuild it's own font cache, taking several long seconds while showing a 'blank' document.
Once those old version font files are gone, the documents all display correctly when first opened, and stay that way.
[crarko adds: This brings back horrible memories. I recall older versions of Adobe software did something like this as well, and resolving the font conflicts and/or rebuilding the font cache felt like it was a full-time occupation.]
Many people don't realize it, but there is no need to use a monospaced font in Terminal.app. The reason is that, unlike most other programs that render monospaced text (including all GUI text editors and web browsers I've tried) it enforces a monospaced character width. Therefore, if you type 12345678 in one line and abcdefgh in the next line right below it, then h will align with 8 regardless of whether the font you choose is monospaced or not.
With that being said, I still actually recommend that you do use a monospaced font, like Menlo or DejaVu Sans Mono (the latter is not included with Mac OS X, but is a font very similar to Menlo but slightly better in my opinion). The reason is that these fonts are designed to be readable despite the fact that shorter characters like i and l are just as long as longer characters like w.
If you do decide to try a non-monospaced font in Terminal.app for whatever reason, I suggest you play with the character spacing and line spacing controls in the font settings dialog. Some fonts are over spaced, and some are under spaced, and this can fix that.
[crarko adds: Just in case you feel a strong urge to experiment with fonts in Terminal, this is a reminder that you can. Even Zapf Dingbats works.]
Lion introduces a new tool in Preview. Press ` (the backtick key) or go to Tools » Show Magnifier to launch the magnifier. This produces a floating window that you can drag over your document, and it will zoom in on whatever area of the document is underneath the magnifier.
The size of the magnifier window appears to be fixed, but you can press + or – to change its size. At full zoom, the magnifier tool can end up larger than the size of the document window that you are viewing.
[crarko adds: A few people submitted this hint, and some also pointed out that the pinch-to-zoom gesture works with this feature.]
Mac OS X Lion adds a new, more aggressive auto-correct function to Safari, Mail and more. While some may find this to be a godsend, others may find it rather annoying. For example, doing a search for Pat Metheny in Safari will auto-correct to Pat Methane. Not exactly what I was looking for. Fortunately, there are ways to control this behavior both as a system-wide default option and on an app by app basis. Here's what you need to do:
To set the default system-wide state for auto-correct, navigate to System Preferences/Language & Text. Click the Text tab at the top and then you can check or uncheck 'Correct spelling automatically.' In order for this to take effect, your apps must be quit and then relaunched. Upon relaunch, the correct default state for auto-correct will be set.
To enable or disable auto-correct on an app by app basis, you need to be in an active text field (for example, in Safari you could go to Google and click to put the cursor in the search field). From there, navigate to Edit/Spelling and Grammar and then check or uncheck 'Correct Spelling Automatically.'
This was a bit confusing to me at first, because it seemed like there were 2 ways to do the same thing, but they didn't always work. For example, if you aren't in an active text field, the option will be greyed out in the app's Edit menu. It also seemed like the system-wide option didn't work at all until I realized that apps need to be relaunched in order to reflect the change. What I finally concluded is that Apple is giving the user system-wide control over this feature's default state and app by app control to override the system default. Very handy. If, for example, you like this feature in everything but Safari, you would then turn on auto-correct as the system-wide default, then go to Safari and turn it off for just that application.
[crarko adds: I tested this, and it works as described. If you've disabled it, and do want to do a check, just select 'Check Document Now' from the Spelling and Grammar menu.]
The iTunes Album cover screen saver just got a cool new feature.
Start up the iTunes screen saver and you'll see that you can now click on an album cover to start playing it. To exit there's now a button on the bottom right corner to exit.
An excellent way to spot an album you'd forgotten about and start playing it right away.
[crarko adds: Several people submitted variations of this hint, so I assume many of you have found this already. But if you haven't, here it is. I'm not sure, but this may also work in iTunes 10.4 in Snow Leopard. Let us know in the comments.]
When you activate some utilities like LaunchBar and MsgFiler from a full screen application it causes you to flip back to a Desktop. You can avoid this if the app allows you to disable the Application Icon in the Dock.
For both of the third party applications LaunchBar and MsgFiler, go to the application's preferences setting and disable the Dock Icon so that the application runs as a background application. Now switching to or activating the utility won't switch you back to a Desktop and leaves you in your full screen app.
If you have a utility that allows it to run in background and you run into this screen flip-flop problem, you can try setting it to background (no icon dock) mode and see if that helps.
If the utility/app doesn't have this option, MAYBE this very old hint will help to force some arbitrary app to run in background.