Re: method conversion from C to C# - C# Discussion Boards

14-Oct-08 22:45

Hi all,

I have the following method that was wriiten in C. The method makes use of a MarshallSoft method called: cscGetData(vSock, Buffer, BufLen). I am trying to rewrite the method in C#. Here is some info about the cscGetData method:

The cscGetData function is used to receive data from an established connection. All available data is copies to 'Buffer' up to a maximum of 'BufLen'. cscGetData never waits for data.

So the problem is that the C# method does not work. What am I doing wrong ... Confused | :confused:

C version of GetData Method

// calling method
Code = GetData(i, DataSock, (char *)gConnectData[i].Request, STRING_SIZE);

// GetData Method
int GetData(int Connect,int Sock, char *Buffer, int BufLen)
{int Code;
 Code = cscGetData(Sock, Buffer, BufLen);
 if(Code<0)
   {DisplayError(Connect, Code, (char *)"cscGetData:");
    gConnectData[Connect].ConnectState = STATE_FINI;
   }
 return Code;
}

C# version of GetData Method

// calling method ????
Code = TcpServer.GetData(i, TcpServer.ListenSocket, TcpServer.connectData[i].Request, 128);

// GetData Method ????    
unsafe static public int GetData(int Connect, int Sock, string Buffer, int BufLen)
{
	int Code;
	char[] BufferString = Buffer.ToCharArray();
	fixed (char* pBuffer = BufferString)
	{
		cscShortToByte(pBuffer);
	}
	fixed (char* pBuffer = BufferString)
	{
		Code = cscGetData(Sock, pBuffer, BufLen);
		if (Code < 0)
		{
			connectData[Connect].ConnectState = (int)STATE.STATE_FINI;
		}
	}
	return Code;
}

Many thanks in advance
Kind regards,

The only programmers that are better those C# programmers are those who code in 1's and 0's Green Alien | [Alien]

Programm3r
My Blog: ^_^

Guffa14-Oct-08 23:21

Guffa

14-Oct-08 23:21

A char in C corresponds to a byte in C#.

A char in C# is a 16-bit unicode character.

Despite everything, the person most likely to be fooling you next is yourself.

Programm3r14-Oct-08 23:36

14-Oct-08 23:36

Hi,

Thanks for your response. I do not wish to sound ungrateful, but what does this have to do with the methods?

Kind regards,

The only programmers that are better those C# programmers are those who code in 1's and 0's Green Alien | [Alien]

Programm3r
My Blog: ^_^

Guffa15-Oct-08 2:07

Guffa

15-Oct-08 2:07

You are declaring an array of characters, and the method is writing to it as if it was an array of bytes. You are putting the wrong data type in the array, so you are only using it as a dumb memory area.

Declare an array of bytes instead, then you don't need the marshalling method in an unsafe code block to read the char array as a byte array. You can use a regular Encoding.Default.GetString call.

Also, you are changing the contents of a string, which is a big no-no. Strings are immutable, and all code that uses strings rely on that.

Despite everything, the person most likely to be fooling you next is yourself.

Programm3r15-Oct-08 2:35

15-Oct-08 2:35

Thanks for the response.

The only programmers that are better those C# programmers are those who code in 1's and 0's Green Alien | [Alien]

Programm3r
My Blog: ^_^

Programm3r14-Oct-08 23:56

14-Oct-08 23:56

So this does the job:

// call method
Code = TcpServer.GetData(i, TcpServer.ListenSocket, ref TcpServer.connectData[i].Request, 128);

// Method in C#
unsafe static public int GetData(int Connect, int Sock, ref string Buffer, int BufLen)
{
	int Code;
	fixed (char* pBuffer = Buffer)
	{
		Code = cscGetData(Sock, pBuffer, BufLen);                
		if (Code < 0)
		{
			connectData[Connect].ConnectState = (int)STATE.STATE_FINI;
		}
		Buffer = Marshal.PtrToStringAnsi((IntPtr)(char*)pBuffer);

	}            
	return Code;
}

Regards,

The only programmers that are better those C# programmers are those who code in 1's and 0's Green Alien | [Alien]

