Discussion :

[Kropernic]

Hello,

Je me suis "amusé" à créer un usercontrol pour faire un agenda.

J'ai mis le projet en pièce jointe et j'aurais aimé avoir l'avis de la communauté. C'est un première pour moi ce genre de contrôles plus avancés alors y a sûrement des tonnes trucs à améliorer.

Merci d'avance pour les retours.

[mactwist69]

J'regarde ça entre à la pause déjeuner !!

[Kropernic]

Si nécessaire, j'peux mettre un p'tit projet d'exemple...

Si vous avez des questions, faut pas hésiter non plus.

[mactwist69]

J'arrive pas trop à le faire fonctionner....

[Kropernic]

Arf... Je te fais un p'tit projet de test alors ^^

[Kropernic]

Et voici un mini projet de démo.

Il est évident que je n'ai pas fait la partie qui va récupérer les rdv déjà existants dans un stockage vu que j'peux pas vous passer le stockage ^^.

J'espère que ce sera plus clair.

J'ai pas mis de commentaire (ou vraiment le strict minimum) mais j'ai tendance à faire du code auto commenté donc ça devrait aller normalement. Si question il y a, je suis là.

[mactwist69]

Il doit manqué une référence, il ne reconnait pas le type TimeFrame

il ne reconnait pas non plus : CalendarEventArgs.CalendarEventArgs
Ton imports Calendar... ça vient bien de System.Globalization.Calendar ?

[Kropernic]

Bah calendar, c'est mon agenda (nom p-e mal choisi )

Edit : j'ai compris le problème. En voulant aller vite, j'ai fait une référence vers la dll produite par mon projet Calendar au lieu de la copier dans un folder assembly dans le répertoire de la solution et de le fournir avec. Du coup, quand vous ouvrez le projet demo, bin il manque la référence ^^. Suffit de la supprimer et de la recréer vers le projet que j'ai passé.

[mactwist69]

Il est bien en référence... Mais il n'a pas l'air de le prendre en compte...
Y'a un souci quelque part.

Il craque déjà sur Imports Calendar...
Donc forcement il ne reconnait pas des types comme TimeFrame...

Pourtant la dll est bien importée...

Après, j'ai dû migrer le projet sur le Framework vers 4.5, y'aurait il un problème de compatibilité ?

[mactwist69]

Ah ok; je test

[Kropernic]

Etrange...

Je suis sur le framework 4.5.2 avec VS2015.

Est-ce que cela va mieux avec cette version-ci dans laquelle j'ai corrigé le problème de la référence.

[mactwist69]

Tu veux quel genre de retour ?

Bugs, idées, ergo ?

[Kropernic]

Bah tout ^^.

J'ai déjà remarqué que quand il y a la scroll bar au panel qui contient les timeframes, faut que je m'occupe du panel qui sert de header pour recentrer les noms des journées dans leur colonne...

[mactwist69]

Bon alors, le petit bug déjà, quand tu changes de semaine dans le calendrier à gauche, les dates en haut changent bien mais les appointments restent toujours là.

Après au niveau interface, j'imagine bien que c'est pas finis, mais quelques idées (en vrac désolé, et je suis peut être à côté du concept initiale)

-> Au niveau de la navigation du Calendrier principale :

Je verrais bien un bandeau au dessus du calendrier, qui rappelle le nom du mois (l'année?) (dans des combobox?), le numéro de semaine et deux jolies boutons à gauche et à droite pour naviguer entre les semaines. En gros : 99% du temps, le calendrier correspond à la semaine en cours, et on navigue rapidement d'une semaine en avant ou arrière...

Et en dessous : Plutôt qu'un richtextbox qui prends tout l'espace avec toutes les infos (heure) (et qui ne mémorise pas les changements)
Faudrait faire un petit panel jolie avec les heures dans des combobox (pour pouvoir modifier), et le text dans un richtextbox, moins grand, et un bouton pour sauvegarder d'éventuelle changements.



-> Quand on ajoute un rdv, moi je verrais plutôt deux façons :

1) Soit on ajoute un rdv dans la semaine en cours (90% du temps), ou dans les semaines autour.

