Flux XMLQautre p’tits bugs… et puis s’en vont
Par amethyste le Oct 16, 2007 | Dans focus | 4 retours »
Voici une série de bugs de nos outils favoris avec une solution de contournement ou de résolution. J’espère que cela vous fera gagner du temps.
Un bug sur mon blog
Ceux qui ont suivi la SAGA de l’été sur l’authentification ont sans doute lu l’opus numéro 2 qui présentait une solution pour se reconnecter avec un autre utilisateur dans un contexte d’authentification Windows.
J’ai implémenté cette solution sur un de mes projets et je suis tombé sur un problème assez vite : certaines pages étaient appelées sous le nouveau login, d’autres non.
Je ne connais absolument pas la cause de ce problème (si quelqu’un a une idée je suis très intéressé), mais j’ai trouvé une solution.
Le code se termine par ceci :
// redirection vers la page d'accueil this.Response.Redirect("default.aspx");
Tout rentre dans l’ordre si on remplace Response.Redirect par Server.Transfert().
Un bug de IE 7
Créez cette innocente page :
<html> <meta> <script/> </meta> <body>Hello</body> </html>
Vous vous attendez à voir Hello, s’afficher. En fait on observe ceci :
Une page blanche !
Le problème vient de la balise <script>. Il faut l’écrire en deux fois :
<script> </script>
Un bug avec TableAdapter
TableAdapter n’est en réalité pas un vrai composant. Mais peut importe, j’aime bien m’en servir et n’hésite pas à écrire des DAL entières avec.
Malheureusement ce composant est souvent assez fragile et a des comportements parfois difficiles à comprendre.
Un de ces bugs récurrents se produit de façon aléatoire. Lorsque vous tentez d’ouvrir le TableAdapter dans le designer en double cliquant sur le fichier .xsd. Vous obtenez ceci :
Le plus curieux est que cela n’empêche pas le composant de fonctionner avec l’existant, mais évidemment impossible de développer !
Si vous éditez le fichier .xsd avec Notepad et observez la section <connections>, vous allez trouver quelque chose de similaire à ceci :
<Connections> <Connection AppSettingsObjectName="Settings" AppSettingsPropertyName="Amethyste" ConnectionStringObject="" IsAppSettingsProperty="True" Modifier="Assembly" Name=" Amethyste (Settings)" ParameterPrefix="@" PropertyReference="ApplicationSettings.Amethyste.Dal.Properties.Settings.GlobalReference.Default. Amethyste" Provider="System.Data.SqlClient"> </Connection> <Connection AppSettingsObjectName="Settings" AppSettingsPropertyName="Amethyste" ConnectionStringObject="" IsAppSettingsProperty="True" Modifier="Assembly" Name=" Amethyste (Settings)" ParameterPrefix="@" PropertyReference="ApplicationSettings. Amethyste.Dal.Properties.Settings.GlobalReference.Default.Amethyste" Provider="System.Data.SqlClient"> </Connection> </Connections>
De temps à autre Visual Studio duplique la déclaration de la chaîne de connexion, c’est cela qui provoque le problème. Il suffit de supprimer l’une d’entre elles et tout rentre dans l’ordre.
J’ai trouvé cette solution sur un blog, mais pas moyen de le retrouver. Désolé pour l’auteur.
Bug avec les DataSources
Une des nouveautés de .NET 2.0 sont les DataSource. C'est donc gaiement que je tente de lier un DataGridView à un DataSource sur une WinForm en ce jour pourtant grisâtre.
Je clique donc sur le SmartTag, puis la liste déroulante intitulée Choose datasource.
Immédiatement VS plante et je me fais éjecter! Le plus fou est que cela se produisait sur CE projet et pas sur d'autres.
Je ne vais pas vous révéler l'explication, que j'ignore, mais au moins une solution laborieusement trouvée par hasard.
La première fois que vous ajoutez un DataSource à un projet un sous-répertoire DataSource est créé dans le répertoire Properties du projet. Ce répertoire contient un fichier XML de configuration pour les DataSources du projet.
On peut essayer plusieurs choses:
le menu contextuel Refresh appliqué à chaque fichier ou bien carrément les supprimer.
Pour ma part c'est ce que j'ai fais avant de découvrir Refresh et ça ne semble pas perturber pépère.
Un dernier problème demeure avec mon DataGridView, parfois sa fenêtre de propriétés refuse de s'afficher. Pour l'instant je ne peux que relancer VS pour y accéder de nouveau. Si quelqu'un à une idée...
4 commentaires
Concernant le 1er bug concernant le response.Redirect(). J'ai eu ce bug la semaine dernière et il semble qu'il faut rajouter un paramètre à response.Redirect(url,false) pourque cela fonctionne :)
Pour le deuxième, c'est juste que IE ne supporte pas réellement XHTML. On obtient le même genre d'effet rigolo avec un . C'est plus spectaculaire avec script parce que ça bouffe tout, mais un simple div peut mettre un beau foutoir dans le DOM aussi.
Laisser un commentaire
| « ID, Name, ClientID et UniqueID c’est quoi au juste ? | Lorem Ipsum » |
