Derek Stone

Obviously you are in a better position to judge for various reasons Tim, however my statements were focused at changes and new additions that are present as a result of Longhorn, not SQL Server "Yukon" or various other pieces of the puzzle. Yet again, I've managed to be less than clear, so I think I'll just step back from this thread. :)

About 10% of programmers are women, so I assume the ratio is the same here. As for whom those women are in specific I prefer not to speculate and let them answer themselves.

You'll need to invoke the Win32 API function [api]SetForegroundWindow[/api].

Which of course is not to say they couldn't.

How are you registering the attribute? Directly in the element definition or via the element's Attributes collection? Might not hurt to try the other method to see what results are generated.

You're absolutely kidding yourself if you think it's harder to replace a jmp command with a nop command in a natively compiled executable than to do the same in an assembly code in IL. Shareware programs are just as vunerable then as they are now, and anyone that says otherwise is living in a world of delusion. With that said you also need to remember that no one cares what your source code looks like. .NET has almost completely removed the need for "creative coding", since most of the functionality one needs is already available in the BCLs. Software is created to meet the needs of a customer. Generally it isn't created to break creative boundaries or to be looked upon as something unique, since within time someone is going to capitalize on your idea and there's little you can do about. What it boils down to is that all software developers need to accept this and move on with their work. The time you're wasting on obscuring your "masterpiece" is time you should be using to entice users to your product.

http://www.xtremedotnettalk.com/showthread.php?s=&threadid=75908

You'll need to impersonate said user from within the thread of execution in order to access their HKEY_CURRENT_USER registry hive.

Windows Forms, by default, have no problems displaying non-English characters. Either you have changed the label's font to one that doesn't support such characters, or your file handling scheme is flawed. You may want to post the code in question.

Creating the IDbCommand object once and changing its CommandText property should work just fine.

Let me be the first to express my distaste for the new toolbar "style".

After re-reading my previous post it may have been slightly unclear. Whidbey is not slated for release with Longhorn, nor is it intended to contain support for it on any grand scale. Orcas, the following version of Visual Studio .NET with be the coinciding release, and will contain the support you seem to be enquiring about. Very few changes will be made to the framework that'll be released with Whidbey and most improvements focus on the development environment itself.

Once you see firsthand how much money goes through an academic institution (and how much of it is waste) one really has no urge to offer such gifts. However, one does sympathize with teachers who are purchasing such educational tools out of their own pockets since their requests for these tools often go unnoticed.

You have to remember that Longhorn is more than 2 years away. Whidbey, the next version of Visual Studio .NET, is currently in alpha, and already supports some of what Longhorn has to offer, including XAML (yes, XAML not XML). Most people won't hear of these types of features or the new Longhorn API until late in the beta/release candidate stages when testers and develolpers are no longer under the watchful eyes of non-disclosure agreements.

And you expected there to be less integration? Microsoft has a "small" paradigm when it comes to such an issue, court cases or no court cases. :)

You can create Excel files on a client machine without Microsoft Office installed, however to do so you'll need to acquire, whether from a commercial source or a free component site, a library that can write to the Excel file format. Of course if the client does have Microsoft Office installed it's a simple matter of using the Microsoft Excel Object Library to generate a workbook.

All errors generated by SQL Server will result in SqlException being thrown. You can query the SqlException.Errors collection and the SqlException.Number property for more details as to what caused the exception.

[msdn]System.Web.UI.HtmlControls.HtmlInputFile[/msdn]

I'm sorry, but impersonating an administrator is the worst thing one can do in terms of security. I strongly suggest against doing so.

I'm fairly certain the Workbooks.Open method of the Microsoft Excel Object Library includes an optional parameter for a password.

Administrative Tools > Microsoft .NET Framework Configuration There are several ways to accomplish what you're aiming for however, and you need to take the time to read up on which is the most appropriate option for your application. [mshelp]ms-help://MS.NETFrameworkSDKv1.1/cpguidenf/html/cpconsecuritypolicyconfiguration.htm[/mshelp]

You do realize an Excel password can be acquired within seconds from the *.xls file using one of many programs found on the Web? It is not secure in the least.

That's not how security in .NET works, thank God. You can't just get around it as your attempting to do. You need to change the assembly's policy or you'll keep getting the same security exception.

ASP.NET applications are not allowed to interop with unmanaged code by default.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/emab-rm.asp