Un bug a été signalé, concernant le positionnement du planning lors de son alimentation, suite à la mise en place de la barre de mois fixe. Ce bug sera corrigé rapidement.
Le bug est maintenant corrigé, permettant un positionnement correct du planning, lors de l'insertion d'événements.
Un deuxième bug, concernant toujours cette barre de mois fixe, apparaissait sur smartphone. Le dernier jour du mois était décalé, c'est maintenant corrigé.
Bonjour Bob,
J'ai toujours ce problème de décalage entre la barre du mois et les évènements... Je suis sous Chrome, est-ce qu'il y a un lien ?
Bonjour,
Votre écran est dans quelle résolution ? pouvez-vous me faire parvenir une copie d'écran de votre planning en MP.
Merci.
Je suis en 1680X1050
(https://i.imgur.com/YdpSr.png)
Effectivement c'est flagrant :o
Pouvez-vous nettoyer l'historique de votre navigateur, et rafraichir la page via la touche F5 ?
Pouvez-vous essayer avec un autre navigateur, IE9 ou Firefox 18 ... ?
En principe Chrome est justement recommandé, comme Firefox par ailleurs.
Tenez-moi au courant.
je confirme le même problème ce jour sous safari, malgré avoir effacé historique et relancé le mac
Ca y est j'ai compris... Le décalage survient quand on zoom sur le planning ! A 100% pas de problème, à 110% ça décale... ;-)
pour ma part pas de zoom, cela survient sur les 2 derniers groupes
Citation de: Loïc le Mardi 15 Janvier 2013 - 11:35
Ca y est j'ai compris... Le décalage survient quand on zoom sur le planning ! A 100% pas de problème, à 110% ça décale... ;-)
Effectivement, ça doit être l'explication.
Citation de: Geoffroy le Mardi 15 Janvier 2013 - 11:44
pour ma part pas de zoom, cela survient sur les 2 derniers groupes
Bonjour Geoffrey,
Pouvez-vous me faire parvenir une copie d'écran, merci ?
impossible à faire parvenir trop lourde la capture d'écran
Par e-mail peut-être ?
Bien reçu, et c'est effectivement décalé !
Ca le fait depuis longtemps ? Est-ce que le problème apparait lorsque les groupes ne sont pas masqués ?
Essayez CTRL 0 pour mettre la page à 100%
Le bug et corrigé. Le problème survenait lors du masquage d'un ou de plusieurs groupes ;)
cool, merci ;)
J'ai testé
sur iPhone, 3 remarques:
Avec Safari pas de problème.- La barre des dates toujours visible super ... mais serait-ce (oui !) possible avec la colonne des noms ? Quand on glisse à gauche les noms disparaissent.
- Avec un autre navigateur iPhone nommé "Mercury" la barre des dates reste complètement fixe et ne se déplace pas avec la grille de gauche à droite ! Donc les évènements ne correspondent pas du tout aux dates ???
Mais enfin ... c'est un détail, ça fonctionne bien avec Safari sur iPhone ... mais je reviens sur la taille des cellules ...
même sur smartphone ça reste trop petit à lire !
J'ai rayé la mention concernant Safari dans le précédent post car en fait la barre des dates se déplace entièrement avec la grille, comme si rien n'était fait.
Donc avec Safari ça ne marche pas, aucun blocage de la barre et avec Mercury blocage sur 2 axes alors que seul le vertical devrait l'être ...
En fait, la plupart des navigateurs sous smartphone ne gèrent pas ou mal la propriété CSS position:fixed, permettant de fixer un élément, entre autre l'entête du planning. Pour contourner le problème, la solution la plus simple a été de détecter le type de terminal (via le User Agent) et de désactiver cette propriété CSS.
Un autre problème vient du User Agent, ne permettant pas de détecter finement le type de mobile.
Cette barre fixe, qui à priori paraît simple, a demandé une 20aine d'heures de travail, avec des résultats incertains sur quelques navigateurs, la colonne des ressources restera donc en l'état ;)
Avec Safari donc la barre n'est pas fixe.
Quel user agent serait fonctionnel ? Car avec Mercury on peut définir le user agent ;)
En fait je me base sur le User Agent pour désactiver la barre fixe, si vous le modifiez il y a des chances que la barre soit fixe mais avec un alignement incertain avec le corps du tableau.
function mobile ()
{
if (isset($_SERVER['HTTP_X_WAP_PROFILE']) || isset($_SERVER['HTTP_PROFILE']))
return true;
if (isset ($_SERVER['HTTP_ACCEPT']))
{
$accept = strtolower($_SERVER['HTTP_ACCEPT']);
if (strpos($accept, 'wap') !== false)
return true;
}
if (isset ($_SERVER['HTTP_USER_AGENT']))
{
if (strpos ($_SERVER['HTTP_USER_AGENT'], 'Mobile') !== false)
return true;
if (strpos ($_SERVER['HTTP_USER_AGENT'], 'Opera Mini') !== false)
return true;
if (strpos ($_SERVER['HTTP_USER_AGENT'], 'MSIE 7.0') !== false)
return true;
}
return false;
}
Opera sous Iphone doit certainement initialiser cette variable : $_SERVER['HTTP_X_WAP_PROFILE'].
Pouvez-vous me transmettre votre User Agent, je modifierai la fonction en conséquence, nous pourrons ainsi valider (ou non) cette barre fixe sur Iphone, d'avance merci.
Voici le User Agent de mon iPhone 4S sous IOS 6.0.1 et Safari :
Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A523 Safari/8536.25
Et voici celui de Mercury toujours avec mon iPhone 4S IOS 6.0.1 :
Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Mercury/7.2 Mobile/10A523 Safari/8536.25
Avec Safari et Mercury (réglé sur son propre UA) : La barre est liée à la grille et se déplace avec.
Avec Mercury avec UA défini comme IE8 ou Opéra ou Chrome : La barre est fixe et toujours visible et la grille se déplace indépendamment sur les 2 axes.
Donc problème, il faudrait que l'axe horizontal soit lié à la grille afin que la barre des dates se déplace de gauche à droite avec la grille pour ne pas décaler les dates !
Bonjour,
Merci pour les infos, je me renseigne concernant cette variable $_SERVER['HTTP_X_WAP_PROFILE'] et modifierai la fonction en conséquence.
Les UA communiqués l'ont été en utilisant $_SERVER['HTTP_USER_AGENT']
En utilisant $_SERVER['HTTP_X_WAP_PROFILE'] j'obtiens une chaine vide (ou même non définie (pas testé).
Apparemment WAP profil est un lien qui dirige vers un fichier xml décrivant le mobile. WAP profil nécessite JQuery mobile.