You mention using a for loop - I'm not sure you need one for a smooth motion (or you have might not fully understand the timer object). Set up a timer and have an Event handler that responds to the Tick event of your timer. That should give you a smooth motion. Once you reach the motion limit, stop the timer. Hope that helps - if not, I may have misunderstood the problem.

Hi Hansjörg, I'm not sure what computationally intensive operations you are attempting to perform but there are a number of ways of improving the performance of your application and it all depends on the specifics of what you are doing as to the best way of breaking it down. I struggled for performance on my final year project (which was analysing webcam pictures in real time). I considered the possibility of writing the core in C++ and calling a library but in the end I decided I couldn't be bothered to do that and simply used an unsafe { } block within C# to give me my pointers back so I could analyse the bitmap at the byte data level. That worked fantastically to give me the performance I needed (it might even have been better than calling a dll library function since I wasn't consistantly making external library calls). Other options are adding threading to your app, using a C++ service running on the same machine and communicating with that over remoting calls (this is not a particularl safe or uncomplex option, but if you really don't want to use dlls it could be a work around). I'm assuming your interface will already be on a seperate thread in the .Net app so it doesn't freeze and you can do you computation in the background but let us all know if that isn't the case as it may affect your outlook on the whole thing. Best Regards, Adam

I did consider the use of interfaces to get round the problem, but unfortunately XmlSerialisation will still stumble on the main issue that I'm trying to store a list of EmailProcessors that would all have different types. The only way I came upon to get round this was to cast down to an actual instance of the parent type to store my setting and use a string within the parent type to allow me to cast back up to the appropriate child type after serialisation once the plugin is running. Is there a more correct solution or is this the only way round the dynamic typing issue caused by an XmlSerialisation process that I can't modify? Thanks very much for taking the time to respond - it is appreciated. Cheers, Adam

Hi Joseph, Thanks very much for the response, but unfortunately (as was mentioned in my original request but perhaps could have been made clearer) the plugin architecture is already in place as part of an application that is already live on a number of systems. The only reason for mentioning the plugin architecture is actually to define the constraint the my settings must be stored using XmlSerialisation, which is what causes my problem in implementing a proper inheritance model. Thanks for your help, I appreciate you taking the time to respond.

Hello guys and girls, I've got a generic architecture best principals question for you I as hoping people could give me some pointers on (or at least, generate some discussion over). The issue I've just encountered is as follows: I'm generating a plugin for a service. My plugin will be compiled as a stand alone dll and called from an application. There are two stages of execution for the plugin: 1. Set up as part of a winforms application, then 2) execution as part of a windows service. In generating the setup information I specify a list of types of "Email Processor" class to use, where EmailProcessor is an abstract class and each type of email processor extends that abstract class to create in instance class. In saving the settings, the list of EmailProcessors was to be saved using XmlSerialisation (this is functionality of the parent application and not my plugin), which throws an error since the type of the EmailProcessor is dynamic. I can't implement any sort of custom XmlSerialisation so I have had to make the abstract EmailProcessor class into a real (non-abstract) class and then throw a NotImplementedException from each of its methods. This has obviously broken the basic inheritance model slightly - not so much as to be truly irritating but enough to make me think there was probably a more correct way of approaching the issue. Can anyone suggest to me what I should have done to allow EmailProcessors to maintain their inheritance model but overcome the issues I had with getting round the XmlSerialisation of dynamic types that I had no control over? Any thoughts greatly appreciated. Cheers, Adam

I learned C# in order to do my final year project - very rewarding. My project was a webcam security camera - to be implemented in whatever fashion or means I saw fit. Other interesting ideas for projects I've heard along the way: Nanite simulator (how would they communicate, create large scale structures with simple instructions) Remote control helicopter controller (you might need an expensive toy for that one though) Any of those are feasible projects and should give you plenty to study, write about and actually implement - there's a lot of real world and computer science theory to be studied and learned in the implementation of any of them

Bear in mind, he's asking for "ideas" rather than solutions. What's to say there's no creative process in being given an idea, or even just a title, and running with that to make it your own. I was given a title for my project of "A webcam security camera". Rest assured that although I was given the title, I consider the entire creative process to be my own since the method I used and the approach I took was certainly not what would be expected from the title. Also, the project itself is to create a solution. As a student it's incredibly hard to find a problem to solve if you have no starting point, but that isn't really the intended technical challenge of doing a computer science degree now is it? Mostly it's the people doing day to day work in the field that will have ideas for really interesting personal projects that would be possible with todays tech, but won't have the time to actually do them.

Why not simply maintain a moving cache of the last N entries you iterated through? e.g foreach (string x in y) { /* operations here */ string previousx = x; }

You seem to be inferring that each instance of a table adapter stores the data from the table in the application. Are you certain this is correct as I assumed that data was only retrieved once the Select function of a table adapter was called in order to fill a data table object? (It is possible that my orginal message was not clear enough and you thought I was referring to data table objects rather than table adapters) I always assumed that table adapters stored connection details for the appropriate database object - these are the resources I was hoping to find out about so that I can ensure my application is not leaving connections open inappropriately or unnecessarily hammering the database.

Hello, I was hoping someone could give me a bit of information on the way I should be creating / handling my table adapters. I have a persistant business object that is managing a number of database calls using a lot of different table adapters. The question I have is what the best practice is for creation of these table adapters. Is it better to persist a reference to each of my different table adapters over the life of my business object (i.e. create them all once, store them in class variables, then dispose of them all at the end) or is it better to create them as they are required (i.e a new table adapter created for each function call). If someone could give a bit of an insight into what a table adapter is doing in terms of the connections created for it during instantiation that would be most helpful in helping me decide the most efficient approach. Thanks for your help, Adam

Thanks for the response Led, I've been having a much more thorough look into using remoting today and came across this MSDN article that pretty much answers my question: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch16.asp There's an architecture section at the end that shows the reasons for the different selections to be made. Best Regagrds, Adam

Hello, I haven't posted on here but before but I've been a reader for a while. I've just switched jobs and taken up the role of developer so I was hoping you good people could give me a bit of advice on the best way to go about designing a solution. I have been given an existing application that runs as a windows service. Currently, this application simply provides a wrapper to control some telephony hardware, managing messaging queues, that sort of thing. It returns some real time information such as delivery reports and failure reports and currently there are only limited options to interact with it (text file input directories or direct database interaction, neither of which are ideal). The service can be extended using the api to write service extension dlls. Here's what I need to do. I want to create an interface to the service so that I can have a heavyweight local winforms UI manage it, as well as allowing a very limited web interface to interact with it eventually (though that is not the priority). I want the level of access allowed to the winforms UI to be much greater than that allowed by web interface later on. Here's the question - what's the best practice for exposing my service. Do I extend it with a web service and simply have different levels of functionality available on different ports, then communicate with my local service as if it was a remote service from my winform application? (I'm a little worried about whether this will provide the appropriate level of real time event handling). Or is there a better way of approaching this and exposing my windows service to a local winform UI? Also, are any of the relatively recently released Application Blocks or Software Factories applicable to this development? I noted the web service factory has just come out and might be worth a look. Any help and advice appreciated. Thanks, Adam