You are affected by this bug if you browse to a WP3.1 driven site and your browser comes back with an error message similar to “too many redirects …”. Apparently in WP 3.1 they changed the way how page redirects are created – which fails under certain conditions. First I solved it by editing the PHP directly, but I found that there is a convenient plugin which just needs to be activated and all is good again:

Permalink Fix & Disable Canonical Redirects Pack

Thanks Chris for providing this – makes live easier

Usually, when you create an iOS user interface with InterfaceBuilder, you will have to deal with IBActions and IBOutlets declared in your ViewController files. Hooking up a UIButton’s TouchUpInside event to your actual event handling method in Xcode requires you to write somthing like that in your .h/.m files:

-(IBAction) myTouchupHandler: (id) sender {
//some code here
}

InterfaceBuilder will see that declaration and you would hook it up to the actual button’s event:

You simply drag a connection from “myTouchUpHandler” in the outlet inspector to the button on the view and select “Touch Up Inside”.

Any method “marked” as return type “IBAction” will show up in this connection list on the left – usually. Same for properties marked as “IBOutlet”.

For some reason this mechanism stop working for me. InterfaceBuilder simply ignored all IBActions and IBOutlets I declared. I double checked my syntax, cleaned all targets, but still no go.

After some research on Google, I found quite some of reports from users where “Xcode Interfacbuilder sync is broken”. A common hint was to reload the corresponding class files from IB manually. This indeed worked for me, but thats not a solution. Then I got closer – I realized that the green “light” at the bottom left corner in the screen shot above (where it says “testxc.xcodeproj”) was grey. This basically means IB has lost its connection to the corresponding project. Hovering over that grey light IB says “There is no Xcode project associated …”.

Great – this happened for all new projects I created. My real projects which I work on currently seemed to work though. More Google research revealed that this happens if you open (or create) projects from Xcode. If you open a project by clicking on it in Finder, it all works – the light becomes green for the project in question.

Reports on Google suggest that this may be due to different Xcode / InterfaceBuilder versions being installed. Indeed I have Xcode 3 and Xcode 4 beta installed. So I reinstalled both and tried this in several variations, but still no go.

Interestingly the same issue in Xcode 4, eventhough InterfaceBuilder works differently here. Btw., “Cocoa with Love” has an interesting article how Xc3 and IB communicate.

Solution

Apparently Xcode and/or InterfaceBuilder have issues with certain directories. My guess is that directory names being too long confuses InterfaceBuilder. If you open the project by clicking on it in Finder, then IB probably doesn’t see the full path, but the “current” one only and doesn’t care about its length, which makes the whole thing work. If you open the project through Xcode, then it sees the whole path and stumbles at a certain point.

So I moved my project from /users/olaf/some_long_sub_dir_for_test_projects to /temp/test and everything is working and green again! In Xc3 and Xc4!

Now who is this buyer called Attachmate? They are obviously an IT service provider offering enterprise level solutions. Steven J. Vaughan-Nichols of “Computerworld” suggests in his Blog “Who really bought Novell? Microsoft.” that Microsoft is actually behind that deal.

Well, interestingly for the Delphi world is though who actually owns Attachmate: “Attachmate Corporation is owned by an investment group led by Francisco Partners, Golden Gate Capital and Thoma Bravo” (from the press release mentioned above).

So why do I suggest that Embarcadero bought Novell? Well, check the owner of Embaracadero: Thoma Bravo! So in fact Embarcadero didn’t buy Novell, but will become a sister company of them! Quite some potential I guess

WHS just runs runs and back ap your computers. Additionally you can add several plugins such as iTunes media server and many more.

Drive Extender is some kind of a software RAID system. You can plug in multiple (different sized if you want) hard drives, and DE combines them to one big volume including redundancy. It works seamlessly for me here. I have 4 drives: 2 1TB ones and 2 500GB ones.

Michael lined out that the WHS figured that large harddrives became cheap lately (1 TB for under $100), which would make it less desirable for customers to combine these. So they deiced to rely on standard Windows Server 2008 technologies for WHS.

To me this doesn’t make much sense though: what if I wanted to combine two 2TB drives? Or even more? With redundancy in the back? Sure I can buy a hardware RAID, but the idea of WHS was to provide a low cost (yet stable) solution. A hardware RAID is certainly not helping in keeping the price tag small…

The next beta (with Drive Extender removed) of Home Server V2 (Vail) is expected to be released “early in the New Year”, Michael said.

I got many responses, which all said: “No, of course not. If MS is not using it for its own apps, then this is for a reason, and has nothing to do with SL’s well beeing.”

Well it appears MS has a different opinion now and somewhat agrees with me

There are many indicators now, that show that MS is moving away from Silverlight and will be focusing on HTML5 instead. Marco Cantu compiled a comprehensive collection of links that are important to read – if you are looking into SL for a future project. You might want to change your mind

Marco Cantu on Microsoft and Silverlight.

A while ago I posted a small tool that validates a VAT ID through an official Web service provided by the EU. In the meantime they change the Web service. The downloads below updated to reflect that change and I also updated to Delphi 2010.

Source code : VAT-Checker.zip

