Errors, bugs, questions - page 3122
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 if someone else has a program with graphical objects, your type prefix "l" < where is the deletion by prefix " l" (the names "label" and "line" were used when the objects were created >
Will kill all objects beginning with"l" in a third party program. This is not a good solution.
Vitaly, why don't you go into the beginners thread? These basics more or less the programmer knows for a long time. And only the "star" ones do not all know...
Vitaly, why don't you go into the beginners thread? These basics have been known to more or less programmers for a long time. And only the "star" ones do not all know...
Great!
Yes, I'll probably go :)
and if someone else has a program with graphical objects, your type prefix "l" < where is the deletion by prefix " l" (the names "label" and "line" were used when the objects were created >
Will kill all objects beginning with"l" in a third party program. This is not a good solution.
That's what I was thinking too. There's a chance that another programmer will glue identical object names or names with the same prefix, so removing objects by prefix (especially the short one) is more dangerous than bumping into and removing an object with a completely matching name. We should also keep in mind that a second program will not be able to create a second object with an existing name, the former object must remain (in my opinion). In any case, a neighboring program that decides to delete such an object, assuming it is its object, will delete someone else's object with the same name.
So far I see the only solution: name objects within the same program as exclusively as possible, to reduce the chance of stumbling across an alien object with the same name and make unwanted manipulations on it. But let me remind you that prefix lengthening is not always technically possible, because the length of object name is limited.
This is something I've been thinking about as well. There is a chance that another programmer will make identical object names or names with the same prefix, so deleting objects by prefix (especially a short one) is more dangerous than bumping into and deleting a fully matched object by name. We should also keep in mind that a second program will not be able to create a second object with an existing name, the former object must remain (in my opinion). In any case, a second program that decides to delete such an object, assuming it is its object, will delete someone else's object with the same name.
So far I see the only solution: name objects within the same program as exclusively as possible, to reduce the probability of stumbling across an alien object with the same name and make unwanted manipulations on it. But let me remind you that prefix lengthening is not always technically possible, because the length of object name is limited.
I don't need to remind you, I work with graphical objects every day.
Incorrect logic is the key to ... what? Right, the key to failure. That's your case.
I don't need reminding, I work with graphical objects every day.
Incorrect logic is key to... what? Right, the key to failure. That's your case.
And what is failure?
And I remind you, in general, not of you (we are not in private correspondence), but of the public reading us, among whom I am sure there are amateurs.And what is the failure?
I have already described it, but the choice is yours.
I understand that you put a lot of effort into the writing, so for you this programme is valuable and correct. But there are flaws in it, even critical ones, that you find difficult to accept.
That's all, sort it out on your own, I've described my assessment.
I have already described it, but the choice is yours.
I have dissuaded you comprehensively, admitting you are right only in a couple of minor non-critical points. But if you are not impressed and dissuaded, I understand - it is difficult to accept the counter-arguments directly from the author of the code.
Speaking of looking for free code.
Try to guess what percentage of programmers search for programs to help their profitable trading or to learn the code. Personally, I think the preponderance will be in the direction of the former, because far fewer seekers see themselves as programmers in this field.
Speaking of looking for free code.
Try to guess what percentage of programmers search for programs to help their profitable trading or to learn the code. Personally, I believe the preponderance is more in favor of the former, since far fewer of those who search for it see themselves as programmers in this field.
The point is that such code cannot be used on a personal machine, but you have never acknowledged this. A programmer certainly won't put it in, having seen what's inside the code.
They also started arguing about the prefix, but I didn't come here to argue.
Good luck!
That's the thing: you can't use that code on a personal machine, but you never acknowledged it.
Of course I didn't. Because in order for those defects to start slowing down the machine, you have to use them in high-loaded computations - for example, in very, very fat loops or very frequent reinitializations. I don't recommend adopting this code for such cases. But in the present case everything flies; the loud and contradictory statement about failure is nothing more than a humiliation. But thank you for that.
And I'm always open to improving my code as I become more enlightened.