Donc on navigue jusqu'à une date précise, on affiche le petit formulaire via le clique droit (ou double clique?). Dans ce petit formulaire je pense qu'il serait plus facile de n'afficher que les heures grâce à 4 combobox (formater sur les plages), heure+minute, en deux cliques on a choisi les créneau, on ajoute juste le texte et c'est finis.

Sachant qu'on avait cherché la semaine, puis cliquer sur le jour, la moitié du boulot était déjà fait, je pense pas que la sélection du jour soit bien dans cette fenêtre. L'utilisateur est "trop" libre. Parce que là on peut choisir l'heure, mais aussi le jour... d'ailleurs en théorie, on peut mettre un rdv sur plusieurs jours, je sais pas ce que ça fait.


2) soit on veut ajouter un rdv a une date précise (lointaine?) sans vouloir s'y rendre avec notre calendrier principal.

Et c'est là que le calendrier à gauche servirai. Certes pour l'instant il peut permettre de changer la date du jour dans le calendrier principal, mais bon.. si tu gardes l'idée d'une navigation rapide par bandeau, du coup tu pourrais te faire un espace sur le côté pour faire un ajout de rdv, sans devoir se rendre à la date.

Par exemple tu prends un groupbox que tu nomme "ajout libre", tu sélectionne une date, tu rentre un texte, tu sélectionne des heures (combobox), et un bouton ajouter. Ca viendra ajouter ton rdv (lointain) sans s'y rendre.

D'ailleurs je crois que sur un calendar de ce type on peut changer le BAckColor de certaines date (pour dire qu'il y a des rdv ?
Du coup il aurait un double rôle : une vue sur le mois, et l'ajout libre de rdv


Bon c'est déjà beaucoup de chose, ça doit être pleins de fautes de français...

[Pol63]

pas tout lu les retours de mactwist, donc peut etre de la redondance

ergonomie :
le clic droit c'est un peu dépassé (quoi que)
double clic sur une case pour ajouter un truc ca serait pas mal
quand on sélectionne une case, afficher les boutons edit et delete sur le textbox en bas

le textbox en bas devrait etre readonly (mais pas gris pour autant)

possibilité de sélectionner plusieurs cases en hauteur puis faire entrée pour ajouter un truc avec déjà la bonne plage horaire (de la sélection) pour les choses qui durent plus d'une case

ajouter un bouton pour ajouter un truc quelque part, car des fois on veut rajouter un truc pour une date loin, mais on a pas envie d'aller sur la semaine (donc le truc d'ajout doit préciser la date entière)

choix de la couleur des rdv ca serait bien (et/ou une catégorie qui a une couleur par défaut)


bugs :
j'ai eut un crash (pas eut le temps de regarder où, mais ca doit être sur le calendar.changed

les parametres à droite j'ai pas compris, ca ne prend pas 30 minutes par exemple

bug en effet sur les trucs qui restent alors que c'est pas la bonne semaine



