There are a few examples of that around (SharpReader is a good example of a non-programming-oriented program), but it is true that the size and hassle of downloading the CLR makes it less convenient for the end user. And there is inertia, both in programmers and in their existing code.
On the other hand, it's generally much easier to write a windows program in C# than it was in C++.
Eric Gunnerson (msft) wrote: On the other hand, it's generally much easier to write a windows program in C# than it was in C++.
Yeah, that's why I'm surprised more people haven't flocked to C# as the language of choice for hobby-development. I'd guess that given the number of people with broadband these days, most people probably have the CLR installed, don't they?
I think one thing that is increasing the inertia of ".NET" is that it is becoming more and more of a buzzword for program managers on up in larger corporations that want to move in this "new" direction. My CEO decided on it even before he knew exactly what it was (good thing he hired me to architect it since I had about a year of experience starting with the 1.0 betas). Of course, this is extreme (and extremely stupid) but I see it happening more and more.
We do, as you can easily tell, have a .NET application and bootstrapping the CLR has been a problem, especially since the bootstrapper that Wise uses for the MSI product doesn't force the selected runtime (if a newer one is installed, it doesn't bootstrap the .NET installer). When I get time (someday it won't be hard writing a new one, but we have had complaints from people trying our software out that the .NET runtime is just too much of a hastle. This is an Internet-deployed smart client, so they have to take the time to download and cache (ala Fusion) our application as well.
I do forsee this picking up when Longhorn reaches fruition, but wide-spread adoption of that I'm sure will take time (especially since it requires a much beefier machine).
So long as people keep up-to-date with Windows Update (and I know that has been a problem Microsoft has been trying to address and push...and I agree they should), they should have it. Perhaps when more free/shareware developers take note of this they will reconsider.
Allot of the programs on those sites is made for more than
Windows. I hardly think saying that these people are not
smart enough to figure out yet another new language is
what people need to be doing? Just because someone wants
to use a language that is not proprietary and make there
programs portable does not mean that they know very little.
I think that people need to consider the source when reading
things like this. Most of the time it comes from people that
doesn’t even have a job and if they do it is not much of one
considering that he spends all day every day answering peoples
questions in this forum. Always bad mouthing people, calling
those people names and saying that they are dumb because they don’t
jump on Microsoft's next big thing, forget about the fact that
they have all this old code that has been written and tested.
They call them dumb and out of date in one line and in the next
say that not all are like that. Please give me a break.
Wouldn't it be better to say that .Net is new and as with
anything new, if it's good enough then it will catch on.
I done that and didn't call anyone a name or insult there
Intelligence, wow that was real hard.
It depends on the ComboBox.DropDownStyle style. If you're using ComboBoxStyle.DropDown, you can select and enter new text. If you use ComboBoxStyle.DropDownList then only the list items in that ComboBox can be select and, hence, there is no need to highlight certain text. This behavior is defined by the Combo Box Common Control which the .NET ComboBox class encapsulates, hence the behavior is the same for native Combo Box controls in Win32 applications. This is not a bug.
Actually, you can't select the text even if you are using DropDown instead of DropDownList. You can edit the text and enter new text, but you can't highlight the text with the mouse like you normally can in an edit box. You can use shift and the arrow keys to highlight text, but holding down the mouse button and moving the mouse will not work. I've read on the internet that this is a bug.
Does any one know of any combobox controls on the internet that might fix this bug, or would the only way to get around it be capturing the mouse events and trying to do it on my own?
Works in .NET 1.1, but I did notice it doesn't work in .NET 1.0. Never noticed that. If you can, upgrade your code base to 1.1. It does contain enhancements and bug fixes (like for this bug! ) after all. If not, you could implement this using the mouse events or overriding WndProc in a derived class and handling the notification messages, though doing all that should be exposed through mouse events and managed methods already (at least in this case). Note that creating such a work around will probably break the correct behavior when run under .NET 1.1.
All managed code written from a language which targets the CLR compiles to Intermediate Languages, or IL. Assemblies are language-independent. Just add a reference to this managed assembly in your C# project, just like you reference System.* assemblies (almost all written in C#) in VB.NET. As far as assemblies are concerned, the source language in which they were written does not matter (although some languages support more features of Microsoft IL (MSIL) than others).
IMO, C#. It was, after all, written from the ground-up for the .NET Framework and supports almost every feature of MSIL based on what I've read in the ECMA standard for the Common Language Infrastructure (CLI). It also offers a syntax similar to many powerful languages like C++, Java, and Perl which makes learning and knowing other languages easier.
For strings, yes, because they are immutable and handled a little differently. I agree that ref and out are handy even in managed code (they are often necessary when P/Invoking native methods, sometimes even with reference types (like for pointer pointers)), but in the case discussed here they are not.
Keep in mind, though, that objects do not require this - only value types and strings (guess I should'be mentioned that too, but at the time I didn't think about it). Take this little example:
string s = string.Empty;
Test t = new Test();
privatestaticvoid Foo(string s)
s = "Testing";
privatestaticvoid Foo(Test t)
t.s = "Testing";
s = "This is a test";