Comment le taux de retour à l'intérieur des méthodes anonymes?

Fondamentalement, je n'ai anonyme méthode que j'utilise pour mes BackgroundWorker:

worker.DoWork += ( sender, e ) =>
{
    foreach ( var effect in GlobalGraph.Effects )
    {
        //Returns EffectResult
        yield return image.Apply (effect);
    }
};

Quand je fais cela, le compilateur me dit:

"Le rendement de la déclaration ne peut pas être utilisé
à l'intérieur d'une méthode anonyme ou lambda
l'expression"

Donc dans ce cas, quelle est la façon la plus élégante pour ce faire? Btw, ce DoWork méthode est à l'intérieur d'une méthode statique, dans le cas où les questions de la solution.

C'est le fond de travailleur de la production de la image ou est-ce le remplissage de la GlobalGraph.Effects énumérable?
Oui, le BW est la production de l'image, mais les EffectResult a le statut de sujet de l'effet, et non des données d'image ou quelque chose comme ça.
double possible de En C#, pourquoi pas une méthode anonyme contenir une instruction rendement?

InformationsquelleAutor Joan Venge | 2011-03-23

16

Malheureusement, vous ne pouvez pas.

Le compilateur ne vous permet pas de combiner les deux "magie" des morceaux de code. Les deux impliquent la réécriture de votre code à l'appui de ce que vous voulez faire:
1. Une méthode anonyme se fait en déplaçant le code d'une méthode appropriée, et la levée des variables locales à des champs de la classe avec la méthode
2. Une méthode d'itérateur est réécrit comme une machine d'état
Vous pouvez, cependant, réécrire le code de retour de la collection, donc dans votre cas particulier, je voudrais faire cela:
```
worker.DoWork += ( sender, e ) =>
{
    return GlobalGraph.Effects
        .Select(effect => image.Apply(effect));
};
```
mais il semble bizarre pour un événement (sender, e) de retourner quoi que ce soit. Êtes-vous sûr que vous faites preuve d'un réel scénario pour nous?

Modifier Ok, je pense je vois ce que vous essayez de faire ici.

Vous avez une méthode statique d'appel, et que vous voulez exécuter du code en arrière-plan, puis de renvoyer les données à partir de cette méthode statique une fois le fond appel se termine.

C'est, si elle est possible, n'est pas une bonne solution puisque vous êtes effectivement la pause d'un thread attente d'un autre, qui a commencé juste avant vous avez interrompu le fil. En d'autres termes, tout ce que vous avez à faire est d'ajouter les frais généraux de la commutation de contexte.

Au lieu de cela, vous devez juste le coup d'envoi du travail de fond, puis lorsque ce travail est terminé, le traitement des données qui en résultent.
- Grâce Lasse. Effectivement, vous avez raison, je ne suis pas sûr si je suis en train de faire la bonne chose sur ce. Fondamentalement, ce travailleur est à l'intérieur d'une méthode statique appelé Run qui est censé renvoyer IEnumerable<EffectResult>. Comment dois-je faire? En dehors de la DoWork? Je l'ai juste fait là parce que l'application d'un tas d'effets est tous cette méthode est en train de faire (et de retourner les résultats).
- Aussi, même si je l'ai montré comme ça, j'ai une boucle for à faire quelque chose d'autre avant de l'image.Appliquer est appelé, pour chaque itération, je peux mettre une boucle for à l'intérieur d'une expression lambda?
- Vous ne pouvez pas faire un return à l'intérieur d'un lambda, qui vise à revenir à partir de l'affichage de la méthode. Un return dans un lambda de retour de l'lambda lui-même.
- Il n'y a aucun moyen de retour de la enfermant méthode tout dans une méthode anonyme. C'est comme de dire que cette méthode appelle la méthode B et de la méthode B retourne à partir de la méthode A, il n'est pas possible. Il est, cependant, un signe qu'il ya quelque chose de mal avec l'ensemble de la ligne de pensée de cette question.
- Fondamentalement, je suis en train d'obtenir les résultats un par un, pas quand la méthode statique est fini son travail. Est-ce que vous vouliez dire?
InformationsquelleAutor angry person
10

