Much as I’ll admit to some spittle-flecked indignation when it comes to Visual Studio 20-anything, it has largely been the development tool that has paid my mortgage and allowed me to eat biscuits and cake. But this one takes the biscuit, cake, mug of tea and plate.

I’m happily working away, writing code when suddenly find in files stops working with the wonderful message “No Files Were Found To Look In. Find Was Stopped In Progress” Ah it’s simple. I’ve obviously fiddled with the search options and not selected the file types to search in or something similar. Nope –  everything looks just fine.

Ah I know. Close devenv and start again. Nope – exactly the same.

So, off for a coffee and moan and someone says: “Press Ctrl+Scroll Lock a few times and it’ll be fine”. This sounds a bit Mornington Crecsent to me, but it worked.

Sometimes I wonder if I should just go back to using notepad.exe

Advertisements

Ever had this problem trying to remote desktop (RDP) to a Windows Server 2003? I got very frustrated by this today. All the Administrator group sessions had been used up, the selfish remoters had gone home and left themselves logged in, so I wasn’t able to admin the server. Arrrrggg!

Yes, all I needed to do was to be able to get to the Terminal Services Manager and forcably terminate their sessions, but I couldn’t get in – the keys were effectively locked in the safe. The server I was trying to admin had a limit of 2 admin RDP sessions – the default limit for Server 2003 I think.

It turns out there is a simple answer to get around this (aren’t they all simple when you know them). The number of sessions on the server is calculated on the RDP client admin sessions, but console connections aren’t included. So the work around is;

Run a cmd session on your client machine and start a console based terminal service to the machine you want to connect to.

mstsc /v:xxx.xxx.xxx.xxx /f -console

where xxx.xxx.xxx.xxx is the IP or resolvable server name

You can then use Control Panel->Administrative Tools->Terminal Services Manager to disconnect the selfish remoters and connect with the RDP client as normal.

Don’t forget to logoff yourself when you’ve finished though.

QuickTime, short temper

February 19, 2009

I’m currently setting up a trancode farm using Rhozet CarbonCoder. What a great piece of software this is and a dream to configure and use when compared with FlipFactory. And it’s very cheap!

However, it requires QuickTime to run – no problem I thought – but you try installing and running QuickTime v7.6 on Windows Server 2003 SP1. It installs fine, but absolutely refuses to run, unhelpfully telling you…

QuickTime failed to initialize (error -2096).

A quick search reveals it may be a compatibility issue. There is an article indicating that turning off Compatibility mode would resolve this issue, but Compatibility mode is not turned on for iTunes or QuickTime.

The same issue is discussed in the Quicktime forum, here:
http://discussions.apple.com/thread.jspa?messageID=6400305

I struggled for a couple of hours, frustrated by something seemingly so simple stopping me doing what I needed to do – as usual in a hurry. I lost count of how many times I installed and then uninstalled QuickTime and CarbonCoder. I even resorted to cleaning the registry of any refernces to QT.

I eventually gave up and decided to go home. As I was walking out I realized I hadn’t actually tried installing an older version. I quickly grabbed v7.2 from the Apple site and – hey presto – it worked.

Now the point of all this really is the Apple support forum driving me mad. Yes, there’s an article posted there with a few replies http://discussions.apple.com/thread.jspa?messageID=6595367 but it’s been archived (so no replies) so now I can’t post my conclusive findings.

On the one hand I think Apple is great compared with Microsoft. On the other I think they are just as bad as each other. I guess the wind is blowing and it changed my mind for the day.

JSON and the Ajaxnauts

September 5, 2008

In a world of BBC News and broadcast media I’ve had a thrilling romp playing with Flex, JSON (and the Ajaxnauts) and revisited JavaScript. I’d forgotten what an awesome language it is when used properly.

Closures particularly are one of its most awesomely powerful features. Once properly understood they tend to roll off the keyboard almost by accident. It makes you wonder how you ever wrote software which doesn’t have them.

Much like my comments about C# thread syntax being easy to use and abuse without realising it, closures are easy to create, but have potentially harmful consequences for the unwary, particularly in IE. To avoid accidentally stepping on a closure landmine it is necessary to understand their mechanism. This depends largely on the role of scope chains in identifier resolution and so on the resolution of property names on objects.

Laurens van den Oever’s solution to stop you wetting yourself when programming for IE is a good one.  Incidentally, I needed a good XML to JSON converter and fairly randomly chose Thomas Frank’s to get me going. I intended to revisit this and write my own, but it’s been so good I shan’t bother – it’s been flawless.

I’m hardly a behemoth of jollity back in the world of C++ at the moment. Much as a think it is an excellent language, I am reminded that is so open to abuse. Take the following example I recently stumbled across.

try
{
  ...
  ...

  throw "Floating point error"
  ...
  ...
}
catch(const char *e)
{
  string strError(e);
  if (strError == "floating point error")
  {
    ...
    ...
  }
  else if (strError == "some other error")
  {
    ...
    ...
  }
  else if (strError == "some violation")
  {
    ...
    ...
  }
  else throw;
}

Clearly this is open to all sorts of problems. Probably the most obvious it breaks when the string content changes due to capitalization and the floating point error never being seen. However, for me the most significant problem here is a fundamental misunderstanding of what exceptions are really all about.

The author of this code is trying to catch an exception based on its value and not its type. A string literal contains practically no information about the type of exception being thrown. It’s no different to using a string to represent a float or complex number. You can do it but you’d be making hard work for yourself.

And this isn’t confined to string literals. Throwing ints, floats or any predefined type has all the same issues. Once caught, there is no real type information, so you can’t be sure what it represents and have to jump through hoops to fathom how to deal with it –  the Temple of Doom!

I’m not going into a long technical treatise about C++ exceptions; there’s plenty of books and online material that cover it much better than I could. However here’s some bullet point reminders I tend to keep in my head for such occasions that are mostly obvious.

  • exception types are abstract data types representing an exceptions.
  • provide some standard method (what) that describes the exception and maybe a code.
  • better still, derive from a standard exception type. You can then catch the specific type or the base class type.
  • make sure you’ve got a non-throwing copy constructor and destructor in place.
  • don’t throw exception pointers. The address of the exception pointer will be somewhere on the heap and isn’t protected for the duration of the catch. A temporary stack based exception is guaranteed to be safely persisted until the exception has been handled, regardless of platform and compiler.
  • throw by value and catch by reference
    • you prevent unnecessary copying of large exception objects
    • you ensure that modifications applied to the exception within a catch clause are preserved in the exception object if it is re-thrown
    • you avoid slicing of derived exception objects
    • you’ve got less work to do!

As Short Round said – “I keep telling you, you listen to me more, you live longer!”