SQLEditor 1.4b2 is now available, which is pretty much bug fixing against 1.4b1.

There were several issues with 1.4b1 including an annoying bug that would sometimes delete foreign key connectors when you deleted an unrelated table.

There are some fixes for other bugs which turned up and some improvements to undo/redo, to make it more stable when you undo or redo lots of things, one after the other.

I’ve also moved SQLEditor to Sparkle. Sparkle replaces an update system that I wrote myself and it should offer better update support as well as a nice html based ‘what’s changed’ window.

SQLEditor also now tells people that it is a beta and exactly when it will expire. It probably should always have done this, but it does it now, which is probably good.

There are also some minor fixes to the live source view, so that it changes with the document sql dialect and appears correctly when reopening existing documents.

[Download] (3.4MB DMG File, changelog)

There is also a new downloads page which currently offers an Applescript to validate the source of the front page in Safari.

Usefully it validates the actual source that the browser received, it doesn’t download the url itself.

It runs on PowerPC or Intel Macs with Mac OS X 10.4 or later.

The current version expires 28th February 2007.

HTMLValidator is a new desktop HTML validator that works on both web pages and files. It’s something I’ve been working on for a while now in between SQLEditor releases. The main motivation is that I often seem to use the W3C validator, but I can’t always do that with files I’m working on locally. I also tried installing the W3C validator on a local web server and although it works, it seems to require a lot of installation effort, with different dependencies. So the idea occurred to me: what if you could have a drag and drop installation. From there came a web version using drag and drop and finally the application bundle version that is being distributed from today.
The earlier application versions actually displayed the results in an html webview in a window, while the newer releases display the results in a table.

On the drawing board for future releases are more validation options, the capability to validate multiple pages and the ability to watch pages for changes and then validate. Also better printing and Applescript support (although both of these are present in the current version).

I’m really interested to know what you think of HTMLValidator so feel free to send in comments, either to me personally Angus [DOT] Hardie [AT] malcolmhardie [DOT] com or to the support [AT] malcolmhardie [DOT] com email address

It has now been fixed, along with slight improvements to image saving and a fix for a menu shortcut not being correct. The latter was an odd problem in that a shortcut was set, but it actually conflicted with an existing shortcut and the cocoa menu system is smart enough not to display the same shortcut for more than one menu.

[Download] 2.8MB DMG

For some reason also I don’t think I posted about the 1.3 release. But the 1.3 release was posted on November 23rd and is the first non-beta release to be released since May 2006. It rolled all of the improvements that had been made during the beta testing phase into a new release and is definitely worth upgrading (especially since the upgrade is free). However the 1.3 release has been superceded by the 1.3.1 release, so download that instead.

Imagine the circumstance: you want to use a particular non-standard version of a native library which is already part of the system; perhaps you want to use an old version with better compatibility, or a newer version with more features. The obvious thing to do is to take a static build of the library and add it your xcode project.

However this typically won’t work. The linker will choose the system version instead because by default it looks in all possible locations for a dynamic library first before looking through the same list of locations for a static library. If there is a dynamic library in any of the search locations it will always get chosen. There are some good reasons for this, but what if you really want to include your own statically linked version?

The answer is to add the -Wl,-search_paths_first flag to the other link flags option (under linking in target settings).

When this is set each possible location for a library is inspected first for a dynamic library and then for a static library. This means that the static library will get linked correctly.

It’s not exactly something that will be needed frequently though.

Edit: Apple have a technical Q&A article (1393) on this very subject which appeared a couple of days back and which I somehow missed.
It offers this exact method. [Link]