Re: Task.Wait() -Why?? - C# Discussion Boards

4-Apr-17 6:54

See this MSDN example

If Task.Wait blocks, why would you ever want to use it?? If I'm in a WPF app and I launch a task from the main thread, it blocks the UI, so why bother using a thread? If I'm going to block the main thread, why not just put the thread's code in the UI to start with?

Someone please give me a real example of when I would really want to use Task.Wait.

Thanks

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Pete O'Hanlon4-Apr-17 7:00

4-Apr-17 7:00

You are assuming here that the only time that you would want to use a Task is off the UI thread. This isn't the case. As an example, suppose you wrote some code to index files in a particular folder - and you then want to finish the task only once the indexing has completed, you could very well create a top level task and then fire off multiple tasks inside - with a Wait on them completing.

This space for rent

Kevin Marois4-Apr-17 7:19

4-Apr-17 7:19

So, Task A spawns 3 child tasks, then waits for all 3 to finish.

In this case you would want Task A to run async, correct?

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Pete O'Hanlon4-Apr-17 7:26

4-Apr-17 7:26

Yes.

This space for rent

Richard Deeming4-Apr-17 7:38

4-Apr-17 7:38

In that example, it would be better to use Task.WhenAll[^] to wait for the child tasks to complete.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Pete O'Hanlon4-Apr-17 7:40

4-Apr-17 7:40

That's true. I was trying more to illustrate the point that waiting on a task or a series of tasks doesn't mean that you created it off a UI thread.

This space for rent

Richard Deeming4-Apr-17 7:48

4-Apr-17 7:48

There are very few situations where it's necessary to block the current thread until a task has completed. The only obvious one that comes to mind is when you're writing a console application, and you want to use async code. And with .NET 4.5 or higher, it's usually better to call task.GetAwaiter().GetResult() rather than task.Wait(), to avoid having any exceptions wrapped in an AggregateException.

static class Program
{
    static void Main()
    {
        MainAsync().GetAwaiter().GetResult();
    }
    
    static async Task MainAsync()
    {
        ...
    }
}

But in most cases, there's usually a better option than blocking the current thread.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Kevin Marois4-Apr-17 7:52

4-Apr-17 7:52

Richard Deeming wrote:
There are very few situations where it's necessary to block the current thread until a task has completed.

That's why I asked. I can't see a reason to block, and the example I posted shows the Main method of a console app creating a thread that blocks.

It's a typical stupid MSDN example, but I thought I'd ask anyhow.

Thanks

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Richard Deeming4-Apr-17 8:04

4-Apr-17 8:04

I guess it's difficult to produce a meaningful real-world example that doesn't end up with the concept you're trying to demonstrate buried in unrelated implementation details. Smile | :)

You just need to imagine that the task is an async method, calling an API that's only available via asynchronous task-returning methods. The Main thread is synchronous, so you're going to have to block at some point to wait for the API calls to complete.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Tridip Bhattacharjee5-Apr-17 23:30

Tridip Bhattacharjee

5-Apr-17 23:30

this line

MainAsync().GetAwaiter().GetResult();

block the main thread.

thanks

tbhattacharjee

Richard Deeming6-Apr-17 1:30

in which scenario people use factory design patter

6-Apr-17 1:30

Yes - which is exactly what I said in my message, if you'd bothered to read it. D'Oh! | :doh:

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Tridip Bhattacharjee4-Apr-17 1:58

Tridip Bhattacharjee

4-Apr-17 1:58

we know that in factory design patter we do not create object of any class directly rather create instance of a class by factory class.

The client is an object that requires an instance
of another object (the product) for some purpose. Rather than creating the
product instance directly, the client delegates this responsibility to the factory.
Once invoked, the factory creates a new instance of the product,
passing it back to the client. Put simply, the client uses the
factory to create an instance of the product.

i read this article https://msdn.microsoft.com/en-us/library/ee817667.aspx?f=255&MSPPError=-2147217396

i am looking for a write up on factory design patter which show me when i need to create instance by factory because we can create instance directly but in factory design pattern instance create via factory. so what is the significance of factory design patter.

so if anyone search google there is many article exist on factory design pattern but i do not find any article which tell me scenario when i will not create instance directly rather will create instance via factory.

so please tell me few scenario with example code from where i can see when people would not prefer creating instance of any class directly rather will create instance via factory.

thanks

tbhattacharjee

Re: in which scenario people use factory design patter

Eddy Vluggen4-Apr-17 2:29

Eddy Vluggen

4-Apr-17 2:29

Tridip Bhattacharjee wrote:
i am looking for a write up on factory design patter which show me when i need to create instance by factory because we can create instance directly but in factory design pattern instance create via factory. so what is the significance of factory design patter.

A nice idea would be to create a factory if there are more than a single class than can be used to perform the action.

Simple and usefull example can be found in the DbProviderFactory. Instead of programming against the SqlConnection and SqlCommand, you program against the interfaces IDbConnection and IDbCommand. Next, let the factory decide which actual class to create. That way the user can configure suddenly whether to use the SqlConnection, an OracleConnection, or something completely different.

Another nice idea for factories is that they can also be combined with the Object Pool Pattern. See the TaskFactory for a nice example of that.

