Libraries: MT4Orders QuickReport - page 7

New comment
 
Forester #:
I have done all this.
Added 2 new parameters to the call
common_path - save to common terminal folder. To prevent files from being overwritten by another agent during optimisation, the agent number (3000, 3001,...) is added to the file names. When saving in the tester folder (false), they are saved in the folder of the agent that performed the calculations.
fileANSI - save in ANSI encoding or in UNICODE. The size of UNICODE files is 2 times larger and they take longer to process, so if you upload a lot of data, for example 1 GB, it is more economical to use ANSI. UNICODE is added for compatibility with third-party services if you need it.

Character checker and hide button are also added, but I didn't describe them.

Thank you for your prompt improvements!

By saving in UTF-8 I meant the library source itself. I store all the codes on the git, so I can easily roll back to the required version or find the point of the bug.
So, the git (and some other applications and services) does not perceive the default encoding of ME (UCS-2) as text, so I save all the codes in UTF-8. ME does not change encoding after that, so this is a one-time action.
Well, with third-party codes (fxsaber's, yours), I have to change encoding when each new version is released. That's why I asked for a change.

I use AkelPad (comes with TotalComander) to convert single files, and for group encoding change I found DS text converter utility (but I can't recommend it, because I don't have sources).

Thanks again for the update!

 
Andrey Khatimlianskii #:

I have to change the encoding every time a new version comes out.

For a long time I posted sources in UTF-8 in KB. Several people asked me not to do so, because of some problems. I stopped.
 
fxsaber #:
For a long time I posted sources in UTF-8 in KB. Several people asked not to do so, because of some problems. I stopped.

It would be interesting to know what "problems". Perhaps the first comparison with the previous version of UCS-2 did not work? Well, it's better to give up UCS-2 once and forget the eel like a bad dream.

 
Forester #:
button to hide

Hide Chart does not work with the default chart (not Highcharts). But I don't need them, I connected Highcharts right away.

The rest works.

 
Andrey Khatimlianskii #:

Hide Chart does not work with the default chart (not Highcharts). But I don't need them, I connected Highcharts right away.

The rest works.

Button corrected for Google chart.

I have doubts about UTF8 for the source itself....
Notepad++ shows the source as UTF-16 LE with BOM

I have no idea what it is and what variant you need. If you have already got used to convert all codes to the form you need, I think it is better to do it this way.
All the more that there may be problems.

Maybe with compilation of other codes in native encoding and library in non-native?
I tried to convert to UTF-8 c BOM - compiled normally.

Downloaded in UTF-8 c BOM
 

replace Highcharts with Lightweight charts (and there are few edits there) - maybe then MQ will realise that they should move instead of building new compilers.

just for the JS library of a direct competitor. Otherwise it's not very clear

 
Maxim Kuznetsov #:

replace Highcharts with Lightweight charts (with only a few changes) - maybe then MQ will realise that it is necessary to move rather than build new compilers.

just for the JS library of a direct competitor. Otherwise it's not very clear

It would be very cool if MQ had a handy HTML data visualisation library based on JS libraries.

It could even be based on ALT+E-report, if you understand the HTML code of the export of this not bad in terms of interactivity report.


I myself, for example, am a complete zero in HTML and JS. Probably, I am not the only one. But it would be possible to achieve very good visualisations in Products, etc.

 
Forester #:

Button corrected for Google chart.

I have doubts about UTF8 for the source itself....
Notepad++ shows the source as UTF-16 LE with BOM

I have no idea what it is and what variant you need. If you have already got used to convert all codes to the form you need, I think it is better to do it this way.
All the more that there may be problems.

Maybe with compilation of other codes in native encoding and library in non-native?
I tried to convert to UTF-8 c BOM - compiled normally.

Downloaded it in UTF-8 c BOM.

Great, thanks!

No, there are no problems with different encodings in different files. You just need to gradually resave all your sources in UTF-8, and forget about ME encoding like a bad dream.

This is how I see your recent changes:


And here's what I see if the encoding of one of the files ( old or new, doesn't matter), or both files -- UCS-2:


 
Andrey Khatimlianskii #:

Here's how I see your recent changes:

In TotalCommander I compare sources at the click of a key. There any encodings with any other are calmly compared.

 
fxsaber #:
In TotalCommander I compare sources at the press of a key. Any encoding can be easily compared with any other encoding.

Graphic file managers are for amateurs, of course. It's a matter of habit. I once moved from text-based NortonCommander to FarCommander, with a lot of plugins. Still not "only hardcore, only console".

And for comparing files I use WinMergeU, which also automatically distinguishes encodings, like all comparison tools, probably. Maybe there are better ones, I historically use these programs. If there is something better, I will listen with pleasure.

PS: off-topic, but at the same time I'll ask: I'm interested in a programme for playing two videos side by side, for frame-by-frame evaluation of quality difference.

12345678910
New comment