http://support.microsoft.com/kb/198642[^] Vasudevan Deepak Kumar Personal Homepage Tech Gossips

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.

I can see why no one responded to your inquiry. The way you phrased it is confusing, even to me, and I read it and then re-read it several times. The basic concept is that you are trying to write a .NET application that will respond to events fired from a COM object that you have imported. While it appears that this should be a simple matter, it is actually confusing as hell. I have a copy of the book, ".NET and COM: The Complete Interoperability Guide", by Adam Nathan, that I have learned an immense amount of 'stuff' from. I would highly recommend it, especially if you do this type of thing alot. He has an entire chapter devoted to the subject, "Responding to COM Events", which is about 50 pages long and describes the techniques clearly and in detail. To be perfectly honest with you, I don't completely understand the matter, and I am reluctant to provide you with confusing information. However, you are working in the right direction. In his book, Adam Nathan describes the callback mechanisms for both .NET and COM, and, while similar, they differ significantly. Basically, he describes the way the type library importer transforms the Source Interface in order to expose the COM object connection points as .NET events using a number of additional types (these are: an event interface, a delegate, a private class that handles interaction with the connection point, and a private sink class that implements the source interface). It is just too much information to adequately describe here. I suggest that you consult his book.

Hi! Thanks alot! Both to Heath and Steven! Will try this first thing monday morning! The Joel on Software text gave som intresting, and fun!, reading. / Mikke

Mikke_x wrote: Yeah, I see what you mean. But I still can´t see the point of beeng able to declare an enum as: enum ints :int {zero, one} if I can´t use it as constant int without convert The explicit cast is a safety mechanism - no matter how good your comments are you are not going to force someone to read them unless they have to. Most people muddle along all through their lives, programmers included. They only tend to look for something if they need to. The compiler forces them to need to. The enum is there to say here is a type that can contain a set of possible values. If you want to assign it to an integer the compiler makes you explicity cast it to an integer (it probably does nothing when compiled - I've never checked the IL for that) because it is ensuring that you are fully aware that what you are doing is stripping off the protective layer that the enum is providing around the underlying int. "You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar The Second EuroCPian Event will be in Brussels on the 4th of September Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way! My Blog

Yeah of course. The problem here was that the process used 99% of the processor all the time. Altough it looked like it had really low priority since it did only use the processor if no other thread wanted to execute. We did resolve the problem however. Can´t really explain the reason behind the problem, but it was because of a sleeping thread. We started a thread when we started the application and suspended it immedediately. Now we have changed it so that we don´t start the thread until we need it instead of starting it and suspend it from the start. M

ok, thank you! I thought it might be like that, but wanted to be sure. I have used a OOD doing the class hierachy and have encapsulated all the important features. Altough some of the functionallity has been placed outside the class because some of components in the application are drawing some graphics om the panel, mainly debug information. Looks like I will have to do some changes in the painting routines then.. / Mikke ( by the way, I think that openGL uses upper right corner too. If I remember correctly, I have not used it in a while.. )

That's correct, so the problem is in your unmanaged code. How is m_Devices declared? What codepage is Windows set up for? Are you using a different codepage for your Console? Also, since your using just printf and not tprintf, this tells me you're not using ASCII on Windows and Unicode on Windows NT (like Auto dictates), so use CharSet.Ansi instead (if this is the case). Like I said before, you should read the documentation, not just expect the exact answer (especially when you don't provide enough details to say for sure). One thing I would warn you about as well is that it's actually a bad idea to return strings from functions. I don't remember all the details (it's been a while since I was hot n' heavy into C/C++), but you should instead declare your function like so: __declspec(dllexport) void GetString(INT i, LPSTR lpszText, DWORD cbText); Also notice my use of INT (declared as int, and it's typically better to use pre-proc defs). The lpszText param is both [in,out], and the cbText ([in]) is the max string length. Without this protection, you open your code up - and potentially your entire system - to buffer overruns (the leading cause of security threats). This signature is common for functions and structs throughout the Windows APIs. Your managed declaration would then look like this (taking into account that is seems you're using ASCII only strings since you're using printf[DllImport("pciDriver.dll", CharSet=CharSet.Ansi)] private static extern void GetString( int i, [In, Out] string lpszText, [MarshalAs(UnmanagedType.U4)] int cbSize);Technically, however, the first param - `i` - should be an `IntPtr`. An `int` in C# refers to `Int32`, which is always 32 bits. An `int` in C/C++ is the width of the processor, so 32 bits on a 32-bit processor and 64 bits on a 64-bit processor (depends on the compiler, really). An `IntPtr` is like that. If you wanted to make your code more portable to other architectures, then change the param type to `IntPtr` and when you pass it, pass it as `new IntPtr(0)` (or whatever index you need). Microsoft MVP, Visual C#[](</x-turndown)