Errors, bugs, questions - page 723
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
and after deleting this variable the error again?
Yes. It is the same on 32 and 64 bits. And when I was searching for the reason, I put the whole fragments of methods, recently extended functionality, etc., into comments. - did not fix the problem.
The biggest inconvenience is repeating the same error in a smaller code to send to Service Desk.
By the way, test on another computer.
I have one laptop, so it gives out such errors and on such flat places, that I couldn't have thought at once.
He is like an experienced beta tester finds hidden bugs. And on other computers available to me the code works without errors.
The colour of object descriptions is independent of the style. Bug or a feature?
Is there a mobile version of the website?
The biggest inconvenience is repeating the same error in a smaller code to send to the service desk.
By the way, test on another computer.
In smaller code - no way. 32 and 64 bit terminals on different computers. But the problem is solved, at least this way. By the way, I added one more intermediate class to this hierarchy and removed the fake variable - everything works. Perhaps the EX5 protection has somehow triggered somewhere. Or the antivirus is picking up the signature. I have avast on all my machines. I will attach ex5 here, maybe it is the antivirus.
Well, then I'll add to my collection of bugs I've found in a couple of days.
64 bit version turned out to be a total crap in the 630 build. It crashes to pieces.
- And on transferring strings into function (string contents is replaced at the end by some previous trash from the same, or concatenation doubles, it's decided by itself for now. Before passing it, I assign the string from the function to the intermediate string variable).
- and when working with assignment NULL strings that are no longer NULL (here was an Access violation, this application in servicedesk hangs, but what do I say to your question "we do not repeat" - I do not know :)
- and on Request from wininet.dll (terminal closes in crash with an offer to send crash to Microsoft! Problem temporarily solved by changing the type of the passed parameter from string to int [] array)
- and on function from class CFastFile::ReadInteger(SHORT_VALUE) (at all it gives unclear values, at first reassigning result of reading array into intermediate variable helped, but then it failed too. And the main thing is that in debug-mode it never repeats.:)
- And the EA loading speed in 64 is three times slower than in 32 (a bit faster in debug mode).
In short, 64-bit version is the most lame one I've ever seen.
And all errors feel to be from the same field. Some kind of problem when working specifically with function and string data return/transfer.
How can I explain all this stuff in Service Desk, if all these bugs are spread in different applications, tied up with accesses and tons of code? + Until you write it all down in Service Desk, it will take you a couple of days to document and track it all. IT'S UNREALISTIC.
And everything is perfect in the 32 bit version. Only the first problem is repeated when transferring strings.
And all errors feel to be from the same field. There's something wrong with the function and string data return/transfer.
Yeah, that's right, I've got glitches with string handling too. Function was building a long string from chunks returned by other functions (OpenCL program generation). In the debugger it's like clockwork - the build crashes and says "Acces Violation"... ;)
I was just about to write to Service Desk, but then, all of a sudden, it just kicked in and worked. :) I couldn't reproduce it (although I tried to do it honestly), so why bother sending it to Service Desk? All that remains here is to grumble and whine.
Must be "Wired" or "Wired" or "Wired"