Bonjour,
Suite à ce message, je m’interroge sur ce que j’ai pu faire faux. Pourtant je pense n’avoir rien fait de différent de ce qui est proposé dans le plugin template.
Certains d’entre vous ont-ils déjà eu ce phénomène ? Ca se corrige comment ?
C’est lié à la config de l’utilisateur ?
A+
Michel
Salut,
Un log dans http.error?
Une erreur js?
Je n’ai pas vu le problème donc c’est au pif
De mémoire, un utilisateur avait déjà évoqué le soucis de rafraichissement, d’où ma question suite à l’appui sur F5. Cet utilisateur était sur RPI (pas un foudre de guerre, donc) et l’affichage des paramètres d’équipement (et seulement d’équipement, pas de soucis sur les paramètres de commande) était aléatoire.
Sur ma machine de dev (VM Syno, pas un foudre de guerre non plus, mais un cran au dessus en terme de perf) j’avais essayé plusieurs fois F5 et une fois de temps en temps (une fois sur vingt), j’ai eu le phénomène.
De mémoire toujours, je n’avais pas vu d’erreur http ni js.
Avant sauvegarde :
Puis il bascule sur les commandes, il sauvegarde et revient sur l’équipement où il a ceci :
Les seuls cas où j’ai eu des écrans vides c’est suite à un problème de js
L’onglet des commandes est rempli ou vide?
Il n’en parle pas, je suppose donc que les commandes ne sont pas impactées.
D’autant plus que les commandes restent affichées suite à la sauvegarde
Hello,
Je pense que c’est lié au load…
tous les eqLogicAttr sont déportés (Ex: eqConfig.php), ils sont initié par $('#div_MyModbusEqlogic').load('index.php?v=d&plugin=mymodbus&modal=eqConfig'); dans le fichier mymodbus.php. et je pense que des fois le core fait le setJeeValues alors que le plugin n’a pas encore chargé le contenu.
Comment on palie à ça ?
Une opération prend trop de temps ?
en faite avant load c’était du jquery et donc certainement méthode synchrone, maintenant c’est le Core qui gère ce load() , et par défaut cela semble être du Asynchrone :
Je confirme, je vient de laisser des log :
Quand pas de soucis :
Quand il y a soucis :
dans le 2ème cas, on voit bien le core set les valeur alors que le plugin n’a pas encore chargé le code des Eq.
Bravo (comme d’habitude) 
.
J’ai déjà expérimenté ce truc. Quand je pose une question à mon fils et que je réponds sans attendre sa réponse ça va beaucoup plus vite ! 
C’est donc un problème du core ?
Oui et non 
,
Oui, si il y a un comportement different entre 4.3 et 4.4.
Non, car je pense qu’il devrait pas y avoir de load() pour ce qui concerne les eqLogicAttr.
d’ailleurs dans la version stable, le problème n’existe pas car il n’y a pas de load sur les eqLogicAttr (data-l1key="name" …)
Dans la fonction printEqLogic voici la partie qui gère la partie dynamique de la config :
// Afficher la partie variable de la configuration de l'équipement en fonction du protocole choisi
$('.eqLogicAttr[data-l1key=configuration][data-l2key=eqProtocol]').off().on('change', function () {
if ($(this).val() != '' && !is_null($(this).val())) {
$('#div_protocolParameters').load('index.php?v=d&plugin=mymodbus&modal=eqConfig_' + $(this).val(), function () {
$('#div_protocolParameters').setValues(_eqLogic, '.eqLogicAttr');
});
}
});
// load values
$('#eqLogic').setValues(_eqLogic, '.eqLogicAttr');
J’ai repris le principe de ce qui est fait dans la version stable de MyModbus. C’est le load() dynamique qui pose problème ? Si c’est le cas, alors je résous cette partie dynamique avec des div visible ou pas, mais ça va créer les éléments de configuration de l’équipement. Ce qui n’est qu’un problème interne au plugin.
Y aurait-il plus propre comme solution ?
Ce load() permet de charger une partie dynamique de la configuration en fonction du type de connexion.
Ce load ne doit pas poser de soucis car il est dans le printEqlogic qui intervient après le SetValues du core, celui qui pose soucis c’est celui qui est dans le plugin.php, qui affiche le nom, id, catégorie…
plugin.php du core ou, dans mon cas, mymodbus.php ?
mymodbus.php, désolé je suis sur smarphone, j’ai pas pensé a préciser.
C’est déjà super sympa de répondre…
On m’avait déjà rapporté ce problème en 4.3 et c’était aléatoire, comme en 4.4
Bon j’ai compris l’histoire de l’ordre des appels, mais je ne sais pas comment résoudre ça.
Dans desktop/php/mymodbus.php :
load est fait pour afficher la config de l’équipement :$('#div_MyModbusEqlogic').load('index.php?v=d&plugin=mymodbus&modal=eqConfig');
eqConfig.php, il y a une section div dont le load est fait dans printEqLogic en fonction du type de connexion : // Afficher la partie variable de la configuration de l'équipement en fonction du protocole choisi
$('.eqLogicAttr[data-l1key=configuration][data-l2key=eqProtocol]').off().on('change', function () {
if ($(this).val() != '' && !is_null($(this).val())) {
$('#div_protocolParameters').load('index.php?v=d&plugin=mymodbus&modal=eqConfig_' + $(this).val(), function () {
$('#div_protocolParameters').setValues(_eqLogic, '.eqLogicAttr');
});
}
});
// load values
$('#eqLogic').setValues(_eqLogic, '.eqLogicAttr');
Comment se peut-il que le setValues qui est dans printEqLogic se fasse trop tôt ?
Cest encore autre chose, pas sur quen 4.4 cela fonctionne, je suis pas sur pc, mais je pense que setValues etait propre a la version <=4.3, je pense qu’elle n’existe même plus en 4.4, et quelle a ete remplacé par setJeeValues
Mais normalement c’est au core de faire les setJeeValues, le printEqlogic n’est pas fait pour ca a mon avis.
OK, je ferai l’essai.
Merci beaucoup !
Bon je suis sur pc c’est mieux ,
J’ai testé de désactiver le setJeeValues du core, et il semble que setValues présent dans le plugin fait le job, c’est peut-être une fonction native de jQuery, c’est pourquoi je ne retrouve pas dans le core 4.4…
Au final je pense qu’il faut juste que tu intègre eqConfig.php dans mymodbus.php directement dans div_MyModbusEqlogic