|
I highly doubt that you will find anyone here that will port this to C# for you. Most of us have our own jobs to do. If you are so "new" to C# then why were you assigned to do this? You just might have to do it yourself OR hire someone to do it for you. Are you unable to package this code into a DLL and just P/Invoke it?
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
|
|
|
|
|
This is not even hard, just some type conversions (U16->ushort, U8->byte) and changing pointer access to array access:
ushort GetCrc16(byte[] pData)
{
ushort fcs = 0xffff;
for(int i = 0; i < pData.Length; i++){
fcs = (fcs >> 8) ^ crctab16[(fcs ^ pData[i]) & 0xff];
}
return ~fcs;
}
bool IsCrc16Good(byte[] pData)
{
return GetCrc16(pData) == 0x0f47;
}
You might need to cast to get a ushort back out of the shift and XOR, though.
|
|
|
|
|
Hi,
When I dispose a groupbox do I have to dispose all
of its child controls myself or is this done implicitly?
Tia
|
|
|
|
|
I never found any such information in MSDN, however AFAIK Controls dispose of their children automatically, and I never felt a need to dispose explicitly of one, so why are you disposing of a GroupBox?
|
|
|
|
|
I create a GroupBox with a TableLayoutPanel and readonly TextBoxes in that panel during runtime. I want the GroupBox and its controls to remove itself also at runtime. So I do :
this.Controls.Remove(m_CustomerInfoGrpBx);
m_CustomerInfoGrpBx.Dispose();
Is this enough ?
tia
|
|
|
|
|
when you remove a Control you no longer need, then disposing it is fine. As I said before, I expect all of its content will be disposed of automatically, so don't try and move the GroupBox content onto another Container.
|
|
|
|
|
Maybe it has been bad. It needed a serious lesson.
We should never let groupboxes make the rules.
No memory stick has been harmed during establishment of this signature.
|
|
|
|
|
It happens automatically.
Control.Dispose iterates over all controls it holds, sets their parent to null and then calls their Dispose method.
|
|
|
|
|
As per what I understand, if there are no references to an object on the object tree, it is viable for collection.
So if the child controls are all not referenced by any other object, they will all be collected.
Let the garbage collector take care of this. IMO, you should not worry about either the managed groupbox or any other children controls.
|
|
|
|
|
I disagree. Of course the GC will eventually clean up whatever isn't needed any more, once new objects are needed and it has ran out of memory. However objects that hold big or expensive or unmanaged resources should provide a Dispose() method and that method should be called explicitly as soon as possible. If anything, it will make your app lighter and more responsive.
BTW: I checked using Reflector, and found this snippet burried deep inside Control.Dispose():
ControlCollection controls = (ControlCollection) this.Properties.GetObject(PropControlsCollection);
if (controls != null)
{
for (int i = 0; i < controls.Count; i++)
{
Control control = controls[i];
control.parent = null;
control.Dispose();
}
this.Properties.SetObject(PropControlsCollection, null);
}
base.Dispose(disposing);
If MS finds it necessary to dispose of Controls, why shouldn't you?
|
|
|
|
|
Well....dispose does not guarantee that memory will be freed right?
As far as I understand, the GC is non-determinstic.
I was going through this article - http://www.devx.com/dotnet/Article/33167/0/page/3[^]. According to this Dispose() does not normally free managed memory directly. I had come across similar analysis somewhere else as well.
So I wonder why MS have called Dispose(). Is the author of that article incorrect?
OR perhaps there is some ambiguity regarding this method?
|
|
|
|
|
Abhinav S wrote: the GC is non-determinstic
correct
Abhinav S wrote: this article - http://www.devx.com/dotnet/Article/33167/0/page/3[^]
Haven't read that, and am not going to.
Abhinav S wrote: dispose does not guarantee that memory will be freed
correct.
Dispose is NOT about freeing the memory that holds the object; it is about other things the object may be holding on to. Such as unmanaged system objects (e.g. device contexts), unmanaged memory blocks, etc.
Conclusions:
- Dispose and GC are no alternatives, they complement each other.
- let the GC do its work (and don't interfere with it).
- call Dispose() for objects that have such method.
|
|
|
|
|
Luc Pattyn wrote: Conclusions:
- Dispose and GC are no alternatives, they complement each other.
- let the GC do its work (and don't interfere with it).
- call Dispose() for objects that have such method.
That is correct.
|
|
|
|
|
I think Luc Pattyn nailed the question, however I would like to point out something to avoid confusion.
Managed controls will eventually be handled by the GC. So disposing, though recommenden, is not absolutely necessary, however if you're working with unmanaged controls, make sure you dispose/delete/... in short cleanup everything yourself. Mostly if you're writing that code yourself you do, but, this also counts for unmanaged third party controls and that's often forgotten.
V.
|
|
|
|
|
There have been some interesting answers here, but I'm going to add a little wrinkle in that you may want to consider. What happens if any of the items in your collection have items that have event handlers that are still subscribed to from elsewhere? What do you think will happen to the items in the collection?
|
|
|
|
|
sir when i am running this code then process is throwing an exception ....and value of exit code becoming 1 ....i dont know why it is happening so ..plz help me ..
public void Restore()
{
try
{
string path;
path = filetext.Text;
StreamReader file = new StreamReader(path);
string input = file.ReadToEnd();
file.Close();
ProcessStartInfo psi = new ProcessStartInfo();
psi.FileName = @"C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqlimport";
psi.RedirectStandardInput = true;
psi.RedirectStandardOutput = false;
psi.Arguments = string.Format(@"-u{0} -p{1} -h{2} {3}",userid, paswd, server, comboBox1.Text);
psi.UseShellExecute = false;
Process process = new Process();
process = Process.Start(psi);
process.StandardInput.WriteLine(input);
process.StandardInput.Close();
process.WaitForExit();
process.Close();
MessageBox.Show("database is restored");
}
catch (IOException ex)
{
if (System.Diagnostics.Debugger.IsAttached)
{
Console.WriteLine(ex.ToString());
}
else
MessageBox.Show("Error , unable to Restore!");
}
}
|
|
|
|
|
What exception?
Where?
Please, try to give us all relevant information - help us, to help you!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
when i am debugging the code and reach to process line and right click at process we find lot of exceptions and first is this .....
BasePriority = 'process.BasePriority' threw an exception of type 'System.InvalidOperationException'
|
|
|
|
|
Are you developing on Windows 98?
Windows 98 Platform Note: Setting the priority class to AboveNormal or BelowNormal causes an exception to be thrown.
Bastard Programmer from Hell 
|
|
|
|
|
no sir i am devloping in windows 7 os
|
|
|
|
|
In that case, there are two conditions that can cause an InvalidOperationException (according to the documentation)
The process has exited.
-or-
The process has not started, so there is no process ID.
That's probably why there was an "WaitForInputIdle"; it needs to wait until the process actually started.
Bastard Programmer from Hell
|
|
|
|
|
yes process is exiting actualy its exit code is showing 1.....but i dont know why it is happening which line is to be corected ...so please analyse my code and provide appropriate solution
|
|
|
|
|
altafmohd wrote: but i dont know why it is happening which line is to be corected
Wait until it's done starting before you change it's priority. Take Google and see what "WaitForInputIdle" does, and don't comment lines that are "seemingly" useless.
altafmohd wrote: so please analyse my code and provide appropriate solution
That's what I have done.
Bastard Programmer from Hell
|
|
|
|
|
altafmohd wrote: catch (IOException ex)
{
if (System.Diagnostics.Debugger.IsAttached)
{
Console.WriteLine(ex.ToString());
}
else
MessageBox.Show("Error , unable to Restore!");
}
I object to this catch block: without a debugger, it swallows all available information and leaves no clue as to why the restore failed. Even if your users aren't interested in technical details, you have to support them and will be clueless as soon as the code fails for whatever reason. Write ex.ToString() to the log file!
|
|
|
|
|
but if i am not writing this in catch block then also same problem is coming ..i just posted this in catch block to check what is the problem in my code ...i dont know much about it ....so see the code is it right ?or what could be the problems
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
