I recently had a similar problem and gained some speed with a 2 step change: parallelize the

foreach (string f in files)

and then ditch the file streaming in favor of File.ReadAllLines(...). Basically the disk was my bottleneck and it performed better doing a bulk reads of data instead of streaming line by line; after each bulk read I had a chunk of data in memory that I could process bound only by the limitations of my CPU. This does, of course, assume that you have some memory to spare because you're reading entire files in at a time. There was also a limit though as to how many concurrent file reads I could throw at my disk, after a certain amount the performance dropped significantly so I had to throttle back how many parallel file reads my app could do. I did some trial and error to find the best number, YMMV. That would also require you to redo your database access though since you probably don't want to be doing that from multiple threads, but that kind of goes along with some of the other suggestions you've received. Collecting that data in memory and do a bulk insert later on instead of individual inserts would make a big difference, too.

:badger:

Glad to help :)

:badger:

Using a switch or creating a different method for each node are valid ways to do it. My preferred method in this case would be to use the Tag property of each TreeNode to store a List of ToolStripItems that should be enabled when that node is selected. When the nodes are created (or in the form constructor, whichever is applicable) initialize the Lists. Then in the selection change handler disable everything, then cycle through the list of ToolStripItems for the selected node and re-enable each one. Like this:

internal MyConstructor()
{
// init the list of items for root node 1
List<ToolStripItem> items = new List<ToolStripItem>();
items.Add(newItemButton);
items.Add(editButton);
// add the rest of the items that should be enabled
rootNode1.Tag = items;

// init the list of items for root node 2
items = new List<ToolStripItem>();
items.Add(deleteItemButton);
items.Add(crashTheComputerButton);
// add the rest of the items that should be enabled
rootNode2.Tag = items;

// init the list of items for etc
// . . .

}

private void mainTreeView_AfterSelect(object sender, TreeViewEventArgs e)
{
if (mainTreeView.SelectedNode == null) return; // No selection

TreeNode selectedNode = mainTreeView.SelectedNode;

foreach(ToolStripItem item in /\* the entire collection of toggle-able ToolStripItems \*/)
{
	item.Enabled = false;
}

List<ToolStripItem> applicableItems = selectedNode.Tag as List<ToolStripItem>;
if (applicableItems == null)
{
	return;
}

foreach(ToolStripItem item in applicableItems)
{
	item.Enabled = true;
}

}

:badger:

jschell wrote:

there is no way to ensure that an action in thread 1 will only occur at point x in thread 2

:confused: What do you mean? That's what Monitors, Mutexes, (Manual/Auto)ResetEvents, etc. are for. The other example I posted demonstrates this using locks. Inside the receive callback the thread waits on the state object until no other thread is in a critical section using the socket. Likewise the Close method waits on the same object until all other threads have left their critical sections that use the socket.

:badger:

Glad to help :) I know you didn't ask for it, but I refactored your snippet into a thread-safe, error handling version as an exercise. I haven't actually run it, but I believe it'll work for you (or at least be close) given that the state object passed as the last parameter to BeginRecieve is _recvState:

private static void ReceiveCallback(IAsyncResult ar)
{
// End Receive
StateObject stateObject = (StateObject)ar.AsyncState;

if (stateObject == null)
{
    return;
}

lock (stateObject)
{
    if (stateObject.Socket == null)
    {
        // done!
        return;
    }

    int bytesReceived = 0;

    try
    {
        bytesReceived = stateObject.Socket.EndReceive(ar);
    }
    catch (SocketException)
    {
        // non-recoverable
        return;
    }
    catch (ObjectDisposedException)
    {
        // non-recoverable
        return;
    }

    if (bytesReceived > 0)
    {
        // Parse Data
        SocketConnection.ParseReceiveBuffer(stateObject);
    }

    // Begin Receive
    stateObject.Socket.BeginReceive(stateObject.DataBuffer, 0, stateObject.BufferSize, 0, new AsyncCallback(ReceiveCallback), stateObject);
}

}

public void CloseConnections()
{
// Receive
lock(_recvState)
{
if (_recvSocket != null)
{
_recvSocket.Shutdown(SocketShutdown.Both);
_recvSocket.Close();
_recvSocket = null;
_recvState.Socket = null; // setting this to null will signify that we've closed the connection
_recvState = null; // don't reset this to null, if we do then we can't lock on it without first checking it
}
}

// then something similar for sending . . 

}

