jss3426

i have a c# activex control hosted by unmanaged code.

The unamanged code upon instatiating my activex control calls a method SetUsers() for all users it finds in the database so say the db contains 100 users, the unamanged code calls SetUsers() a 100 times, api design not set by me as i cannot control nor inform the unmanaged code as to if i have completely set all my internal methods before accepting information via setusers() call.

so while the unmanaged code is calling SetUsers(), my activex control has to wait and then perform its init routine. Should i thread the SetUsers() call so that my activex control can perform its internal settings and then when SetUsers() is done it can then act on the data, 100 users information, set via SetUsers() call.



Re: Visual C# General should i thread this?

Stefan Van Reeth

Some more detailed information would be handy. But generally, if a procedure hogs up the main program, it's always a good candidate for threading. That way the user can still interact with the application, even if they can only watch a progressbar filling up or cancel the thing. Still that's better than an app that freezes for a few seconds.

Nobody likes waiting, but an app that becomes unresponsive is even worse. Personally I'd thread it anyway. Any connection to a database is a process that can easely go wrong. If you don't detect that early on, the user keeps on waiting for getting back control. Connection timeouts can be quite lengthy, so... yeah, thread it.




Re: Visual C# General should i thread this?

Peter Ritchie

Largely it depends on what SetUsers does. If it's doing anything with the GUI then it's a bad idea to do that in a background thread. If it's interacting with a database you may have to deal with data synchronization issues (depending on the database); but it sounds like you won't, if the work done in a background thread is doing something with 100 users synchronously (sequentially).




Re: Visual C# General should i thread this?

Stefan Van Reeth

Off course you're right on this, Peter:

Largely it depends on what SetUsers does. If it's doing anything with the GUI then it's a bad idea to do that in a background thread.

Then again, I'm so used to coding different classes for achieving different goals, that I never stood still by this. The way I develop things, this won't be an issue ever. In my apps I would never tolerate a datahandler which also directly interacts with a specific form. Those are two entirely different things, so they deserve each their own class.

In fact, I always try to make my code as reusable as possible. That way I'm constantly enlarging my personal library of solutions already explored, without ever pondering over them again. I find this the most practical way to do things, especially since it doesn't make an app code more difficult to understand, on the contrary. Performance doesn't get hurt if one learns to identify what should be static. In time it speeds up development, because I just have to add a class to do the things I want, instead of writing a similiar things over and over again. I admit that designing such classes does cost time initially, but I gain that back every time I reuse them.

So handling datasets and working on a form from one piece of code, is a definite no-no in my book. Sometimes I do use such practice, but only when designing a new app or form. Then it quickly gets refactored to more general components that group together related functionality, thus adding to the personal toolbox. And then I refactor those to extract even more classes out of them if possible. And again, and again and again. Untill I end up with base classes I can extend to do more specific things. Or tie together to form new classes. U name it. In short, if one does it like that, one day programming becomes more like playing with lego.

In this example I would propably end up with classes for the database connection and handling the dataset, a dataviewer control and then some main application with the form in question maybe also coupled loose from it (depending on the size of the app). To keep it simple. Yeah, I know, the first time I was told to do it like that I also thought that it would double my work. At first it certainly does. Now it's second nature.

But that has all to do with application design and maybe that's a bit out of scope here Smile




Re: Visual C# General should i thread this?

jss3426

thanks for the info. ALso found this which kinda help me get pointed in the right direction.

http://www.codeproject.com/csharp/AsyncMethodInvocation.asp