Peut-être juste de retour de l'expression linq et de reporter l'exécution comme rendement:
```
return GlobalGraph.Effects.Select(x => image.Apply(x));
```
InformationsquelleAutor Tejs
5

Sauf si je suis en manque de quelque chose, vous ne pouvez pas faire ce que vous demandez.

(J'ai une réponse pour vous, lisez donc passé mon explication de pourquoi vous ne pouvez pas faire ce que vous faites en premier, et alors lisez la suite.)

Vous complète de la méthode devrait ressembler à quelque chose comme ceci:
```
public static IEnumerable<EffectResult> GetSomeValues()
{
    //code to set up worker etc
    worker.DoWork += ( sender, e ) =>
    {
        foreach ( var effect in GlobalGraph.Effects )
        {
            //Returns EffectResult
            yield return image.Apply (effect);
        }
    };
}
```
Si nous supposons que votre code est "légal" puis, quand GetSomeValues est appelé, même si le DoWork gestionnaire est ajouté à worker, l'expression lambda n'est pas exécutée jusqu'à ce que le DoWork événement est déclenché. Donc, l'appel à GetSomeValues complète sans retour à tous les résultats et les lamdba peut ou peut ne pas être appelé à un stade ultérieur - qui est alors trop tard pour l'appelant de la GetSomeValues méthode de toute façon.

Votre meilleure réponse est l'utilisation Rx.

Rx tourne IEnumerable<T> sur sa tête. Au lieu de demander les valeurs d'une énumération, Rx a des valeurs poussé à vous de une IObservable<T>.

Car vous utilisez un arrière-plan travailleur et de réagir à un événement, vous êtes effectivement en ayant les valeurs poussé à vous déjà. Avec Rx, il devient facile de faire ce que vous essayez de faire.

Vous avez quelques options. Probablement le plus simple est de le faire:
```
public static IObservable<IEnumerable<EffectResult>> GetSomeValues()
{
    //code to set up worker etc
    return from e in Observable.FromEvent<DoWorkEventArgs>(worker, "DoWork")
           select (
               from effect in GlobalGraph.Effects
               select image.Apply(effect)
           );
}
```
Maintenant appelants de votre GetSomeValues méthode pourrait faire ceci:
```
GetSomeValues().Subscribe(ers =>
{
    foreach (var er in ers)
    {
        //process each er
    }
});
```
Si vous savez que DoWork est seulement à feu une fois, cette approche pourrait être un peu mieux:
```
public static IObservable<EffectResult> GetSomeValues()
{
    //code to set up worker etc
    return Observable
        .FromEvent<DoWorkEventArgs>(worker, "DoWork")
        .Take(1)
        .Select(effect => from effect in GlobalGraph.Effects.ToObservable()
                          select image.Apply(effect))
        .Switch();  
}
```
Ce code est un peu plus compliqué, mais il permet juste d'un unique effectuer des travaux de l'événement dans un flux de EffectResult objets.

Puis le code d'appel qui ressemble à ceci:
```
GetSomeValues().Subscribe(er =>
{
    //process each er
});
```
Rx peut même être utilisé pour remplacer l'arrière-plan travailleur. Ce pourrait être la meilleure option pour vous:
```
public static IObservable<EffectResult> GetSomeValues()
{
    //set up code etc
    return Observable
        .Start(() => from effect in GlobalGraph.Effects.ToObservable()
                     select image.Apply(effect), Scheduler.ThreadPool)
        .Switch();  
}
```
Le code d'appel est la même que dans l'exemple précédent. Le Scheduler.ThreadPool dit Rx comment faire pour "planifier", le traitement des abonnements à l'observateur.

J'espère que cette aide.
- Grâce à ce qui semble être une bonne solution. Vous connaissez aussi une solution purement à l'aide de la BW? Je voudrais utiliser Rx, mais actuellement, je ne veux pas ajouter de nouvelles dépendances, si possible. Plus tard, je peux travailler à l'embellissement du code.
- Vous ne pouvez pas utiliser le BW pour faire ce que vous voulez. Il n'est pas judicieux de l'utiliser. Votre code d'appel est d'obtenir un IEnumerable<EffectResult> qui il a bloquer sur tout le BW est en train de faire sa chose. Vous pourriez ainsi éviter l'BW entièrement à cause de cela. Vous avez besoin d'utiliser quelque chose comme Rx ou le TPL.
- OK, alors comment suis-je censé mise à jour de l'INTERFACE utilisateur tout en utilisant BW? Il me semble qu'il doit être facile à faire au moins. Je suis en utilisant WPF et progressivement souhaitez mettre à jour la collection de l'INTERFACE est reliée à donc c'est pourquoi j'ai voulu utiliser IEnumerable<EffectResult>.
- L'exécution thru tout IEnumerable<T> est un appel bloquant. À l'aide d'un yield return ne pas faire en asynchrone. Votre BW devraient faire tous les traitements de données à l'arrière-plan, puis, une fois terminé, la main sur les données traitées à l'INTERFACE utilisateur en une seule étape. Vous êtes à essayer de le remettre dans de nombreuses étapes (c'est à dire à l'aide d'un énumérable) et qui ne va pas au travail. Essayez d'utiliser TPL. Si vous êtes sur .NET 3.5 SP1, alors vous pouvez obtenir le TPL par l'installation de Rx. Il est livré dans il.
- Grâce Énigme. J'utilise .NET 4.0, mais n'utilisez pas de TPL avant. Je ne pensais pas que ce serait aussi dur. Si je mettre à jour l'INTERFACE utilisateur dans l'étape 1, il est facile, mais pas souhaitable parce que les utilisateurs veulent des commentaires en temps réel sur ce qui se passe :O
- Rendre sensible l'INTERFACE utilisateur est difficile. À l'aide de TPL, vous pouvez de manière asynchrone retour tous vos résultats en une seule étape. À l'aide de Rx vous pouvez de manière asynchrone retour chaque résultat, un à la fois. Sinon, vous aurez besoin pour permettre à l'BW code directement mettre à jour l'INTERFACE utilisateur via des appels invoquée sur le thread d'INTERFACE utilisateur. Toutes les options sont en désordre. Rx sonne comme le meilleur choix pour vous. Il a des activités à faire traitement en arrière-plan et de premier plan de la mise à jour sans trop de travail.
- Grâce Énigme, afin de retourner des résultats 1 par 1 comme je veux n'est même pas possible dans le TPL, mais seulement Rx? - Je besoin pour terminer cette bientôt donc, j'ai des soucis d'apprentissage Rx est va prendre beaucoup plus de temps une fois que je reçois en elle.
- Si vous pouvez poster plus de votre code, je peux vous aider avec le Rx code, si ça peut aider.
- Grâce Énigme, il serait utile pour vous. Je ne peux pas poster de SI, mais je vais voir si je peux en extraire certaines parties de rendre cette partie de l'après-mesure. Utilisez-vous des Rx beaucoup dans vos propres trucs?
- Oui, j'utilise Rx en tant que partie intégrante de tout mon code. Vous pourriez m'envoyer un email à mon nom d'utilisateur à gmail.
- Merci man, l'apprécier. Je suis sur quelque chose, donc si je peux le faire, je vais vous laisser savoir, parce que je n'aurez pas besoin de faire de complexe de thread de l'UI.
- Ok j'ai réussi à le faire en utilisant l'Action<float, EffectResult>, et faire ce que je veux avec le passé EffectResult à chaque itération, il fonctionne exactement comme je le voulais. Heureux je n'ai pas besoin de compliquer davantage.
InformationsquelleAutor Enigmativity
1