Actually I have to thank you, your original post caused me to go back into some old code and re-look at my own async socket class. Have you ever gone back and looked at something you wrote a long time ago and wondered what was going through your mind when you originally wrote it? I just had one of those moments. It's time for some bug fixing! :)

:badger:

When you close a Socket I believe any pending asynchronous callbacks are fired to terminate said callbacks. It's by design so it's something you need to handle in your code. When you call EndReceive (or EndAnything for that matter) it can can throw any number of exceptions to indicate failures from the pending operation so those methods should always be wrapped in a try {} catch (stuff) {} block. Basically, anything the synchronous versions of the methods can throw, the asynchronous ones can throw too with some extra ones for good measure. Catching those exceptions is one way that your code could know that it should exit from the callback without initiating another async method call. Another way would be to check a flag in the receive callback that is set in CloseConnections to indicate that work is done. It also looks like you might be being bit by a lack of thread safety. Async callbacks are executed on Threadpool threads so it's a good bet that CloseConnections and the receive callback are racing to use the socket at the same time. A simple lock(_recvState) { /* use the shared resources here */ } around places where the shared resource are used will be sufficient to protect them.

:badger:

You're welcome :)

:badger:

This is the pattern I'm familiar with (in pseudocode):

Socket socket;
Queue<Data> pendingData;
bool sending;

public void SendAsync (Data data)
{
if (sending)
{
pendingData.Add(data);
}
else
{
sending = true;
socket.BeginSend(data, new Callback(SendCallback));
}
}

private void SendCallback ()
{
socket.EndSend();

if (pendingData.Count > 0)
{		
    socket.BeginSend(pendingData.DequeueReasonableAmountOfData(), new Callback(SendCallback));
}
else
{
    sending = false;
}

}

This maintains only one outstanding asynchronous send operation at a time and the amount of data queued to be sent can easily be handled by user code. This is useful in case the queued data needs to be resent if the client disconnects/reconnects, or if you want to put a limit on how much data to queue to send or perhaps prioritize the queued data in some way. Of course another important part would be to make sure the receiver is receiving in such a way that parsing the data isn't blocking the socket from immediately receiving the next packet being sent.

:badger:

It really doesn't matter if it's in or out of VS when it's running, if an app is throwing invalid cross-thread operation exceptions then it's not observing the "One GUI Thread" rule. The only reliable way to do so is to use the IvokeRequired/Invoke/BeginInvoke members of the Control class.

:badger:

UI elements must be accessed on only the GUI thread. The Control class provides the Invoke/BeginInvoke methods to do this. See here[^] for a reference.

:badger:

This is bad advice; it won't solve any problems, only mask them for a little while. The docs[^] state that illegal cross thread calls will throw exceptions when run outside of the debugger no matter what you do. The correct way to perform cross thread UI operations is to invoke the operation on the GUI thread. See here[^].

:badger:

HTTP stuff is contained in the System.Net[^] namespace. The WebRequest[^] class example demonstrates a typical usage scenario.

:badger:

OK, so loop through the rows again until you find the one where the account name matches what they entered in the TextBox and then grab the ID from that row. If you want to get fancy about how you do it then you could probably do it using Linq but looping and searching will work just fine.

:badger:

Set the TextBox's AutoCompleteMode, AutoCompleteSource and AutoCompleteCustomSource Properties to appropriate values depending on what exact behavior you wish it to have. MSDN[^]

:badger:

something like this:

abstract class BaseClass
{
protected static readonly Icon BaseIcon = new Icon("...");

public abstract Icon DisplayIcon
{
    get;
}

}

class ChildClassOne : BaseClass
{
static readonly Icon ChildIcon = new Icon("...");

public override Icon  DisplayIcon
{
    get { return ChildClassOne.ChildIcon; }
}

}

class ChildClassTwo : BaseClass
{
public override Icon DisplayIcon
{
get { return BaseClass.BaseIcon; }
}
}

:badger:

