Last year around this time, I was posting a daily blog with photos and thoughts on the Microsoft Tech-Ed 2007 conference. This year, I'm at my last day of the Microsoft Tech-Ed Developers 2008 conference. I was so exhausted last year, that I skipped the daily blogging this year and took things easy in the evenings. However, I thought I would put up at least one post containing my thoughts on this year's extravaganza.
I'll start by saying that it wasn't the extravaganza that it has been in past years. They split the conference over two weeks, so there's only 6000 or so people here this week (versus 14,000 or so last year). That, perhaps combined with the general state of the economy, has lead to lots of very apparent cut-backs. Little things like the empty tables that used to be piled high with snacks and the lack of any drink choices beyond pop and coffee, while not the end of the world, were definitely noticeable. I also missed having the option of attending a couple of the IT Pro sessions to get a different perspective on things. There were only maybe 1/3 of the usual vendors on site, and none were giving away big prizes. Last year, there were thousands of dollars, a Ducati motorcycle, and more. The party at Universal Studios was OK, but it lacked the same spark as last year's event at Islands of Adventure. For one, Microsoft had only rented-out half of the park. Several rides, including The Revenge of the Mummy roller coaster (my favorite) were off-limits to us. On a side note, I have to point out that Universal calling the Simpsons ride "new" is quite an overstatement. They just put a paint job on the old Back To The Future ride, replaced the Deloreons with roller coaster cars, and changed the movie that plays on the screen. Other than that, it's the same ride. It would be like taking your car with 50,000 miles on it, painting it and installing a new exhaust, then telling everybody its a "new" car. But I digress... :)
That said, the real point of attending the conference was still of similar caliber to years gone by. There was a ton of stuff to learn and a bunch of really good (some not so much) sessions from which to choose. It still got me jazzed about all the latest Microsoft offerings just like it always does. If this had been my first Tech-Ed, I would have been overwhelmed and wowed just like I was several years ago when it WAS my first Tech-Ed. However, the feel just wasn't the same this year. All things considered, I'm sure I'll be back again. My guess is that the Developer week of the show will continue to grow in size and I will, once again, be wowed.
PS - I almost forgot to add my usual plea to Microsoft. I submit this same request as part of every evaluation for every session.... "Slides should be made available prior to presentations to facilitate note-taking particularly by folks with tablet PCs. I've been asking for this for years, and I just can't understand why it never happens. If the slides are required in advance of the conference, why can't they be made available before the sessions? If you're looking to sell tablet PCs and copies of OneNote or Office with OneNote, this would be a perfect way to advertise their functionality. Print the PowerPoint to OneNote and write your thoughts right on the slides as the presenter is talking. It gives your notes much more context when you go to review them after the conference."
Showing posts with label Microsoft Development. Show all posts
Showing posts with label Microsoft Development. Show all posts
Friday, June 6, 2008
Monday, May 14, 2007
Pre-TechEd 1
So, the Microsoft TechEd conference is quickly approaching. For those who don't know what that is, check out the website. As in 2005, the conference is being held in the 2.1 million square foot Orange County Convention Center in Orlando, FL. There should be roughly 12000 people in attendance this year, and I'm really looking forward to it. I will be traveling down there with a friend and, as time permits, keeping a daily photo diary here on my blog. Stay tuned for more information.
Wednesday, February 14, 2007
Exporting/Importing Settings in Visual Studio 2005 - Part 2
As a follow-up to my February 5th post....
I must be getting a little slower with age, but I eventually realized that the reason the Visual Studio 2005 installation on my tablet PC was so different from the one on my desktop was because it was the Standard Edition, versus Professional on the desktop. According to this chart, the Standard Edition features "Simplified menu options and defaults". I guess that's what I was running up against. Well, since importing the settings from my Professional installation, the Standard edition has been "transformed" with most of the menu and toolbar options that were previously unavailable. It's solved all of my issues, at least. Seems like another instance of Microsoft simply hiding functionality instead of eliminating it for lower versions. I just stumbled upon a way of unlocking it, I suppose.
I must be getting a little slower with age, but I eventually realized that the reason the Visual Studio 2005 installation on my tablet PC was so different from the one on my desktop was because it was the Standard Edition, versus Professional on the desktop. According to this chart, the Standard Edition features "Simplified menu options and defaults". I guess that's what I was running up against. Well, since importing the settings from my Professional installation, the Standard edition has been "transformed" with most of the menu and toolbar options that were previously unavailable. It's solved all of my issues, at least. Seems like another instance of Microsoft simply hiding functionality instead of eliminating it for lower versions. I just stumbled upon a way of unlocking it, I suppose.
Tuesday, February 13, 2007
Interesting Free Software from Microsoft
Here is a list of a few interesting pieces of development-related software from Microsoft in no particular order. Each is either free or at least has a free version available.
- Microsoft Express Editions (Visual Studio 2005, SQL Server 2005, Visual Web Developer 2005) - "Free, lightweight, easy-to-use, and easy-to-learn tools for the hobbyist, novice, and student developer."
- Microsoft Robotics Studio - "The Microsoft Robotics Studio is a Windows-based environment for academic, hobbyist and commercial developers to easily create robotics applications across a wide variety of hardware."
- Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System Second Edition - "Install VSTO 2005 SE to create new application-level add-ins for six applications in the 2007 Microsoft Office system and five in Microsoft Office 2003. Use managed code to customize task panes and the Ribbon in the 2007 Microsoft Office system applications."
- ASP.NET AJAX (formerly ATLAS) - "ASP.NET AJAX is a free framework for quickly creating a new generation of more efficient, more interactive and highly-personalized Web experiences that work across all the most popular browsers."
- Microsoft CodePlex (think SourceForge for .NET) - "CodePlex is Microsoft's open source project hosting web site. You can use CodePlex to create new projects to share with the world, join others who have already started their own projects, or use the applications on this site and provide feedback."
- XNA Game Studio Express - "The XNA team is proud to announce the availability of the 1.0 release of XNA Game Studio Express and the XNA Framework, aimed at helping students and hobbyists build games for Windows and the Xbox 360. This release supports both Windows game development and Xbox 360 development (subscription to the XNA Creators Club is required in order to run XNA-based games on the Xbox 360)"
- Microsoft Expression - "Expression Studio, a key component of Microsoft's strategy for improving the user experience delivered by applications, provides designers with an end-to-end tools platform that boosts collaboration with developers in the delivery of next-generation user experiences for the Web, Windows Vista™ applications and beyond."
Monday, February 5, 2007
Exporting/Importing Settings in Visual Studio 2005
OK, so maybe I'm cheating with this post by referencing ScottGu's Blog, but I just love it when you do a web search and find exactly what you are looking for.
I was getting annoyed with the fact that my toolbars and other settings were different on my tablet PC than my work PC. Even more annoying was trying to figure out exactly where the settings were to change them. Add to that the fact that my tablet was using one setting to assume a default location for all projects and wouldn't allow me to specify different folders for each.... As an aside, I realize that it's really my fault and not my PCs. :) But if anybody asks, the computer did it!
Anyway, at this link, you will find Scott's tips on setting up, exporting, and importing custom profiles for the Visual Studio 2005 IDE. Over time, I had forgotten all the changes I had made to my work PC to get it to a point where I was happy. Simply exporting the settings and importing them into my tablet saved me quite a bit of time. Thanks, Scott!
I was getting annoyed with the fact that my toolbars and other settings were different on my tablet PC than my work PC. Even more annoying was trying to figure out exactly where the settings were to change them. Add to that the fact that my tablet was using one setting to assume a default location for all projects and wouldn't allow me to specify different folders for each.... As an aside, I realize that it's really my fault and not my PCs. :) But if anybody asks, the computer did it!
Anyway, at this link, you will find Scott's tips on setting up, exporting, and importing custom profiles for the Visual Studio 2005 IDE. Over time, I had forgotten all the changes I had made to my work PC to get it to a point where I was happy. Simply exporting the settings and importing them into my tablet saved me quite a bit of time. Thanks, Scott!
Friday, January 26, 2007
ASP.NET control naming (.ClientID and .GetPostBackReference)
If you've done much development with ASP.NET, you know that all of the controls you include in your ASPX code get renamed for the resulting HTML script. For instance, "MyControl" might be converted to "ctl00$MyControl" on the client side. You probably have also read that you shouldn't assume the name of the control on the clients side if you need to access it via JavaScript. This "best practice" is intended to avoid errors resulting from Microsoft switching naming conventions in subsequent versions of the .NET framework. Thus, they provide a number of server-side calls to determine what the ID of the control will be once it gets to the client. This post is intended to point out an issue that I noticed when using MyControl.ClientID and Page.ClientScript.GetPostBackEventReference(MyControl).
MyControl.ClientID returns what you might expect, the ID that the control will have in the client HTML code.
The latter method, GetPostBackEventReference returns a string that is the client-side, JavaScript code to execute if you want to cause the page to post back targeted at the specified control. For instance, calling GetPostBackEventReference(MyControl) would return "__doPostBack('ctl00$MyControl','')". Executing this code in JavaScript causes the page to post back and attempt to execute a server-side postback event handler on MyControl. It achieves this by submitting a form value, "__EVENTTARGET", that is automatically read on the server side to determine which control caused the postback. Anyways, that's the gist of what happens. What was the point of this post again? :) Oh yeah, I remember...
I created a page with a custom control on which I wanted to be able to force postback via JavaScript. In order to implement this, I used GetPostBackEventReference(MyControl) to create the line of JavaScript code to execute and then simply called eval() on it at the appropriate time on the client-side. When postback occurs, the load event handler for the page always runs prior to any other event handlers being called. In my situation, I wanted to perform special functionality if MyControl caused the postback (versus the other controls on the page). To determine this, I decided to simply compare the value available in Page.Request.Params("__EVENTTARGET") to MyControl.ClientID. It seemed simple enough. If the two were equal, then I could assume that MyControl caused the postback. I was surprised to find out that this approach does not work. The client ID returned by GetPostBackEventReference was equal to "ctl00$MyControl" while the value returned by MyControl.ClientID was "ctl00_MyControl".
All in all, it's wasn't a major issue. A little string manipulation and the use of MyControl.ClientIDSeparator did the trick. However, I think it is resonable to expect the two values to be equal since they refer to the same control. The fact that they are not seems like a bug.
On a somewhat related note, shouldn't there be a constant for "__EVENTTARGET" somewhere in the .NET API? After all, you're not supposed to assume the client ID of the control or the postback method call. What happens if Microsoft decides to change the ID of the form element some day. It's odd that they didn't seem to take the same approach as they did with the other client values.
MyControl.ClientID returns what you might expect, the ID that the control will have in the client HTML code.
The latter method, GetPostBackEventReference returns a string that is the client-side, JavaScript code to execute if you want to cause the page to post back targeted at the specified control. For instance, calling GetPostBackEventReference(MyControl) would return "__doPostBack('ctl00$MyControl','')". Executing this code in JavaScript causes the page to post back and attempt to execute a server-side postback event handler on MyControl. It achieves this by submitting a form value, "__EVENTTARGET", that is automatically read on the server side to determine which control caused the postback. Anyways, that's the gist of what happens. What was the point of this post again? :) Oh yeah, I remember...
I created a page with a custom control on which I wanted to be able to force postback via JavaScript. In order to implement this, I used GetPostBackEventReference(MyControl) to create the line of JavaScript code to execute and then simply called eval() on it at the appropriate time on the client-side. When postback occurs, the load event handler for the page always runs prior to any other event handlers being called. In my situation, I wanted to perform special functionality if MyControl caused the postback (versus the other controls on the page). To determine this, I decided to simply compare the value available in Page.Request.Params("__EVENTTARGET") to MyControl.ClientID. It seemed simple enough. If the two were equal, then I could assume that MyControl caused the postback. I was surprised to find out that this approach does not work. The client ID returned by GetPostBackEventReference was equal to "ctl00$MyControl" while the value returned by MyControl.ClientID was "ctl00_MyControl".
All in all, it's wasn't a major issue. A little string manipulation and the use of MyControl.ClientIDSeparator did the trick. However, I think it is resonable to expect the two values to be equal since they refer to the same control. The fact that they are not seems like a bug.
On a somewhat related note, shouldn't there be a constant for "__EVENTTARGET" somewhere in the .NET API? After all, you're not supposed to assume the client ID of the control or the postback method call. What happens if Microsoft decides to change the ID of the form element some day. It's odd that they didn't seem to take the same approach as they did with the other client values.
Subscribe to:
Posts (Atom)