DoWork est de type DoWorkEventHandler qui ne renvoie rien (void),
il n'est donc pas possible dans votre cas.

InformationsquelleAutor manji
1

Le travailleur doit définir le Résultat de la propriété de DoWorkEventArgs.
```
worker.DoWork += (s, e) => e.Result = GlobalGraph.Effects.Select(x => image.Apply(x));
```
- Puis-je "exploiter" ce résultat comme un IEnumerable? Parce que je veux mettre à jour mon INTERFACE utilisateur que les effets sont appliqués, au sujet de leurs résultats.
- Vous devez configurer un gestionnaire pour RunWorkerCompleted. Ensuite, foreach (var en effet (GlobalGraph.Les effets) e.Suite) ...
- Donc vous voulez dire que je dois ajouter la mise à jour des progrès et de l'INTERFACE utilisateur mise à jour RunWorkerCompleted? Parce que j'ai une certaine séparation entre cette classe et de l'INTERFACE utilisateur, avec des ViewModels, etc.
- Oui, DoWork ne peut pas toucher l'INTERFACE utilisateur, car il n'est pas sur le thread d'INTERFACE utilisateur. Le RunWorkerCompleted est invoquée après l'DoWork remplit, et il est SUR le thread d'INTERFACE utilisateur; c'est là que vous mettez à jour l'INTERFACE utilisateur. Veuillez cocher accepter si cette réponse, c'est ok.
- Merci Richard, mais RunWorkerCompleted n'est soulevée une fois, non? Je veux mettre à jour l'INTERFACE utilisateur à chaque fois un effet est exécuté, pour montrer son résultat et de mettre à jour la barre de progression.
- Alors pourquoi le faire sur un thread d'arrière-plan. Juste faire le code sur le thread de l'INTERFACE utilisateur avec l'aide d'un BackgroundWorker.
- Mais le thread d'INTERFACE utilisateur uniquement les appels de cette méthode statique à l'intérieur de la classe statique qui est responsable de l'application des effets. N'est-ce pas une bonne pratique? Parce que sinon, la logique sera mis dans le code de l'INTERFACE utilisateur, qui appartient à la EffectGraph type.
InformationsquelleAutor Richard Schneider