It's similar to the strategy-pattern, with the difference that a factory is for creating objects.

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

Re: in which scenario people use factory design patter

Tridip Bhattacharjee4-Apr-17 3:48

Tridip Bhattacharjee

4-Apr-17 3:48

thanks for nice answer. can you please include a article link sir which show how i can use DbProviderFactory to connect sql server ,oracle, oldedb or use dsn to connect any db.

thanks

tbhattacharjee

Re: in which scenario people use factory design patter

Pete O'Hanlon4-Apr-17 4:14

Re: in which scenario people use factory design patter

4-Apr-17 4:14

I assume Google is broken for you. Seriously, you have been posting on this site long enough to indicate that you are meant to be a professional programmer. Part of being a professional programmer is having the ability to do research for yourself.

This space for rent

Gerry Schmitz4-Apr-17 4:36

Gerry Schmitz

4-Apr-17 4:36

Too bad ... You were doing so well up to this point. You seem to think noone has anything better to do than run down errands for you.

"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal

Re: in which scenario people use factory design patter

Eddy Vluggen4-Apr-17 5:24

Eddy Vluggen

4-Apr-17 5:24

A simple example of using DbProviderFactory can be found here[^]. Since you already worked with databases I'm going to assume that you'll recognize most parts; note that we ask the Factory to create a connection for us, instead of creating one ourself.

The factory can also create IDbCommands, but I prefer to use the factory-method that is provided in the IDbConnection-interface. Details on the class can be found on MSDN[^].

The factory does NOT make your code database vendor-independant - it just makes it easier to switch between those classes. Your C# code would no longer depend on a specific implementation, but chances are that you are using an SQL dialect that is specific to the database-server. Stick to SQL92 if you want to minimize the risc of incompatibilities.

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

Strange Problem Loading Config File

Kevin Marois3-Apr-17 7:51

Re: Strange Problem Loading Config File

3-Apr-17 7:51

I'm trying to load a config file from a location other than the app.

// Get the full path and name of the app's Config file.

var configFileName = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;

This returns '.....\bin\Debug\OQRangeDataInput.exe.Config', which is correct

Then I do this to load the config file

_configuration = ConfigurationManager.OpenExeConfiguration(configFileName);

The next line, the OpenExeConfigation sets a property on the Configuration called FilePath which is set to '.....\bin\Debug\OQRangeDataInput.exe.Config.config'
this is clearly wrong.

I had to add this right after the first line to fix it

configFileName = configFileName.ToLower().Replace(".config", "");

So, all told, I now have this

private void LoadConfigFile()
{
    var configFileName = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;

    // For some reason ConfigurationManager.OpenExeConfiguration adds ".config" to the end
    // of the file name, so it appears as "app.exe.config.config"
    configFileName = configFileName.ToLower().Replace(".config", "");

    _configuration = ConfigurationManager.OpenExeConfiguration(configFileName);

    AppConfigFile = configFileName;
}

Anyone see what's wrong? Is this some kind of bug, or am I just doing it wrong?

Thanks

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Richard Deeming3-Apr-17 8:03

Re: Strange Problem Loading Config File

3-Apr-17 8:03

Have a look at the documentation:

ConfigurationManager.OpenExeConfiguration Method (String) (System.Configuration)[^]:
exePath: The path of the executable (exe) file.

The method expects you to pass the path of OQRangeDataInput.exe, not the path of the config file you want to open.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Kevin Marois3-Apr-17 8:07

3-Apr-17 8:07

Well there ya go!!

I was using "AppDomain.CurrentDomain.SetupInformation.ConfigurationFile" because if the Config file doesn't exist I create it.

Thanks!

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Understanding IOC

Liagapi2-Apr-17 21:06

Liagapi

2-Apr-17 21:06

I've recently read about the Inversion of Control (IOC) principle and I have a few questions I'd like to have answered. I've read that in order to implement the principle of IOC, one must not define a class and pass in concrete objects as its constructor's parameters but one must instead use interfaces as its constructor's parameters.

My first question is can I implement IOC by defining a class with virtual classes as its constructor's parameters instead of interfaces. After all the whole reason behind using interfaces is to decouple the class from its dependencies and virtual classes can pretty much do that.

My second question is can I use abstract classes as the parameters instead of interfaces.

Thanks in advance for your reply.

modified 3-Apr-17 3:37am.

Re: Understanding IOC

Pete O'Hanlon2-Apr-17 22:41

2-Apr-17 22:41

C# doesn't support the concept of virtual classes so, in the context of this forum, the first part of your question makes no sense.

With regards to using abstract classes, yes you can. Only a very poor IoC framework wouldn't support them but there are things to consider. First of all, we tend to prefer composition over inheritance nowadays, so an abstract base class would be a violation of that principal. Versioning an interface is difficult to do, so if you need to inject something that is version aware, you should consider using an abstract class in that case.

This space for rent

Re: Understanding IOC

Liagapi3-Apr-17 16:32

Liagapi

3-Apr-17 16:32

Hi thanks for replying. I meant to say a generic class that has virtual methods or methods that take generic types T.

Re: Understanding IOC

Pete O'Hanlon3-Apr-17 20:41