Fixing Microsoft Office 2011 for Mac – AutoUpdate Cannot Connect to The Update Server

I recently did a clean install of my iMac to OS X Mojave, which required of course reinstalling all my apps, including Microsoft Office 2011. That’s the last version that I have purchased from Microsoft and although already 7 years old at current time of writing, it still works perfectly fine and I see no reason at all to upgrade to Office 365.

However, after reinstalling Office 2011 for Mac from a back-up dmg file, I was unable to use the built-in Office autoupdater to get any updates. Any attempts result in a pop up box saying rather cryptically “AutoUpdate Cannot Connect to The Update Server”. Well…

…turns out Microsoft has stopped supporting this product as of 2017.

And unfortunately, the stock Office 2011 (i.e. version 14.0.0) does not support Retina resolutions, so text looks pretty bad on retina capable screens, such as my late-2015 retina 5K iMac.

If you are facing the same problem as I was, fear not though, you can still download the updates directly from the Microsoft site if you know where to find the relevant download pages. So here you go…

First download and install Service Pack 1 (v14.1.0): https://www.microsoft.com/en-us/download/details.aspx?id=17198

Then after that, download and install Service Pack 3 (v14.7.7): https://www.microsoft.com/en-us/download/details.aspx?id=55942

That will bring your install up to the final version that Microsoft will ever provide for Office 2011  for Mac.

If this helps you, I’d strongly suggest saving copies of those 2 service pack installers in case you ever have to go through a reinstall again. Microsoft probably won’t leave those downloads up indefinitely so have your own backups just in case.

 

Advertisements

Fixing Mac OS X Bluetooth Disconnect Issues

I use a late-2015 iMac (currently) running OS X High Sierra as my main work machine. From day 1 till just a few days ago, bluetooth has worked flawlessly on this machine. The bluetooth Apple keyboard and TrackPad 2 that came with the iMac both paired seamlessly right out of the box, and I’ve never had a connection drop or any other issue, even after going through 2 rounds of major OS upgrades (first to Sierra, and now to High Sierra).

Then suddenly out of the blue a few days ago, the bluetooth connections to both the keyboard and trackpad would drop roughly 20-30 seconds after the machine wakes from sleep. Most times, they would not reconnect on their own, and sometimes, the bluetooth status of the machine would actually report bluetooth was OFF with no option to turn it back ON.

Simply removing the devices and re-connecting them would work to keep them connected only until such time that I sleep the machine and wake it up again. Whereupon the whole disconnect cycle would repeat.

Trashing the Bluetooth prefs file and resetting the machine SMC did not solve this problem. Finally what seems to have done the trick to fix it is Resetting the Bluetooth Module on the iMac via a little known special menu accessible via holding “Shift + Option” then clicking on the bluetooth icon in the top menu bar.

This brings up the among other things a “Debug” sub-menu with the option to “Reset the Bluetooth Module”. And easy as that, disconnect issues have now been resolved!

Fixing dispatch_async error in Swift 3/4

If you are copying some older Swift code (say circa 2014/15 or older) off the web to ensure some code is executed on the main queue, such as like this:

dispatch_async(dispatch_get_main_queue(), {
//do something that must be done on the main queue
})

You will be greeted with these 2 errors by Xcode:

‘dispatch_async’ has been replaced by instance method ‘DispatchQueue.async(execute:)’
‘dispatch_get_main_queue()’ has been replaced by property ‘DispatchQueue.main’

And unfortunately Xcode doesn’t offer to “fix” this for you automatically as it often does with other method calls that have been deprecated.

The new way to perform such a call is simply this:

DispatchQueue.main.async {
//do something that must be done on the main queue
}

 

PHP usort is slow slow ssslow…..

PHP’s native usort array sorting function is handy especially when you need to sort an array by some custom criteria, and other sorting options like sort, asort or ksort just don’t have enough flexibility.

But man, on any reasonably sized dataset, usort is just too slow! How slow you ask? E.g. with an array of 150 elements, using usort adds 3 seconds to loading time on a webpage that displays this data (versus no sorting at all). 3 seconds might not seem like much, but consider:

  • Most nowadays web users are accustomed to pages loading in 1-3 seconds total, otherwise they simply click back and don’t bother waiting. So using up 3 seconds just for a sorting function is not really acceptable
  • That 3 second lag for usort to do its thing gets exponentially larger as the dataset grows

Is there a solution? Only thing I can think of is code refactor to not require usort. Sorry but that’s the sad truth.

Easy UIPickerView with RxSwift & RxCocoa Magic

RxSwift (and RxCocoa) make it super easy to wire up a UIPickerView for your IOS project. No need to bother with the UIPickerViewDataSource and Delegate protocols and the attendant methods that you would normally be required to implement. Instead, it can be as simple as this in your viewcontroller:

import UIKit
import RxSwift
import RxCocoa

class MyViewController: UIViewController {

  // MARK: – Variables
let
disposeBag = DisposeBag()
var pickerView = UIPickerView()

  override func viewDidLoad() {
    super.viewDidLoad()
    setupRx()
}

func setupRx() {

        //#1 bind your data to pickerview
Observable.just([“Item 1″,”Item 2”, “etc”])
                             .bind(to: pickerView.rx.itemTitles) { _, item in
                return \(item)”
         }.disposed(by: disposeBag)

        //#2 handle pickerview selection
pickerView.rx.itemSelected.asObservable().subscribe(onNext: {item in

            //item.row gives you the index of the selected item, so do what you need with                  it

            //also here you can call .resignFirstResponder() on whatever element brought up the pickerview (e.g. a button) in order to close the pickerview

        }).disposed(by: disposeBag)

        //optional: preselect the second item in pickerview
pickerView.selectRow(1, inComponent: 0, animated: true)

}

} //end class

So what’s going on?

In #1, we bind our data to the pickerview. In the example we simply have a small array of some strings to display. This could instead come from coredata, over the network, or whatever your app requires.

In #2, we set up the subscription to observe selections made on the pickerview. In the closure’s body you can put whatever business logic you need to handle the selection, with “item.row” giving you the index of the selected item from the array. You would also call resignFirstResponder() here in most cases in order to close the pickView.

And that’s it! Neat huh?