code :
ca manque de try catch (et ca c'est vu du coup)

cbDay.DisplayMember = "ToString" : pas utile, de plus displaymember ne fonctionen qu'avec les propriétés, tostring est une function (et sans la ligne ca marche pareil car une enum est affichée en string)

ca manque de POO !
Public Sub New(startTime As TimeSpan, endTime As TimeSpan, day As DayOfWeek, editmode As EditMode, Optional comment As String = "")
non on fait une classe appointment avec ces propriétés (sauf editmode) pour l'édition on passe l'instance, pour le new on instancie une classe en lui mettant juste les dates en fonction de la case où on est, ca fait moins de code

on a pas le code source du calendar, il y aurait peut etre des choses à voir dessus (mais le décompilateur ca ressemble pas assez au code d'origine je pense)

[Kropernic]

Bon alors, le petit bug déjà, quand tu changes de semaine dans le calendrier à gauche, les dates en haut changent bien mais les appointments restent toujours là.

J'ai fait le choix que ce ne soit pas le contrôle qui décide lui-même s'il faut clear la liste des données sources ou non. C'est pour ça qu'il y a un événement CalendarDateChanged dans lequel le développeur peut décider ce qu'il doit faire. J'y ai d'ailleurs indiqué dans le projet test que c'était là qu'il fallait récupérer les données dans le système de stockage pour les passer ensuite au calendar sous forme de dictionnaire de (jour, timeframe).

It's not a bug, it's a feature .

Après au niveau interface, j'imagine bien que c'est pas finis, mais quelques idées (en vrac désolé, et je suis peut être à côté du concept initiale)

Ce n'est effectivement pas fini mais les idées sont les bienvenues. C'est pour ça que la discussion est faite

-> Au niveau de la navigation du Calendrier principale :

Je verrais bien un bandeau au dessus du calendrier, qui rappelle le nom du mois (l'année?) (dans des combobox?), le numéro de semaine et deux jolies boutons à gauche et à droite pour naviguer entre les semaines. En gros : 99% du temps, le calendrier correspond à la semaine en cours, et on navigue rapidement d'une semaine en avant ou arrière...

Ca pourrait s'envisager. J'vais avoir du temps à tuer les semaines qui viennent donc ça doit pouvoir se faire ^^

Et en dessous : Plutôt qu'un richtextbox qui prends tout l'espace avec toutes les infos (heure) (et qui ne mémorise pas les changements)
Faudrait faire un petit panel jolie avec les heures dans des combobox (pour pouvoir modifier), et le text dans un richtextbox, moins grand, et un bouton pour sauvegarder d'éventuelle changements.

Là je suis moins d'accord. Enfin, c'est fonction de mes utilisateurs aussi. Je développe uniquement en interne donc mes utilisateurs, je les connais. Si je mets des boites en bas pour une modification des plages horaires plus faciles/rapides, ça va être le bordel car ils vont modifier des trucs qu'ils ne voulaient pas modifier et le truc qui devait être modifier restera inchangé. Si si, j'vous jure !

-> Quand on ajoute un rdv, moi je verrais plutôt deux façons :

1) Soit on ajoute un rdv dans la semaine en cours (90% du temps), ou dans les semaines autour.

Donc on navigue jusqu'à une date précise, on affiche le petit formulaire via le clique droit (ou double clique?). Dans ce petit formulaire je pense qu'il serait plus facile de n'afficher que les heures grâce à 4 combobox (formater sur les plages), heure+minute, en deux cliques on a choisi les créneau, on ajoute juste le texte et c'est finis.

Sachant qu'on avait cherché la semaine, puis cliquer sur le jour, la moitié du boulot était déjà fait, je pense pas que la sélection du jour soit bien dans cette fenêtre. L'utilisateur est "trop" libre. Parce que là on peut choisir l'heure, mais aussi le jour... d'ailleurs en théorie, on peut mettre un rdv sur plusieurs jours, je sais pas ce que ça fait.


2) soit on veut ajouter un rdv a une date précise (lointaine?) sans vouloir s'y rendre avec notre calendrier principal.

Et c'est là que le calendrier à gauche servirai. Certes pour l'instant il peut permettre de changer la date du jour dans le calendrier principal, mais bon.. si tu gardes l'idée d'une navigation rapide par bandeau, du coup tu pourrais te faire un espace sur le côté pour faire un ajout de rdv, sans devoir se rendre à la date.

Par exemple tu prends un groupbox que tu nomme "ajout libre", tu sélectionne une date, tu rentre un texte, tu sélectionne des heures (combobox), et un bouton ajouter. Ca viendra ajouter ton rdv (lointain) sans s'y rendre.

D'ailleurs je crois que sur un calendar de ce type on peut changer le BAckColor de certaines date (pour dire qu'il y a des rdv ?
Du coup il aurait un double rôle : une vue sur le mois, et l'ajout libre de rdv


Bon c'est déjà beaucoup de chose, ça doit être pleins de fautes de français...

T'inquiète pas pour les fautes de français, j'ai déjà vu/fait pire ^^.

Sinon, concernant comment le rdv est ajouté, à nouveau, ce n'est pas le contrôle qui décide de comment on fait. C'est le développeur qui utilise le contrôle qui s'en charge. Le Calendar, lui, demande juste que, pour insérer un rdv, on utilise la méthode InsertTimeFrame ([Edit/Delete]TimeFrame pour respectivement l'édition et la suppression).

Alors oui dans le projet test j'ai fait via un clic droit et menu contextuel mais rien n'empêche de faire autrement. Par contre c'est vrai qu'il manque des events. Genre le double-clic sur une plage horaire par exemple histoire que le développeur (cad moi ou mon futur collègue) puisse laisser libre cours à son imagination sur ce qu'il veut [en] faire.

pas tout lu les retours de mactwist, donc peut etre de la redondance

ergonomie :
le clic droit c'est un peu dépassé (quoi que)
double clic sur une case pour ajouter un truc ca serait pas mal
quand on sélectionne une case, afficher les boutons edit et delete sur le textbox en bas

clic droit : Ah bon ? J'aime bien mois ça... Puis dans Windows, le clic droit, c'est courant pourtant non ?
double clic : Un event sur le double-clic manque, on est d'accord.
des boutons de CRUD pourraient avoir leur place en effet.

le textbox en bas devrait etre readonly (mais pas gris pour autant)

C'est pas faux !

possibilité de sélectionner plusieurs cases en hauteur puis faire entrée pour ajouter un truc avec déjà la bonne plage horaire (de la sélection) pour les choses qui durent plus d'une case

Je n'avais pas envisagé que cela pourrait être un besoin. Mais pourquoi pas. Juste pour le défi car j'vais devoir réfléchir à comment renvoyer l'info. Comme déjà dit, c'est mon premier contrôle un peu complexe.

ajouter un bouton pour ajouter un truc quelque part, car des fois on veut rajouter un truc pour une date loin, mais on a pas envie d'aller sur la semaine (donc le truc d'ajout doit préciser la date entière)

Comme déjà dit, le calendrier demander juste sa timeframe pour l'ajout. Par contre, à force de le dire, je me rends compte que ce n'est pas tout à fait exacte. Car à côté de la timeframe, il ne demande que le jour de la semaine et pas une date. Je vais donc ajouter cela comme paramètre à la méthode InsertTimeFrame et on pourra insérer où on veut. Après, le formulaire pour l'insertion n'est pas gérer par le contrôle donc osef j'ai envie de dire. Non ?

choix de la couleur des rdv ca serait bien (et/ou une catégorie qui a une couleur par défaut)

Ca c'est déjà dans ma todo list. Juste que j'ai encore jamais fait donc je gardais pour plus tard.

bugs :
j'ai eut un crash (pas eut le temps de regarder où, mais ca doit être sur le calendar.changed

Ah ? Ce serait cool que t'arrives à le reproduire et à me dire comment. Car j'ai plus eu de crash depuis pas mal de temps avec.

les parametres à droite j'ai pas compris, ca ne prend pas 30 minutes par exemple

Ouais, c'est p-e pas super clair ces machins-là ^^. C'était encore du provisoire donc pas très explicite. Voici l'explication :

• Time's height (60 min) : Définit la hauteur d'une heure en pixel. Histoire que, si on n'a par exemple que 5h à afficher, on peut mettre plus grand par exemple. Ce nombre doit être un multiple de "Minimum minutes in a timeframe" sinon quand on a des rdv qui ne sont pas des heures entières, ça fait décalage d'un pixel lors du calcul de la taille d'un rdv.
• Minimum minutes in a timeframe : Définit la durée minimal d'un rdv. Je dois vérifier mais il me semble que le contrôle arrondi les plages horaires (12h12 --> 12h15 par exemple si ce paramètre vaut 15)
• Start hour : Heure de début d'affichage
• End hour : Heure de fin d'affichage

bug en effet sur les trucs qui restent alors que c'est pas la bonne semaine

It's not a bug, it's a feature (voir plus haut )

code :
ca manque de try catch (et ca c'est vu du coup)

Ouip, c'est pas fini. C'était le check-up de mi-parcours pour voir si j'étais sur la bonne route ou pas. Vu que je n'ai pas eu droit à un lynchage en règle, j'en déduis que c'est acceptable .

cbDay.DisplayMember = "ToString" : pas utile, de plus displaymember ne fonctionen qu'avec les propriétés, tostring est une function (et sans la ligne ca marche pareil car une enum est affichée en string)

T'es sûr de ça ? Pcq'avec des classes custom dont je donne parfois une liste en datasource d'un contrôle ou l'autre (combobox, etc.), si je ne mets rien, ça affiche le nom de la classe (ou alors je me fourvoie depuis 2 ans lol). Si je mets "ToString" en DisplayMember, ça affiche bien ce que la fonction renvoie. Du coup, p-e pas utile pour une enum mais par habitude, je l'ai fait.

ca manque de POO !
Public Sub New(startTime As TimeSpan, endTime As TimeSpan, day As DayOfWeek, editmode As EditMode, Optional comment As String = "")
non on fait une classe appointment avec ces propriétés (sauf editmode) pour l'édition on passe l'instance, pour le new on instancie une classe en lui mettant juste les dates en fonction de la case où on est, ca fait moins de code

Ca j'aimerais vraiment qu'on en parle. Jamais eu de cours de POO moi. J'ai tout appris sur le temps pendant mes heures creuses au boulot (et en expérimentant sur les nouveaux projets). Du coup, ce genre de "détails" m'intéressent super fort. Personnellement, je partais du fait que le calendrier gère des plages horaires. Que ce soit des rendez-vous ou autre, on s'en tappe. Du coup, j'ai créé la classe TimeFrame (qui est en même temps un usercontrol pour s'afficher correctement). S'il faut créer une classe Appointment avec les propriétés d'une TimeFrame pour la passer au constructeur de TimeFrame, je comprends pas l'intérêt. C'est juste déplacer le code ailleurs non ?

on a pas le code source du calendar, il y aurait peut etre des choses à voir dessus (mais le décompilateur ca ressemble pas assez au code d'origine je pense)

[/QUOTE]
Euh si... Le code source du calendar est dans la discussion. C'est justement le but lol. Ou alors on ne parle pas du même calendar (surtout que tu donne le constructeur de la classe TimeFrame qui est dans le projet Calendar ) ^^.


Voilàààààààààà. Je pense que j'ai répondu à tout. Je vais de ce pas m'attaquer aux modifs sur lesquels nous sommes tous d'accord et pour le reste, on en discute autour d'une bière.

[Kropernic]

ajouter un bouton pour ajouter un truc quelque part, car des fois on veut rajouter un truc pour une date loin, mais on a pas envie d'aller sur la semaine (donc le truc d'ajout doit préciser la date entière)

Comme déjà dit, le calendrier demander juste sa timeframe pour l'ajout. Par contre, à force de le dire, je me rends compte que ce n'est pas tout à fait exacte. Car à côté de la timeframe, il ne demande que le jour de la semaine et pas une date. Je vais donc ajouter cela comme paramètre à la méthode InsertTimeFrame et on pourra insérer où on veut. Après, le formulaire pour l'insertion n'est pas gérer par le contrôle donc osef j'ai envie de dire. Non ?

Par raport à ceci. J'étais en train d'y réfléchir et en fait non, il ne faut pas la date.

Comme déjà, le formulaire de création de rdv ou autre (peu importe ce qu'on crée du moment que ça se représente dans une instance de TimeFrame) est à charge du développeur qui utilisera ce usercontrol. Il peut donc ajouter un DateTimePicker par exemple pour choisir une date plus ou moins loin dans le futur.

Quand son utilisateur a bien tout compléter et qu'il valide le fomulaire, le développeur va donc stocker son rdv dans sa DB (ou un autre support, osef ^^) et, si nécessaire (cad si la date du rdv est dans la semaine en cours), le passer à mon usercontrol qui lui n'a besoin que du jour et de la timeframe.

Le usercontrol n'a "en mémoire" (sa propriété TimeFrames), que la semaine en cours. Si on change de semaine, le développeur doit lui passer les rdv correspondant à la nouvelle semaine.

J'aurais pu faire en sorte qu'on puisse lui passer directement toute une année de rdv planifier et qu'il se démerde mais ce n'est pas l'orientation que j'ai prise en démarrant. Y a des pour et contres mais bon, c'est comme dans tout je pense.

[Kropernic]

@Pol : J'ai trouvé le plantage sur le changement de date dans le monthcalendar. Ca merde quand on choisit un dimanche ^^. Donc plus la peine que tu cherches à reproduire, c'est fait ! A moins que ce soit encore autre chose

[Pol63]

les controles "liste" du framework (combobox, listbox ...) quand tu leur donnes des classes dans .items et que tu ne leur donne pas de datasource et de displaymember ils appellent automatiquement .ToString
quand ca affiche le nom de la classe c'est que le ToString n'est pas surchargé, par défaut dans le framework ToString affiche le type de la classe

avec un datasource, je ne suis pas sur que le tostring est appelé (à testé) et ca me paraitrait étrange qu'avec tostring en displaymember ca fonctionne, mais pourquoi pas

POO : pas une classe appointment avec les même propriétés que ton timeframe, ca serait en effet idiot, tu peux alors faire une propriété as TimeFrame directement
ou encore mieux si tu veux que plusieurs trucs puissent avoir un timeframe, de l'héritage ou une interface, genre apppointment hérite de timeframe
avec ca tu peux avoir une collection de timeframe, et mettre dedans des appointment ou autre, étant donné qu'ils ont tous les propriétés d'un timeframe ton calendar pourra les manipuler

(concernant le calendar, il y a bien une dll externe en référence, et je ne crois pas avoir le controle avec les cases dans le code source)

[Kropernic]

les controles "liste" du framework (combobox, listbox ...) quand tu leur donnes des classes dans .items et que tu ne leur donne pas de datasource et de displaymember ils appellent automatiquement .ToString
quand ca affiche le nom de la classe c'est que le ToString n'est pas surchargé, par défaut dans le framework ToString affiche le type de la classe

avec un datasource, je ne suis pas sur que le tostring est appelé (à testé) et ca me paraitrait étrange qu'avec tostring en displaymember ca fonctionne, mais pourquoi pas

Je vais aller faire joujou avec tout ça et donné un état des lieux ^^

POO : pas une classe appointment avec les même propriétés que ton timeframe, ca serait en effet idiot, tu peux alors faire une propriété as TimeFrame directement
ou encore mieux si tu veux que plusieurs trucs puissent avoir un timeframe, de l'héritage ou une interface, genre apppointment hérite de timeframe
avec ca tu peux avoir une collection de timeframe, et mettre dedans des appointment ou autre, étant donné qu'ils ont tous les propriétés d'un timeframe ton calendar pourra les manipuler

Dans le projet pour lequel j'ai créé ce usercontrol (un exercice de création de soft pour gestion de cabinet vétérinaire), j'ai bien une classe appointment et une méthode pour la "convertir" en timeframe histoire de la passer au calendar. Juste que dans le projet test que j'ai filé, c'est à l'arrache juste pour montrer comment utiliser le calendar pour que vous puissiez jouer avec.

(concernant le calendar, il y a bien une dll externe en référence, et je ne crois pas avoir le controle avec les cases dans le code source)

Dans le premier message, il y a une pièce jointe nommée calendar.rar qui est le code source du usercontrol. Sauf que maintenant, il n'est déjà plus à jour vu que j'ai corrigé quelques unes des suggestions de Mactwist et toi. Mais ça te donnera une idée. Là je suis sûr que tu vas avoir plein de chose à dire sur la façon dont c'est fait. Ca ne devrait sûrement pas être fait comme ça ^^.