You have to name the .config file according to the executable (.exe) naming convention for whatever application instantiates your control. For instance, lets say you want to test you control in the ActiveX Control Test Container (tstcon32.exe). You would put a txtcon32.exe.config file in the same directory as txtcon32.exe. Last time I tried this (some time back) it worked. Give it a try now. The ActiveX Control Test Container would be a good test without having to write a new COM client, too.
I am trying to use remoting to allow a client access to an object that has already been instantiated on a remote server. My thought was that I could create an object that would be offered up by remoting to clients which would have a reference to this already instantiated object, that way clients would be able to get at this variable which contains state information about the program running server-side. However, after reading about remoting from several different sources I am unable to figure out how to actually pass this reference to an existing object into the object that will be offered to the client over remoting.
If anyone can provide me any insight into this subject, I would be greately appreciative.
The window frame is not part of the form and has to be handled differently. In the case of the frame for you main form, you can use an IMessageFilter implementation to get notification of a click:
publicclass Test : Form, IMessageFilter
Test t = new Test();
this.Text = "Test";
bool IMessageFilter.PreFilterMessage(ref Message m)
if (m.Msg == WM_NCLBUTTONDOWN)
MessageBox.Show("You clicked the Window frame");
privateconstint WM_NCLBUTTONDOWN = 0x00a1;
See documentation for the WM_NC* messages for more information about non-client notification messages that you can handle in an IMessageFilter implementation.
I'm curious as to what kind of market penetration C# has achieved in the freeware/shareware/hobby-ware application segment. It seems that virtually everything that you see on sites like Download.com are still written in Visual C++ or VB. Am I wrong about that, or has C# been embraced by developers and users of this classification of applications and utilities?
I'm not too surprised, honestly. I see the same thing. The main reason, I believe (based on feedback and community involvement), is that .NET application require the 20+ MB runtime to be installed in order to run (and sometimes even install if Installer derivatives are used as Custom Actions in an MSI). For free/shareware, this is too much of a burden on would-be users (after all, why download crap...er, helpful utilities when it requires such a heft download or such large prereq's).
Another reason - though this is greatly generalized and is not even based on a stereotype - is that some free/shareware developers aren't what you'd call "up-to-date" and can't find tech jobs, so they use what (little) they know. I might get flamed for this (and remember to those who are considering flaming me that I said some), but after looking at betanews.com every once in a while I see a lot of examples that support what I said (butdon't get me wrong, there are a lot of good programs posted there, including some from Microsoft and other large companies).
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.