Le copier coller dans les applications .NET est extremement simple à mettre en place.

Le code d'un copier coller d'une image se coderait ainsi en .NET :  Clipboard.SetData(DataFormats.Dib,MonImage);

Mais il peut arriver que certaines applications cibles ne le prennent pas en compte. Par exemple le copier coller vers open office est assez étrange. En effet avec les methodes classique de copier/Coller du .NET il n'est pas possible de le réaliser. En se baladant ici on peut voir que beaucoup de personnes rencontrent ce problème. Pour exemple, il suffit d'utiliser un logiciel tel que Paint .NET, de selectionner un contenu et de le recopier dans Open Office.

Pour contourner ce  probleme, il suffit de faire comme suit:

   System.Collections.Specialized.StringCollection Maliste = new System.Collections.Specialized.StringCollection();
           Maliste.Add(MonImage); // MonImage represente le chemin complet vers l'image 
           Clipboard.SetFileDropList(Maliste);

 Et voila. Le tout fonctionnant a merveille. L'inconvénient dans cette solution est qu'il faut recopier un copie de l'image sur le disque dur pour pouvoir la mettre en tant que lien dans le ClipBoard. Mais c'est un inconvénient minime en comparaison a ce que l'on peut en retirer.

 

Dans le cadre d’un développement d’une application, on essaie tant bien que mal de gérer l’ensemble des exceptions qui peuvent survenir lors de l’utilisation d’une application. Cependant, nous ne sommes jamais à l’abri de l’utilisation hasardeuse que peut avoir l’utilisateur lambda (pour pas dire béta).

Aussi, il n’est pas rare de voir apparaitre ce genre de message assez agaçant pour le développeur, car il ne peut rien faire d’autre que de subir le message « banal » de Windows.

 

Cependant, il existe une parade à ce message.

En effet, il serait fort intéressant de pouvoir personnaliser ce message pour le rendre plus attractif, ou tout simplement de masquer ce message pour faire croire à l’utilisateur que tout marche pour le mieux. Nous verrons la première approche, car Windows de base connait très bien la seconde approche.

 

namespace WindowsApplication5

{

    static class Program

    {

        /// <summary>

        /// Point d'entrée principal de l'application.

        /// </summary>

        [STAThread]

        static void Main()

        {

            Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);

            Application.EnableVisualStyles();

            Application.SetCompatibleTextRenderingDefault(false);

            Application.Run(new Form1());

        }

        /// <summary>

        /// Methode de gestion de l'erreur

        /// </summary>

        /// <param name="sender"></param>

        /// <param name="e"></param>

        static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)

        {

            //On affiche ici la fenetre personnalisée

            FRM_Erreur maForm = new FRM_Erreur();

            maForm.ShowDialog();

        }

    }

}

Il suffit donc de s’abonner à l’evenement d’erreur de l’application. Cet evenement sera levé lorsqu’une erreur non gérée sera apparue.

FRM_Erreur dans ce cas, sera une simple fenetre montrant un label. Il peut tout a fait etre envisageable de faire passer l’exception a la fenetre pour afficher un detail de l’erreur.

Bon tres bien, nous avons donc une erreur qui est geré. Suite à cette gestion, on peut facilement imaginer des améliorations possibles  : Envoyer un mail à l'administrateur pour l'avertir du probleme, Faire une impression écran du moment de l'erreur pour l'envoyer avec le mail (pour que l'administrateur puisse reproduire la suite d'action qui a pu amener au problème). Mais tout ceci est une autre histoire