Bibliothèque: MT4Orders QuickReport - page 7

 
Forester #:
J'ai fait tout cela.
Ajout de 2 nouveaux paramètres à l'appel
common_path - enregistrer dans le dossier commun du terminal. Pour éviter que les fichiers ne soient écrasés par un autre agent pendant l'optimisation, le numéro de l'agent (3000, 3001,...) est ajouté aux noms des fichiers. En cas d'enregistrement dans le dossier du testeur (false), ils sont enregistrés dans le dossier de l'agent qui a effectué les calculs.
fileANSI - enregistrer en encodage ANSI ou en UNICODE. La taille des fichiers UNICODE est deux fois plus importante et leur traitement est plus long. Par conséquent, si vous téléchargez beaucoup de données, par exemple 1 Go, il est plus économique d'utiliser l'encodage ANSI. L'UNICODE est ajouté pour des raisons de compatibilité avec des services tiers si vous en avez besoin.

Un vérificateur de caractères et un bouton de masquage ont également été ajoutés, mais je ne les ai pas décrits.

Merci pour vos améliorations rapides !

En sauvegardant en UTF-8, je voulais parler de la source de la bibliothèque elle-même. Je stocke tous les codes sur le git, ainsi je peux facilement revenir à la version requise ou trouver le point du bug.
Donc, le git (et quelques autres applications et services) ne perçoit pas l'encodage par défaut de ME (UCS-2) comme du texte, donc je sauvegarde tous les codes en UTF-8. ME ne change pas d'encodage après cela, donc c'est une action unique.
Eh bien, avec les codes tiers (ceux de fxsaber, les vôtres), je dois changer d'encodage à chaque nouvelle version. C'est pourquoi j'ai demandé un changement.

J'utilise AkelPad (livré avec TotalComander) pour convertir les fichiers individuels, et pour le changement d'encodage de groupe, j'ai trouvé l'utilitaire DS text converter (mais je ne peux pas le recommander, car je n'ai pas les sources).

Merci encore pour la mise à jour !

 
Andrey Khatimlianskii #:

Je dois changer l'encodage à chaque nouvelle version.

Pendant longtemps, j'ai publié des sources en UTF-8 dans KB. Plusieurs personnes m'ont demandé de ne plus le faire, en raison de certains problèmes. J'ai donc arrêté.
 
fxsaber #:
Pendant longtemps, j'ai publié des sources en UTF-8 dans KB. Plusieurs personnes m'ont demandé de ne pas le faire, en raison de certains problèmes. J'ai donc arrêté.

Il serait intéressant de savoir de quels "problèmes" il s'agit. Peut-être que la première comparaison avec la version précédente d'UCS-2 n'a pas fonctionné ? Eh bien, il vaut mieux abandonner UCS-2 une fois et oublier l'anguille comme un mauvais rêve.

 
Forester #:
pour cacher

Hide Chart ne fonctionne pas avec le graphique par défaut (pas Highcharts). Mais je n'en ai pas besoin, j'ai connecté Highcharts tout de suite.

Le reste fonctionne.

 
Andrey Khatimlianskii #:

Hide Chart ne fonctionne pas avec le graphique par défaut (pas Highcharts). Mais je n'en ai pas besoin, j'ai connecté Highcharts tout de suite.

Le reste fonctionne.

Bouton corrigé pour Google chart.

J'ai des doutes sur UTF8 pour la source elle-même....
Notepad++ affiche la source comme UTF-16 LE avec BOM

Je n'ai aucune idée de ce que c'est et de la variante dont vous avez besoin. Si vous avez déjà pris l'habitude de convertir tous les codes dans la forme dont vous avez besoin, je pense qu'il vaut mieux procéder de cette manière.
D'autant plus qu'il peut y avoir des problèmes.

Peut-être avec la compilation d'autres codes en encodage natif et de la bibliothèque en encodage non natif ?
J'ai essayé de convertir en UTF-8 c BOM - compilé normalement.

Téléchargé en UTF-8 c BOM
 

remplacer Highcharts par Lightweight charts (et il y a peu d'éditions) - peut-être qu'alors MQ se rendra compte qu'il devrait bouger au lieu de construire de nouveaux compilateurs.

Il n'y a pas d'autre solution que d'utiliser la bibliothèque JS d'un concurrent direct. Sinon, ce n'est pas très clair

 
Maxim Kuznetsov #:

remplacer Highcharts par Lightweight charts (avec seulement quelques changements) - peut-être qu'alors MQ se rendra compte qu'il est nécessaire d'évoluer plutôt que de construire de nouveaux compilateurs.

Il n'y a pas de raison que MQ se contente d'un compilateur pour la bibliothèque JS d'un concurrent direct. Sinon, ce n'est pas très clair

Ce serait vraiment cool si MQ avait une bibliothèque de visualisation de données HTML pratique basée sur des bibliothèques JS.

Elle pourrait même être basée sur ALT+E-report, si vous comprenez le code HTML de l'exportation de ce rapport pas mal en termes d'interactivité.


Moi-même, par exemple, je suis un zéro absolu en HTML et JS. Je ne suis probablement pas le seul. Mais il serait possible de réaliser de très bonnes visualisations dans Produits, etc.

 
Forester #:

Bouton corrigé pour le graphique Google.

J'ai des doutes sur UTF8 pour la source elle-même....
Notepad++ affiche la source comme UTF-16 LE avec BOM

Je n'ai aucune idée de ce que c'est et de la variante dont vous avez besoin. Si vous avez déjà pris l'habitude de convertir tous les codes dans la forme dont vous avez besoin, je pense qu'il vaut mieux procéder de cette manière.
D'autant plus qu'il peut y avoir des problèmes.

Peut-être avec la compilation d'autres codes en encodage natif et de la bibliothèque en encodage non natif ?
J'ai essayé de convertir en UTF-8 c BOM - la compilation s'est déroulée normalement.

Je l'ai téléchargé en UTF-8 c BOM.

Très bien, merci !

Non, il n'y a pas de problème avec des encodages différents dans des fichiers différents. Il vous suffit de réenregistrer progressivement toutes vos sources en UTF-8, et d'oublier l'encodage ME comme un mauvais rêve.

C'est ainsi que je vois vos récents changements :


Et voici ce que je vois si l'encodage de l'un des fichiers ( ancien ou nouveau, peu importe), ou des deux fichiers -- UCS-2 :


 
Andrey Khatimlianskii #:

Voici comment je vois vos récents changements :

Dans TotalCommander, je compare les sources en cliquant sur une touche. Là, tous les encodages sont comparés calmement avec n'importe quel autre.

 
fxsaber #:
Dans TotalCommander, je compare les sources en appuyant sur une touche. N'importe quel encodage peut être facilement comparé à n'importe quel autre encodage.

Les gestionnaires de fichiers graphiques sont destinés aux amateurs, bien sûr. C'est une question d'habitude. Une fois, je suis passé de NortonCommander textuel à FarCommander avec de nombreux plugins. Ce n'est pas encore "seulement hardcore, seulement console".

Et pour comparer des fichiers, j'utilise WinMergeU, qui distingue aussi automatiquement les encodages, comme tous les outils de comparaison, probablement. Il y en a peut-être de meilleurs, j'utilise ces programmes depuis toujours. S'il y a mieux, j'écouterai avec plaisir.

PS : hors sujet, mais en même temps je demande : je suis intéressé par un programme pour lire deux vidéos côte à côte, pour une évaluation image par image de la différence de qualité.