3.2.8版text函数改用科学记数法带来的问题
以前正常工作的代码，在3.2.8版里结果不正常，换回老版又正常，最后发现是新版里Text函数转6位以上数值时，自动用了科学记数法，才导致问题的出现。例如，日期数值，4位年份+2位月份+2位日期，共8位数，用科学计数法后就只有6位有效数字：
日线级别上每个Bar的日期转文本输出到外部文件，源代码为FileAppend("C: \\Formula.log","CurrentBar="+Text(CurrentBar)+" Date="+Text(Date));
输出结果：
CurrentBar=19 Date=2.01004e+007
CurrentBar=20 Date=2.01004e+007
CurrentBar=21 Date=2.01004e+007
CurrentBar=22 Date=2.01005e+007
CurrentBar=23 Date=2.01005e+007
CurrentBar=24 Date=2.01005e+007
而在以前版本里，结果应该是：
CurrentBar=19 Date=20100428
CurrentBar=20 Date=20100429
CurrentBar=21 Date=20100430
CurrentBar=22 Date=20100504
CurrentBar=23 Date=20100505
CurrentBar=24 Date=20100506
本来将日期写数据库再读出后还能做精确到日的比较，现在有效位数只有6位，相应的比较只能精确到月了。
日期还好办，是定长格式的数值，大不了按照当年解决千年虫的思路逆向操作，减少位数，也能凑合着规避，但
如果记录的是绩效，就麻烦了：各位操作股指的，输赢应该都是上十万了吧？用科学记数法，起码除非绩效发生数量级的变化，否则都被抹平了。而且绩效这种数值，从0到无穷大，都有可能，用户没法自己在代码里打补丁，也不应该让用户打这种补丁。
同时必须考虑到，策略易是需要通过数据库与相应的图表互动的，而数据库里的记录只能用文本格式，数值和文本之间的转换非常频繁而重要。
现在，如果要使用新版，用户只好手工检查以往代码里每一处涉及6位数以上文本转换的部分，这样的工作量和隐患是用户无法承受的。不知道此次修改是否必须，至少留一个选项，让用户可以自行决定用哪种方式转换数值。
急盼回音！ 是个大问题，我发现程序有问题，就把新版删除了。现在回想应该是text（20100615）之类出的问题
这么严重的bug，策略易应该也不能正常运行啊，
新版是整么测试通过的？
强烈要求tb取消科学计数法。不然我们只有永不升级了。 问题很严重啊 TB的技术人员又要忙了 问题现在解决了，tb的效率很高啊。:lol 这个问题已经解决了，请重新下载安装包，或者下载以下dll，替换掉安装目录下的dll就可以了 多谢！！ Tb bug确实多。:L :L 下载试试！
页:
[1]