How to check if an order is selected - page 16

 
TarasBY:
Please elaborate on this point. I am in favour of it too! I haven't encountered anything else, either. And a single error (which you once mentioned) is not a factor to worry about.

The environment here is the order selection state, a kind of "pointer" as it was called here. It should be possible to save this pointer state seamlessly when any function is called, even if this function itself works with orders, going through them and so on. However, it turns out that trying to save this "pointer" generates a 4105 execution error if it was not sort of initialized before this function was called. But the function shouldn't worry about what's in this pointer. It should keep its state whether an order has been selected before it or not. If it hasn't been selected, it should return the pointer also uninitialized on return. If it has been chosen, any such function must return the pointer in the state it was in when it was called. I wrote a solution to this situation a few pages ago using OrderSelect function wrappers, but these are "crutches", this feature should in theory be present in the language without the need to duplicate data or generate additional code

 
FAQ:
Dear, from the first page I have tried to convey to you the idea that you and only you should be concerned about this fact, but you take it as "belittling" and rudeness. If you are not able to perceive opinions that diverge from your point of view on the issue of interest, then why are you asking it?

I am only able to accept opinions when the author demonstrates a willingness to have a constructive discussion, not when he demonstrates with his tone and words "I am right and you are a fool". In the latter case, I reply "you are a fool" - for which you have tried to ban me not for the first time.

 
Ant_TL:

I am only able to accept opinions when the author demonstrates a willingness to have a constructive discussion, not when he demonstrates with his tone and words "I am right and you are a fool". In the latter case, I reply with "you are a fool" - for which you have tried to ban me not for the first time.


Here we go again, the same thing again...

Again you are jumping to conclusions and attributing it to me. If I was "trying to get" you banned, we wouldn't have been chatting nicely for 16 pages.

 
Ant_TL:

I am only able to accept opinions when the author demonstrates a willingness to have a constructive discussion, not when he demonstrates with his tone and words "I am right and you are a fool". In the latter case, my response is "you are a fool" - which is not the first time you have tried to ban me for.


Maybe you should take a day or a week off. In good faith.
 

Gentlemen, I'm in no way challenging your ability to ban anyone at any time)

But still, I would like to see a branch of people for whom this topic is interesting and relevant, yet among the general flow of "opinions" there are such people

 
Ant_TL:

Gentlemen, I'm in no way challenging your ability to ban anyone at any time)

But still, I would like to see a branch of people for whom this topic is interesting and relevant, yet among the general flow of "opinions" there are such people


I asked for your code, but it was not there. So there was no constructive feedback from you
 
Vinin:

I asked for your code to be posted, but it never was. So there was no constructive input from your side

Now you've been asked. OK, since it all rests on this code, I won't go back until I've posted it.

Although this post here, in my opinion, and there are like-minded people of that opinion, describes enough of the validity of the emergence of this thread:

[QUOTE]The environment here is the state of order selection, a kind of "pointer" as it has been called here. It should be possible to seamlessly preserve the state of this pointer when any function is called, even if that function itself works with orders, going through them and so on. However, it turns out that trying to save this "pointer" generates a 4105 execution error if it was not sort of initialized before this function was called. But the function shouldn't worry about what's in this pointer. It should keep its state whether an order has been selected before it or not. If it has not been selected, it should return the pointer also uninitialized on return. If it has been set, any such function should return the pointer in the state it was in when it was called. I wrote a solution to this situation a few pages ago via OrderSelect function wrappers, but it's "crutches", this feature should theoretically be present in the language without the need to duplicate data and generate additional code[/QUOTE]

 
Ant_TL:

Gentlemen, I'm in no way challenging your ability to ban anyone at any time)

But still, I would like to see a branch of people for whom this topic is interesting and relevant, yet among the general flow of "opinions" there are such people


You yourself are driving them out of your topic. Because you want to see only what you want to see.

But there is some progress - you decided to use global variable of lastticket type and it can't help pleasing, now I suggest you to introduce an array where each function would enter a ticket and its own label like ords[ticket][function indx].

 
Ant_TL:

The environment here is the order selection state, a kind of "pointer" as it was called here. It should be possible to save this pointer state seamlessly when any function is called, even if this function itself works with orders, going through them and so on. However, it turns out that trying to save this "pointer" generates a 4105 execution error if it was not sort of initialized before this function was called. But the function shouldn't worry about what's in this pointer. It should keep its state whether an order has been selected before it or not. If it has not been selected, it should return the pointer also uninitialized on return. If it has been chosen, any such function must return the pointer in the state it was in when it was called. I wrote a solution to this situation a few pages ago using OrderSelect function wrappers, but these are crutches - this feature should theoretically be present in the language without the need to duplicate data or generate extra code

The letters seem familiar, but "about what???"... :(

Ok, good luck with your search...

 
TarasBY:

Well, good luck with your search...

And good luck to you.

Reason: