Here’s a MSDN forum article that links back to my post about the VS2008 hotfix:
I believe there are known issues with VS2008 and web development. This article contains a link to some hotfixes for VS2008 web development. Maybe it’ll fix your problem: https://blog.wolffmyren.com/2008/02/11/performance-and-editor-fixes-for-vs2008/
Great post on how to share a solution between VS2008 and VS2005, from stevenharman.net/blog:
One of the things I’m most excited about with Visual Studio 2008 is it’s ability to target various versions of the .net framework, a feature known as multi-targeting.
I recently rebuilt a (hand-me-down) laptop for use at developer group meetings, conferences, and coding from the couch. When building out the machine I decided to only install VS2008 and make use of multi-targeting to work on my various .net 2.0 projects… like Subtext. Today I finally got around to loading Subtext up in VS2008 and I was expecting some heartache.
But I did a little research first and luckily came across Rick’s great post explaining how VS2008 and VS2005 can be made to play nice together, allowing you to work with your projects in either IDE. The gist is, the project files (i.e.- your
.csproj files) will work in either environment, but you’ll need to maintain separate solution files. Not a huge deal as most of the churn is usually in the individual project files, and not the solution.
(via Multi-Targeting VS2005 and VS2008 Web Application Projects, a Gotcha!)
- Until now, home.mcom.com and all URLs under it just redirected to netscape.com, then redirected a dozen more times before taking you to some AOL portal page. The old URLs that were baked into the toolbar buttons of the original web browsers didn’t work any more. But now, if you fire up a copy of Mosaic Netscape 0.9, and click on the various toolbar buttons, they will work again! For example, in the old browsers, when you clicked on the “What’s New” toolbar button, it went here.
- home.mcom.com is now a snapshot of that web site from 21-Oct-1994.
I found this on a forum post, and just wanted to verify that this information is correct:
for base64 the valid charset is:
the = is used as filler for the last bytes, as the length must be mulitple
The charset looks reasonable, but must the length be a multiple of 3? (Seems like a multiple of 4 would make more sense.)
Comments very much appreciated!
Here’s a great tip from Lifehacker about how to set up an AutoHotkey script to copy/paste without manually switching windows:
I have one very simple AutoHotkey script which I use when I need to do some massive copying and pasting work, which simplifies the task into just one keystroke: Win+C.
With this script, I run Notepad (or any program to paste the content into), browse through some web sites, select text or pictures, and hit Win+C to capture the content—without leaving my browser. The script switches to the destination program (Notepad or otherwise), pastes the information, and returns me to my browser automatically. Check out the video for how it works. It’s good for transferring bits of data between two programs like compiling a list of email addresses. It’s also customizable—instead of entering a new line, it can move on to the next cell in the spreadsheet.
(via Copy and Paste Without Switching Windows)
The mistaken belief that GIF has a limit of 256 colors probably comes from the way GIF was first used when it came out. In the late 1980’s, PC video cards generally supported no more than 256 colors. Image exchanges were becoming popular among BBS systems and the Internet and viewer programs were quickly produced. No one tried or needed to generate images with more than 256 colors since they could not be viewed on anything less than high priced graphics workstations. Programs that converted images to GIF worked up a number of methods to reduce the number of colors to 256 or fewer. Some actually did a very good job. GIF files were constructed with just a single image block, even though the GIF standard placed no limit on the number of blocks. Since there was no use for more than 256 colors, there was no use for more than one image block. This practice became effectively ingrained into the computer culture and eventually everyone “knew” that GIF supported no more than 256 colors. The fact is, the programs that generated GIF files supported no more than one image block, and thus didn’t have a means to deal with more than 256 colors. The top image shows that a GIF file really can have more than 256 colors.