Programm3r
My Blog: ^_^

Dave Doknjas15-Oct-08 13:38

Dave Doknjas

15-Oct-08 13:38

If you don't want to convert to 'unsafe' code, then the following might do (produced by C++ to C# Converter):

// calling method
private void test()
{
Code = GetData(i, DataSock, ref (string)gConnectData[i].Request, STRING_SIZE);
}

// GetData Method
private int GetData(int Connect, int Sock, ref string Buffer, int BufLen)
{
int Code;
Code = cscGetData(Sock, Buffer, BufLen);
if(Code < 0)
{
DisplayError(Connect, Code, (string)"cscGetData:");
gConnectData[Connect].ConnectState = STATE_FINI;
}
return Code;
}

David Anton
http://www.tangiblesoftwaresolutions.com
C++ to C# Converter
C++ to VB Converter
C++ to Java Converter
VB & C# to Java Converter
Java to VB & C# Converter
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: convert VB, C#, or Java to C++/CLI

Unregistering Events

Member 419713614-Oct-08 22:25

Member 4197136

14-Oct-08 22:25

Hello,

Lets say I have a class that exposes event. In which cases do I need to unregister event so that I don't get memory leak? As far as I know if I have a form and I handle form events in the same class there is no need to unregister event myself. But if I attach event handler to form's event then I have to unregister it manually. So, in general when should I unregister event handlers?

Also, if I am developing a class that provides an event and implenets IDisposable, should I unregister attached event handlers in Dispose method?

Thanks.

Eduard Keilholz14-Oct-08 22:39

Eduard Keilholz

14-Oct-08 22:39

You simply unregister for an event if you don't want to respond to that event anymore, however you want to keep the object which fires the event intact.

If that object implements the IDisposable interface, and you call the dispose method() you obviously don't need the object anymore. You don't need to unregister events here...

A good example, I have an object which downloads files from the internet. This proces runs on the background. However, when the user opens a dialog box which displays download progress, I register to a DownloadProgressChanged event, and unregister for the event when that dialog closes. The object which performs the download must stay intact.

.: I love it when a plan comes together :.
http://www.zonderpunt.nl

Simon P Stevens14-Oct-08 22:47

Simon P Stevens

14-Oct-08 22:47

When you attach to an event handler, the class that has the event (Lets call it class A - the source), holds a reference to the class that handles it (Lets call it class B - the listner).

This means, that if that class A goes out of scope and is ready to be garbage collected the reference that A holds to class B is also out of scope, so nothing to worry about.

If on the other hand, class B goes out of scope, and you want it released, it won't be. A still has a reference to it, so B will never be released while A is still in scope.

In the case of things like forms and UI controls, you generally don't need to worry. The code handling the events is needed until the controls are finished with, then it's all released together.

The times you need to worry about it is when you have a class that you want to respond to events (The listener) for a little bit, and then get rid of the class while the class with the event (the source) stays alive for longer.

There's lots of different ways of handling this case. This article[^] will get you started if you do need to do it.

Simon

Member 419713614-Oct-08 23:35

Member 4197136

14-Oct-08 23:35

Thanks for reply.
Let's say I have a Form which uses BackGroundWorker for some work. Do I need to unregister BackGroundWorker events when I no longer need it? So that when the form is closed backgroundworker doesn't reference the form. Or will they get out of scope at the same time and there is no need for unregistering? Generally, if a Form stores an instance of class that provides an event do I need to unregister events?

Thanks again.

Simon P Stevens15-Oct-08 0:38

Simon P Stevens

15-Oct-08 0:38

You have a form and a background worker. The background worker is the source, and I'm assuming the listener is the form. So the background worker has a reference to the form.

When the form is closed, the background worker goes out of scope, so it's reference to the form goes out of scope, so everything is fine.

(Background workers do require disposing though. If you don't dispose of them you will have other problems)

Generally, no, in these cases you are all right. Just watch out for when you have a source that you want to exist for longer than your listener.

Remember that the listener (in this case the form) cannot be released until after the source (the background worker) is released. In this case you are fine because you want to release both at the same time, so it will be ok.

Simon