Ok, donc j'ai fait quelque chose comme ce qui fait ce que je voulais (certaines variables omises):

public static void Run ( Action<float, EffectResult> action )
{
    worker.DoWork += ( sender, e ) =>
    {
        foreach ( var effect in GlobalGraph.Effects )
        {
            var result = image.Apply (effect);

            action (100 * ( index / count ), result );
        }
    }
};

et ensuite dans le site d'appel:

GlobalGraph.Run ( ( p, r ) =>
    {
        this.Progress = p;
        this.EffectResults.Add ( r );
    } );

InformationsquelleAutor Joan Venge

Pour les nouveaux lecteurs: la façon la plus élégante pour mettre en œuvre anonyme des itérateurs " (j'. e. imbriqués dans d'autres méthodes) en C#5 est probablement quelque chose comme ce truc génial avec async/await (ne pas être confondu par ces mots-clés, le code ci-dessous est calculé absolument synchrone - voir les détails dans la page du lien):

        public IEnumerable<int> Numbers()
        {
            return EnumeratorMonad.Build<int>(async Yield =>
            {
                await Yield(11);
                await Yield(22);
                await Yield(33);
            });
        }

        [Microsoft.VisualStudio.TestTools.UnitTesting.TestMethod]
        public void TestEnum()
        {
            var v = Numbers();
            var e = v.GetEnumerator();

            int[] expected = { 11, 22, 33 };

            Numbers().Should().ContainInOrder(expected);

        }

C#7 (maintenant disponible dans Visual Studio 15 Aperçu) prend en charge fonctions locales, qui permettent à yield return:

public IEnumerable<T> Filter<T>(IEnumerable<T> source, Func<T, bool> filter)
{
    if (source == null) throw new ArgumentNullException(nameof(source));
    if (filter == null) throw new ArgumentNullException(nameof(filter));

    return Iterator();

    IEnumerable<T> Iterator()
    {
        foreach (var element in source) 
        {
            if (filter(element)) { yield return element; }
        }
    }
}

InformationsquelleAutor user1414213562

Vous devez vous connecter pour publier un commentaire.