Executable: VAT-Checker.exe.zip

foo := TFoo.create;
try
  //do something with foo
finally
  foo.free;
end;

It basically means, that if you create an instance of some class and if there is no “owner” who takes care of the new instance’s life cycle, then it is your responsibility to destroy the instance again, as soon as you are done with it.

If you don’t care about freeing the objects you created, then you will get “memory leaks”, i.e. you app will use (possibly a lot) more memory as it should.

The technique above is clear and simple, but what if you have more than one object that is needed in a routine? Line them up?

foo := TFoo.create;
bar := TBar.create;
try
  //do something with foo and bar
finally
  foo.free;
  bar.free;
end;

Looks good, and I see this pattern frequently – but hold on! What happens if there is an exception when TBar is created? Right, foo won’t be destroyed in that case. So maybe handle it like this then:

foo := TFoo.create;
try
  bar := TBar.create;
  try
    //do something with foo and bar
  finally
    bar.free;
  end;
finally
  foo.free;
end;

In theory this would be the correct way, and there are a lot of examples that work like that. But look at the code – right: looks really ugly, esp. if we extend that to even more objects being created. Apart from readability there is also some performance hit: every try-frame needs some extra CPU cycles, which may sum up if your routine is time critical already.

My suggestion is this one:

foo := nil;
bar := nil;
try
  foo := TFoo.create;
  bar := TBar.create;
  //do something with foo and bar
finally
  bar.free;
  foo.free;
end;

Now lets discuss some questions about this pattern:

Didn’t we learn, that calls to “Create” have to be made outside the try-finally block?
No, not really. In fact it doesn’t matter where you create an instance of a class. The first example (which is mentioned in many articles) only suggests this, because it’s easy to do so with just one object.

If TBar.create fails, what happens with its bar.free counter part? Wouldn’t it actually be executed on some not “really created” object?
No, in fact bar.free is special method, which can safely be called even on variables pointing to NIL. Free checks if self<>nil and only then the actual destructor is called.

Why did you initialize fo and bar with NIL?
Because otherwise they might have random values. Esp. if they are declared as local variables. And we need NIL initialized variables so that “free” does not call random code in the case of an exception in one of the create calls.

If TBar.create fails with an exception, wouldn’t be there the chance that some address value would have been written to bar already – so that bar.free would be executed on some half initialized instance?
No, if TBar.Create fails with an exception, then the class function “create” would (like any other function) return NO value at all. bar would keep its original value that is.

Silverlight has quickly developed from version 1.0 to 4.0, which is the most current version as of today. Version 1.0 was released in September 2007, which means that Microsoft pushed 4 major releases in less than 3 years. Considering that the technology is non-trivial (some sort of .NET integration, derivation of WPF, plugins even for Mac OSX and non Microsoft friendly browsers, VS and Web Expression designers …), Microsoft obviously put in quite some man power to get this done.

Now I look at the recently released Office 2010 version, which also comes with a “Web version” of Office. Via office.live.com Microsoft offers Word, Excel, OneNote and PowerPoint as some sort of light editions of their desktop counter parts.

The layout looks nice, and indeed it feels almost like Office 2010 running on your desktop. The feature set is of course not (yet?) that rich, but for the occasional writer probably all features are there. Here and there it feels a little sluggish, but it works,. Collaboration is way below from what docs.google.com offers, but for a 1.0 version it’s okay.

Now you could have guessed “alright Microsoft’s Office Web team took Silverlight and made this a killer use case for it”, but interestingly if you look under the hood, by examining the HTML source, there appears to be not a single trace of Silverlight. At least I couldn’t find anything but HTML, Javascript and CSS.

This of course leads to the question “Is Silverlight dead?”. If Microsoft does not eat its own food or if the Silverlight team cannot even convince other Microsoft teams to use Silverlight (the SL pieces on the MSDN pages does not really count here imho), does that possibly mean there is something wrong with the technology?

Wir werden diesmal gewissermassen das Thema “Sauberkeit am Arbeitsplatz” behandeln, d.h. wir zeigen Ihnen alles zum Thema Sourcecodeverwaltung (Subversion), Debuggen, Fehlereingrenzung und Speicherprobleme. Als besonderes Extra zeigen wir Ihnen, wie man native iPhone/iPad Anwendungen mit einem Delphi Backend verbinden kann.

Die genaue Agenda und Anmeldung findet sich unter www.DelphiExperts.net

It’s an iPad only application – it’s a magazine. So it really makes use of the large iPad screen. On the iPhone it just wouldn’t be readable. Daniel and I (and actually Holger assisted us a bit) developed that application for our partner American International Media, who own the magazine. That copmany also owns the USA Sevens Rugby series, which is an interesting Rugby variant: 7 Players per team – 2 * 7 minutes.  From 2016 its gonna be Olympic.

Get the mag at Apple’s AppStore

We considered using Delphi Prism / MonoTouch for this application, but as we know that Apple would come out with a couple of new beta releases of the 3.2 SDK right before the submission deadline, we decided against it, to make sure we were able to deliver. We are working on a DelphiFeeds app though – which will be using Delphi Prism. Stay tuned for that.