There is an design paradox here: To have this event, you need to click the buttom which forces the focus onto the button. If it was anywhere else, you wouldn't be able to click the button. You don't want things stealing focus while doing various operations (like clicking, drag-and-drop, etc) anyway. You should consider another UI design instead of trying to have focus jump around on the form while performing user input.

That isn't an error. That is how you "run" the Web Service. If you still believe this is an error please give more information.

Delegate/Events are more or less like an array of references to methods in objects. Overloading seeks to slightly alter, in a way customize, behavior for implemented objects. They are really different methods exhibiting different behavior. Although you can similate overriding with events but one should really avoid it. Likewise, you can similate events using virtual behavior as well but again you should avoid it.

Your problem is you are interpting the "normal data" to mean "string" which if it is in the form of Html *is not* string at all. After all, this page is all Html and it has far more stuff than just "string". So what is it that you are really after? If you just want to do raw text processing you might want to look at WebRequest/WebResponse instead.

It is possible to set a break point at the bottom of your main on Closing for the main form. Or if worse comes to worse, create a temporary button that behaves like "Quit" with your break point there.

The virtual machine implementations of C# and Perl are radically different so calling methods between "byte codes" is almost impossible. You can however do a SOAP proxy like that to do interprocess communications at that level if the lower level IPC is too low.

What do you mean "it does not update the datasource"? Have you inspected the DataSet with the debugger to see if the data has truly been changed and therefore needs to sync against the source? A common problem I see is that someone mishandles validation, transfer, etc where they think the input changed the data but in actuality it ignored or threw it out. If dataSet11 never changed, as far as the system is concerned there is nothing to update.

The problem is that in the C# treats const much more "seriously" than C++. In fact a problem common in C++ code is accidently casting away something const by shifting to a reference. Look at the behavior of the keyword sealed. `sealed` can protect a lot of things from having the inheritor from overriding, modifying, etc base class behavior.

The C# compiler does not provide support for this construct which was dubious in C++ anyway.

Assuming your "dll" is really a .Net Assembly it is entirely possible with Reflection. Just take a look at the System.Reflection namespace. You can load an assembly and call methods or create objects or whatever on the assembly. It isn't for the faint of heart because it involves some advanced topic but what you want is entirely doable in all version of the .Net.

Considering that those "other applications" may want to change the cursor for various UI hints and reasons, why would your cursor overide their cursor?? In general it is not good usibility alter cursors outside of your application. If you want to change a cursor for all applications use a theme.

If the object represents a truly limited resource, it should implement IDisposable and then one would call `object.Dispose()` when they are done with it. If it isn't a limited resource that needs active maintaince then let the system handle it by normal garbage collection.

What do you mean "execute a program written in DotNET ?"? Did you write this program yourself? What compiler are you using?? Use ildasm first to make sure you have a valid .Net Assembly let alone something that is runable.

How could this possibly work? Embedding the JIT IL runtime in a binary is one thing. Embedding the whole of the .Net Framework (there is a reason why its a multiple MB install, there is a lot of stuff in it) is something different. In any event, yes there are tools out there that try to sidestep the .Net Framework through runtime tricks but in general you have to ask yourself why do you want to this? Maybe C# isn't the best tool for your problem since you can't/don't/whatever use the .Net Framework.

No problem here. Might be some configuration issue like some of your extensions (which is why I never use them).

Can you be more descriptive on what "it seems not to be the right thing" means? Keep in mind these are just access level permissions. NTFS will have another level that will alter the behavior.

You know, I would almost recommend writing that kind of manipulation into the database itself instead of trying to pull it to the client to reinterpt. Or if you are doing more of a report kind of thing you might want to look into making the database return Xml so you can apply an Xslt. Or heck why not look into buying any number of the software advertised here to do this kind of thing.

What do you mean "I want to convert it to code"? If you want to dynamically create objects and methods in IL on the fly it is possible but far from a trivial task. I would also suggest that allowing your application to blindly execute instructions from any data source is a best a bad design pattern and at worst a huge security risk.

Consider what is happening when you "sign up" for the event. You need to send a message to the server object to add ClientObject.ClientFunction to the delegate list. Assuming ClientObject is a MarshalByRefObject, it can marshal "itself" across. It can also marshal strings across. So technically it will succeed in making the functional call across the .Net Remoting. The problem is that it is meaningless to the server app domain because of all of the stuff I meantioned before. All of the object references only work in the client domain and will "blow up" if used in server domain. Oh yeah, I did mention a way to work around the limitation in .Net Remoting but it might not be clear without an example:

ObjectA CallRemoteB()
{
/* old bad way
b.ValueChanged += ValueChangeDelegate();
b.Call();
*/
// better way: sometime earlier the object signed up for the delegate like so
// this.ValueChanged += new ValueChangedDelegate(this.onValueChanged());
b.Call();
if(this.ValueChanged != null)
this.ValueChanged();
}

The event/delegate is now only in the client app domain so everything works.

Events conceptually are not sound in any network protocol. I'm surprised there was even an attempt in .Net Remoting to support this. The exception you are seeing is somewhat indicitive of the general problem. I wish that future versions of .Net Remoting would throw a more accurate exception than ArgumentException you often see in this case. Okay so what is the problem? Mechanically, it can't serialize the delegate and event cleanly across .Net Remoting. Seriously, how would .Net Remoting even begin to handle an delegates/events? Ignore the actual mechanical problems with serialization for a moment and look at the concept you are trying to do. Bare with my crude ascii art :)

+--------------------------------------------+ +-------------------+

• Client + + Server +

•                                        +                  +                   +
  

• ObjectA CallRemoteB() + ---------------->+ ObjectB Call() +
• { + + { +
• b.ValueChanged += ValueChangeDelegate(); + + DoSomeStuff(); +
• b.Call(); + err??? <--------+ ValueChanged(); +
• } + + } +
  +--------------------------------------------- +-------------------+

Remember that the client and server are for all purposes are in two seperate application domains let alone two different processes let a lone two different machines. If you don't understand why marshalling events across seperate app domains is tricky then read on. :) The client is making a call b.Call which is remoted and marshalled correctly over to the server. If you don't do anything fancy, it is going to be syncronous and therefore block and wait for the response from the server. Over on the server, it is going to do the ObjectB.Call method when it makes an attempt to do the event. Okay, how does the server contact the client?? If you can't come up with a good answer then you see why events are a problem in Remoting. :) Neither application domain knows what state the other is in. Even if the client is making an asycronous remote call, the client would have to *stop* execution on whatever it is doing and do the event. The client side is either blocked waiting for a response or the client