Author: VHiStory

Why does Visual Studio Intellisense stop highlighting the suggested completion?

This has happened to me quite a few times, and the answer is annoying simple, and annoyingly hard to find.

When I am typing code in Visual Studio, particularly in C#, I’m very used to the way Intellisense usually works. I type a couple of characters of a method name, for example, and Intellisense shows the completions it can find, with the most likely item highlighted. At that point, it will fill in the completion if I type Enter, or an opening parenthesis, or a dot (if it’s a property – basically whatever the next symbol after the name I want it to enter.

But sometimes, seemingly randomly, it stops highlighting the suggested completion. It’s still the selected item in the dropdown, but now it’s merely selected and not highlighted, and to use it I have to type Tab, or hit the down arrow to highlight it then type the next character after the name. It’s different, not what’s in my muscle memory for typing code. And I could never work out quite why it happened.

I think, previously, I’ve had to completely nuke my Visual Studio settings to get the old behaviour back, which obviously I don’t really want to do. I assumed this was some kind of bug.

But I think I’ve found out why it’s happening, and the VS command to revert it.

The setting is not found in Tools->Options->Intellisense where I was looking, which explains why I didn’t find it.

It’s actually in Edit -> Intellisense -> Toggle Completion Mode, a simple toggle of this behaviour. And it has a shortcut – Ctrl-Alt-Space. I think it’s the shortcut that’s been causing it, as that might possibly be a key combination that I can hit accidentally, although rarelt enough for me not to notice.

But now, I hope I can remember where to find the option. Writing this entry is an effort to make it stick in my memory.

Thanks to Machet on Stack Overflow for pointing the way.


The hidden cost of Editor Templates

I’ve been doing some ASP.NET MVC work recently, for a new client, and I just had to work on a site that we performing badly. It was a simple site for signing up to an event, but the admin page was taking a very long time to appear. A bit of database profiling suggested a lot of traffic to the database, which was my first suspicion.

But I wanted to get a bit more visibility on how much work the server was doing, so I thought I’d take the opportunity to try out Glimpse.

A simple nu-get install was all it took, and the next time I fired up the site to test it, I got the glimpse Head-Up Display at the bottom of the page showing some headline figures.

glimpse hud

The HTTP section shows how long the request took in total, and broken down into server time, wire time (how long it took for the page to be sent over the internet) and Client time (how long it took for the browser to render the page once it received it).

On my page, the Client figure was quite high, as the page contained a big table of customers which was then being turned into a paged table by jQuery. But the server figure was still high – over 60 seconds.

I quickly found a large database query that, it turned out, wasn’t actually used to generate the page, and was only used to cache data for an ‘Export’ button. Since the Export was a little-used feature, I decided it was better to leave the export data fetching for when the user actually requested it. This made a big dent in the time taken – and removed about 1330 database requests.

But the page was still taking a fair amount of time – about 16 seconds – and now it wasn’t the database that was causing the delay – total database time was well under a second.

The Client processing time was still quite long, but the server was still slow, so I looked a the Host section, which breaks down the time taken in the Controller Action and the View. For this page, the view was taking way longer than the controller, despite there being no real data processing in the view, so clearly something was causing a lot of work in the view.

This might have taken a long time to diagnose, but Glimpse showed its value again, with the ability to drill down into the details of each part of the MVC engine. When you click the ‘g’ logo on the right, it opens the details window, which has tabs for all the different things Glimpse logs.

Glimpse views tab

I wanted to see what the Views tab said – and sure enough, it showed a lot – there were hundreds of entries in that log for this single page, because the customer list was being rendered by an Editor Template.

Editor Templates are useful things. When you’ve got a complex class as your ViewModel, they allow you to write a template for the component objects, and the framework will do all the heavy lifting of calling the templates for the properties of the ViewModel.

The problem with my page is that I was using a template for over 500 objects in a collection, and what Glimpse was telling me was that the server was spending a lot of time finding the view for each of the objects, and it wasn’t caching this template.