Are your COM objects being cleaned up properly? You need to use Marshal.ReleaseComObject to release all of the resources that are allocated when using the Excel interop classes. See this[^] thread for details (code is in C# but same principal applies).

r_mohd wrote:

it is working very fine, but

Thanks, it always makes me chuckle when people say "It works fine but . . .". If there's a but then it isn't working fine, is it? :-D

:badger:

SOA describes any architecture that allows one component to request another component to do some operation. For an example let's say that you work for an online retailer and you've been asked to write something to allow different parts of the existing software system to generate several types of sales reports - one report for the marketing department, one for the shipping department, one for the tax collectors, etc. The underlying service that the solution is oriented around here is the generation of a report. Using web services for SOA you would write a web service that has a web method that clients can call to create reports. Any client can call the method, the method creates the report and does whatever it needs to do with it. You could also use a Windows Service. All you have to do is create a way for clients to request that the service generate the report that it wants and for this any form of IPC could be used. Sockets, MSMQ, Named Pipes, .Net Remoting or WCF would all allow other clients to get a message to the service to ask it to generate a report. The basic gist of SOA is [component A -> requests a service to be performed by -> component B]. What component A and B are aren't important and neither is how A requests B to do something. What makes it SOA is the design not what technologies are used.

:badger:

Member 4487083 wrote:

only testing public members

I'm not saying don't test them, I'm saying don't call them directly to test them. To test the private method in my example I'd write test cases that started with the public method and manipulate the inputs in order to fully exercise the private one.

Member 4487083 wrote:

a unit eg. a single method

I'd call a unit a class, not a method or a property. When I link to a third party DLL to import some functionality, I'm importing the classes not individual methods.

Member 4487083 wrote:

which may include using things in a way that they weren't necessarily supposed to be used

Of course, but I always honor the contract of the classes that I'm testing. If a class has a method that takes a string parameter I'll throw everything I can think of into that parameter to stress the method but if you go outside the contract then what are you testing? If something is private then it's not supposed to be accessible by anything other than things internal to the class so it should be tested only by way of things internal to the class.

Member 4487083 wrote:

Dead code is potentially a bug waiting to happen IMHO

I agree completely.

Member 4487083 wrote:

it may be worth making a few modifications for testing

I agree almost completely. Testability is something that can/should be built in so that no modifications are required to do it. The connection string is a good example. Ideally those should be built to be configurable from the beginning - it shouldn't have to be added on later just to accommodate testing. Still, this is something completely different from changing the accessibility level of members to facilitate testing. Making something configurable is an enhancement that promotes flexibility and testability; making something unnecessarily public makes it more testable but introduces security risks. More to the point, making a connecting string configurable doesn't change the contract of the class but changing something from private to public does.

:badger:

I would never change a private method to public or anything else for testing. I'd always test it through calls to the public[1] members of the class because that's the way that they were designed to be used. If you make them public and test them directly then you have access to them in ways that the other classes and modules don't and you can stress them in ways that won't be possible once deployed. When unit testing a class I access it only in ways it was designed to be used and if code private that means that it was not designed to be used by anything other than the other code in the class. Take the following class:

public class TestClass
{
private void PrivateMethod(bool someBool)
{
if (someBool)
{
// do something
Console.WriteLine("Reachable Code");
}
else
{
// do something else
Console.WriteLine("Dead Code");
}
}

public void PublicMethod(double x)
{
	// do some stuff
	
	// Here we're going to do some calculation with the input and use the result to determine what to pass 
	// PrivateMethod(...).   I'm using Math.Abs just as an example.
	double calculationResult = Math.Abs(x);  
	
	PrivateMethod (calculationResult >= 0.0);
	
	// do some more stuff
}

}

The private method has different behavior based on its parameters. If you make that public and test it directly then you can stress both cases but that's not how the code was designed! If you examine the code you'll see that the only place it's called from is from the one public method and that method will always pass it a value of true. What this means is that private method doesn't need to have different behaviors, it doesn't need to check its input and it doesn't even need any input parameters. The parameter, if statement and else block are all dead code and should be removed. At least this is what it looks like at first glance; what if the fact that the method can only be passed one value a bug? What if the calculation is wrong? If you make the private method public just for the sake of testing then this question might never be asked. Granted, this is a contrived example that shows a minor inefficiency but it highlights how easy it is to hide bugs private code if you tweak for testing. If you have a class where everything is private then what's the point of the class? If you have private code that isn't callable in one way or another from any public methods then what's the point of the code? If code can't

Using asynchronous methods and a timer is pretty much how you do it. If you aren't happy with that then you could create a wrapper class that hides all of the details and offers a Connect(address, port, timeout) method to make things easier for yourself.

:badger: