Discussion :

[zooffy]

Effectivement, j'ai pas réussi à exprimé, du coup, je pense que deux images vont être plus explicite.
Les listes déroulantes sont celles qui sont ouvertes sur ces deux captures d'écran.
On peut voir que la liste de Gauche est presque vide alors qu'elle devrait contenir la liste des contrôle de la ^page posés côté HTML.
Et la liste de Droite contient ce qu'il y a de saisie dans le code + les contrôles qui n'ont rien à faire là.

Vois tu ?

[tomlev]

On peut voir que la liste de Gauche est presque vide alors qu'elle devrait contenir la liste des contrôle de la ^page posés côté HTML.

"devrait" ? D'après qui ? Ce n'est pas parce que c'est comme ça en VB que ça doit être pareil en C#
C'est l'éditeur C# standard, il n'y a rien de spécifique à ASP.NET. La liste de gauche contient toutes les classes définies dans le fichier, et celle de droite tous les membres déclarés dans la classe. C'est juste pour faciliter la navigation dans le code.

Et la liste de Droite contient ce qu'il y a de saisie dans le code + les contrôles qui n'ont rien à faire là.

Ils ont quelques choses à faire là, puisque ce sont des membres de la classe (mais déclarés dans un autre fichier)

[Nathanael Marchand]

Ca dépend de ce que sont sensés contenir les listes! En C#, c'est la liste des classes du fichier (donc généralement une) et celle de droite les membres de la classe (attributs, propriétés, méthodes).
Etant donné qu'un textbox d'une page appartient visuellement à la page, il est tout à fait normal qu'il soit membre de la classe.

Bien souvent, quand je vois des questions VB.Net, je me demande vraiment comment la personne peut poser cette question. Je commence désormais à comprendre, vu le côté magique/boite noire(/laxiste ?) de VB.Net qui masque tout et qui ne permet pas de comprendre trop bien comment ca se passe sous le capot... Rien que la "rigueur" de C# permet de mieux comprendre et de solutionner bien des problèmes apparament...

[zooffy]

Ok, je vois ce que vous voulez dire.
ça doit être pour ce genre de chose que j'ai toujours refusé de me mettre au C# (ou C en général).
Le confort du VB me va vraiment mieux, même si pour vous c'est de la magie ou du laxisme.

Encore une fois, c'est une question de point de vue, mais l'esclave de l'homme, c'est la machinee t avec cette façon de faire (C#) j'ai plus l'impression du contraire, je me sens martyrisé par des détails dont l'importance ne me saute pas aux yeux.

Je vais avoir beaucoup de mal à reprogrammer tout mon système sans avoir accès aux évènements des contrôles de manière directe, va falloir que je plonge dans la MSDN en permanence pour trouver les choses.

Bon, en tout cas merci pour tout ce que vous avez fait, je vais lutter encore un peu, mais si ça tourne au masochisme, j'arrête.

Bonne soirée à vous.

[tomlev]

Je vais avoir beaucoup de mal à reprogrammer tout mon système sans avoir accès aux évènements des contrôles de manière directe

Mais bien sûr que tu y as accès, via le designer ! Tu sélectionnes ton contrôle, et dans la grille des propriétés (onglet évènements) tu double-cliques l'évènement, et ça te génère la méthode qui va bien dans le code-behind. Faut pas croire non plus qu'en C# on est obligé de tout faire à la main

C'est juste que les outils sont conçus différemment. Moi quand j'utilise VB.NET (ce qui heureusement est rare) je suis toujours perdu et je suis beaucoup moins productif... mais c'est juste une question d'habitude. Quand tu auras pris l'habitude de C#, et que tu sauras tirer parti des raccourcis en tous genres proposés par l'éditeur, tu seras tout aussi efficace que tu l'étais en VB

[Bluedeep]

tu seras tout aussi efficace que tu l'étais en VB

Plus, car en C# le code source n'est pas un roman fleuve

[DonQuiche]

@Zoofy
Ne t'y trompe pas, tu perds en réalité bien peu de choses en passant au C#, ce sont simplement des réflexes différents qu'il te faut adopter.

En revanche, tu vas gagner beaucoup : un code plus compact, plus lisible, davantage de fonctionnalités, un meilleur support de l'IDE, et sans doute un meilleur code au final. Et n'oublie que presque chaque contrainte vient avec des bénéfices : par exemple le respect de la casse te permet de stocker une instance de "Client" dans une variable nommée "client".

Crois-moi, une fois la période d'adaptation passée, tu ne regretteras plus le VB.

[zooffy]

Merci les gars pour vos encouragements.
Je vais persévérer mais à 41 ans aprés 8 ans de VB, pas simple de tout remettre en cause.
J'ai l'impression de repartir de zéro et de tout réapprendre. C'est pas simple.

Je vais me permettre de pas boucler le topic tout de suite, histoire d'avoir une bouée de sauvetage en cas de pépin.

Là j'attaque le coeur de mon système, donc du code pur et j'en profite pour améliorer deux ou trois détails, histoire d'être plus performant.
J'ai bien aimé ce que j'ai découvert sur le traitement des chaines de caractères avec le substring. ça m'a l'air plus performant que la série de Left(), Right() et Mid() en VB.

Zou, je plonge.

Bonne journée à tous.

[zooffy]

Bon alors premier problème de la journée que je ne comprends pas.
J'ai fais une fonction qui retourne une table.
J'ai utilisé une structure Try Catch pour gérer les erreurs.
L'idée c'est de prendre des données dans la base, les mettre dans une DataTable et de renvoyer la DataTable pleine.
S'il y a une erreur (donc le catch) il faut loguer l'erreur dans un fichier
Et quoi qu'il arrive il faut fermer la connexion (le Finaly)

Voici donc le code de cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
public DataTable RetournerTable(string requete)
        {
            try
            {
                // On assigne une requêtes parametrée à la commande
                SqlCommand commande = new SqlCommand(requete);
 
                //' On lui assigne une connexion
                commande.Connection = this.Conex;
 
                Adapteur = new SqlDataAdapter(commande);
                SqlCommandBuilder oCommandBuilder = new SqlCommandBuilder(Adapteur);
 
                Table = new DataTable();
                Conex.Open();
                Adapteur.Fill(Table);
                return Table;
            }
            catch(Exception ex)
            {
                SystemC.Outils.Logage(ex.Message);
                SystemC.Outils.Logage(requete);
            }
            finally
            {
                this.Conex.Close();
            }
        }

A la compilation il bloque en me disant :

Erreur 1 'SystemC.Dmanager.RetournerTable(string)'*: tous les chemins de code ne retournent pas nécessairement une valeur D:\inetpub\SystemC\App_Code\DataCon.cs 60 26 http://www.systemc.maison/

Je vois pas comment je peux lui dire autre chose.

Vous avez une idée ?

[tomlev]

Bah si tu passes dans le catch, la méthode ne retourne rien... il faut soit renvoyer quelque chose, soit relancer l'erreur (je pencherai pour la 2e option, parce que je vois pas ce que tu pourrais retourner dans ce cas...). Et donc ton catch devient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
            catch(Exception ex)
            {
                SystemC.Outils.Logage(ex.Message);
                SystemC.Outils.Logage(requete);
                throw; // relance l'exception interceptée
            }

C'était quoi ton code VB d'origine ?

[Bluedeep]

Bon alors premier problème de la journée que je ne comprends pas.Je vois pas comment je peux lui dire autre chose.

Vous avez une idée ?

Oui : le return n'est exécuté qu'en cas d'absence d'exception; en cas d'exception, on ne passe pas dans le return, on passe dans le handler d'exception, puis dans le bloc finally, et .... plus d'instruction return.

Donc rajouter, par exemple, un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

return null;

en dessous du bloc finally (pas à l'intérieur bien sur).

[tomlev]

Donc rajouter, par exemple, un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

return null;

en dessous du bloc finally (pas à l'intérieur bien sur).

Oui, enfin dans ce cas la méthode appelante va récupérer un null, ce qu'elle n'avait peut-être pas prévu... et donc ça va péter une NullReferenceException. Perso je préfère relancer l'exception, au moins on voit clairement l'origine du problème

[zooffy]

Merci les gars.

Relancer l'exception ou renvoyer un null, ok, ça me va.
De toute façon, même si c'est bizarre, l'idée est d'avoir un plantage de la page à ce moment là.
Du coup, je vais essayer les deux méthodes, mais le renvoi du null me plait plus, d'autant que lorsque j'utilise cette fonction je commence par vérifier que la DataTable contient au moins une ligne.

Par contre si je mets un return null; aprés le Finaly, ça va bien me renvoyer la table avant dans le cas où elle serait pleine ?

Le code VB d'origine qui ne m'a jamais posé ce genre de souci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Public Function RetournerTable(ByVal requete As String) As DataTable
            Try
                ' On assigne une requêtes parametrée à la commande
                Dim commande As New SqlCommand(requete)
 
                ' On lui assigne une connexion
                commande.Connection = Me.Conex
 
                Adapteur = New SqlDataAdapter(commande)
                Dim oCommandBuilder As New SqlCommandBuilder(Adapteur)
 
                Table = New DataTable()
                Conex.Open()
                Adapteur.Fill(Table)
 
                Return Table
            Catch ex As Exception
                ProjetY.Outils.Logage(ex.Message)
                ProjetY.Outils.Logage(requete)
            Finally
                Me.Conex.Close()
            End Try
 
        End Function

[zooffy]

Heu, attendez un moment.
En fait je viens de me rendre compte que si ça plante c'est parce que ma requête est pourrie (oublie des ' autour des chaines !!!)

Donc si ma requête est pourrie j'ai une erreur.
Si je prends la technique du return null; il me fait une exception que je ne sais pas gérer, vu qu'il n'y a pas de DataTable en testant le nombre de ligne ça coince dur, dur.

Si je prends la technique throw il me balance une SQLexception non gérée et je sais pas comment m'en sortir.

Voyez vous le truc ?

[tomlev]

Par contre si je mets un return null; aprés le Finaly, ça va bien me renvoyer la table avant dans le cas où elle serait pleine ?

Oui

Le code VB d'origine qui ne m'a jamais posé ce genre de souci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Public Function RetournerTable(ByVal requete As String) As DataTable
            Try
                ' On assigne une requêtes parametrée à la commande
                Dim commande As New SqlCommand(requete)
 
                ' On lui assigne une connexion
                commande.Connection = Me.Conex
 
                Adapteur = New SqlDataAdapter(commande)
                Dim oCommandBuilder As New SqlCommandBuilder(Adapteur)
 
                Table = New DataTable()
                Conex.Open()
                Adapteur.Fill(Table)
 
                Return Table
            Catch ex As Exception
                ProjetY.Outils.Logage(ex.Message)
                ProjetY.Outils.Logage(requete)
            Finally
                Me.Conex.Close()
            End Try
 
        End Function

Bah y avait le même problème... sauf qu'en VB c'est juste un warning, alors qu'en C# c'est une erreur. Le comportement actuel de ta méthode VB est de renvoyer la valeur par défaut en cas d'erreur (donc null/Nothing)

En fait je viens de me rendre compte que si ça plante c'est parce que ma requête est pourrie (oublie des ' autour des chaines !!!)

Faut pas construire des requêtes par concaténation, tu t'exposes à toutes sortes de problèmes (format de date et de nombre, injection SQL...)
Utilise des requêtes paramétrées
http://johannblais.developpez.com/tu...s-donnees/#LIV

Donc si ma requête est pourrie j'ai une erreur.
Si je prends la technique du return null; il me fait une exception que je ne sais pas gérer, vu qu'il n'y a pas de DataTable en testant le nombre de ligne ça coince dur, dur.

Si je prends la technique throw il me balance une SQLexception non gérée et je sais pas comment m'en sortir.

Bah y a pas 36 solutions, si tu as une erreur que tu peux pas gérer, tu affiches un message d'erreur... y a pas de solution magique pour retomber sur ses pieds dans ce genre de cas

[zooffy]

Ok, je vois mieux maintenant.

Bon alors sur le sujet des requêtes j'utilise des Procédures stockées que je trouve plus performantes (mais c'est affaire de gout). Et au niveau sécurité du SQL injection je trouve que ça marche bien.

Sinon, pour gérer l'erreur, je pense que je vais retenir la technique du return null; sauf que je sais pas quoi faire au retour.

J'explique :
je lance ma requête avec ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DataTable VerifSite = new Dmanager("DataDev").RetournerTable("EXEC CORE_VerifSiteExiste " + urlsite + "'");

et je test avec ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (VerifSite.Rows.Count == 1)

Sauf que si j'ai fait un return null; ben il plante.

Alors comment tester que la DataTabel est null ?
Ou alors est ce que plutôt que de faire un return null; je peux faire un return new DataTable (une DataTable vide mais pas null en gros) ?

[Immobilis]

Salut,

Sauf que si j'ai fait un return null; ben il plante

Ne retourne pas null si une erreur se produit. Cela cache l'erreur qui risque de réapparaître sous une autre forme. Du coup, tu ne comprendras plus rien. Si une erreur se produit il faut gérer l'erreur pas le null.

Alors comment tester que la DataTabel est null ?

A la limite instancie la DataTable, et renvoi la vide.

Sinon, une bonne pratique, utilise les objets disposable (connexion SQL, etc.) dans un "using": http://msdn.microsoft.com/en-us/library/yh598w02.aspx. Cela évite le try...catch...finally.

A+

[zooffy]

Merci.

J'ai finallement utilisé un return new DataTAble();
Et ça marche bien, si la requête plante, je reprends une table vide que je peux gérer facilement et mon erreur se logue dans mon fichier texte, donc je peux voir la tronche de ma requête et corriger le tir.

Allez, je continue parce que là, je n'en suis qu'à la vérification de l'existence du site dans mon système, j'ai pas encore ouvert une page !!!

[tomlev]

Sauf que si j'ai fait un return null; ben il plante.

Bah il suffit de vérifier la valeur de retour...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
DataTable VerifSite = new Dmanager("DataDev").RetournerTable("EXEC CORE_VerifSiteExiste " + urlsite + "'");
if (VerifSite == null)
{
    ...
}

[zooffy]

Merci Tomlev.

Toujours dans la série de vérification avec des null, j'ai un autre souci, mais je comprends pas bien.

Avec ma fonction je vais chercher une donnée dans la base.
Ma fonction renvoi du string et là j'ai besoins de convertir à la volée en Int64.
Sauf que (j'ai fait expres) la requete ne renvoi rien, pas même du null, y a juste pas d'enregistrement.

Et la conversion ne veut pas se faire toute seul vers 0.
Alors est ce que c'est moi qui suis à côté de la plaque ou est ce que j'ai zappé un truc ?

Voici le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Int64 IdPageDefault = Convert.ToInt64(new Dmanager("DataDev").RetournerScalaire("EXEC dbo.CORE_PageIdDefault '" + urlsite + "'"));

Je peux aussi gérer le truc dans la Proc Stock de la base, mais j'aurais aimé le faire dans le code C#.

Merci pour votre aide.