Now, one of the reasons to use templates like this is so that your controller action can simply accept your model class as an argument, which keeps your code simple, but in this case, it was causing far too much server work.

Luckily, the controller that was handling the form data didn’t actually need the entire viewmodel – in fact, for my purposes, all I required was a single checkbox per item which contained the item ID.

This allowed me to remove the Html.EditorFor call that was generating all the template traffic, and put in my own loop.

At the same time, I simplified the code in the template. It was using Html.DisplayFor for textual fields, so I replaced those with just putting the literal fields in.

I had to change the signature of the controller action to simply accept an array of IDs, but that was the only information it was taking from the original model, so the rest of the code didn’t change. But it had a dramatic effect on the rendering time.

With these changes, the View rendering time plummeted, from around 8s to less than a second.

As a result of these changes, a page with over 500 customers in a paged table dropped from around 75 seconds down to around 4 seconds (half of which was the jQuery pagination happening).

Not a bad result, and it would probably have been much, much harder to track down the bottlenecks without a tool like Glimpse.

No Good Deed Goes Unpunished

I’ve had a fraught two weeks with my Windows Store developer account.

I signed in, checked the dashboard, but when I tried to look at reports for an app, I got an error page saying my account had been locked. There was no indication why.

After trying a few things, I got in touch with support. We had a bit of back and forth, before he told me that, to my horror, my account was cancelled, and removed from the system. However, it turned out that he had been looking at my old developer account, with a different email address (the one I had been using for correspondence) which had, indeed, lapsed earlier in the year.

Despite this original ticket having been raised on the correct dev account, I had to raise another ticket, and explain the problem again. Once more, the back and forth, but at least I got more information – that my account had not auto-renewed because the credit card was declined.

I was a bit confused by this, because I’d received, back in July, notification that my account had been successfully renewed. And I had not received any notifications that the credit card had been declined.

But, when I delved into the commerce section of the site, I saw the attempts at renewal, and the declines. OK, no problem, that credit card had indeed been replaced by my bank, so I added a new card to the account and tried to renew.

I got a cryptic ‘Service Error’ message. No matter what I tried, several different cards, as well as PayPal, all I could get was ‘Service Error’.

I was relaying all this to the hapless support person, who couldn’t seem to help at all.

Then, several days after I’d started this whole odyssey, I suddenly got an email saying my developer account had been cancelled.


If true, this meant my apps would be removed from the store, and I’d have to create a whole new account, and submit the apps again. Existing customers would not get any upgrades, and would not be able to download the app again if they needed to.

This was quite serious. The tone of my emails to support got a little more panicked, as I threw terms like ‘bad faith’ and ‘incompetence’ at him, hoping he’d escalate the issue. However, all I could get from him in return was the same message – my account was irrevocably removed, and I’d have to create a new one.

Until today when, after I replied to his last message, asking for progress on escalating the issue, he replied with all new information.

He said that ‘Recently the developer subscriptions do not expire.’ and suggested that everything looked fine on my account.

He was correct. All was well.

Because of this: New Dev Center lifetime registration and benefits program

The Windows Store dev program has just made accounts a one-off payment. So clearly my renewal difficulties, and the cryptic ‘Service Error’ I kept getting was a result of the internal changes that were happening in the subscription system. I was just unlucky that my registration renewal happened to coincide with the switchover.

I wish they had been able to communicate this change to their support people, though. I had a very fraught two weeks, thinking that I’d have to go through the hassle of recreating an account, and resubmitting apps, along with possibly alienating existing customers.

It demonstrates some of the problems of outsourcing your support so far from the development teams. When I first started in software development, every developer in our (small) company had to do tech support regularly. It kept us aware of issues real users were having, and users got information straight from the people who knew how it all worked. If your support staff aren’t even on the same continent as your development staff, the quality of support is going to suffer.