So prüfen Sie, ob ein Auftrag ausgewählt ist - Seite 18

 
Eigentlich ist der Fehler im allerersten Beitrag, im Gegensatz zum Themenstarter habe ich alle Züge aufgeschrieben, d.h. ich schreibe nur über das, was getestet wurde
 
keekkenen:
es spielt keine Rolle, was Sie darüber denken, wie man Code schreibt, die Hauptsache ist, dass der Code richtig funktioniert, anstatt Ihren Code zu bringen und zu fragen, wo Sie falsch gehen... noch einmal, es gibt keinen 4105 Fehler, wenn das Ticket korrekt ist

Was Sie sagen, ist nicht wahr, denn der Fehler 4105 tritt auf , wenn Funktionen aufgerufen werden, denen das Ticket nicht übergeben werden muss.

Zum Beispiel, wenn OrderTicket() aufgerufen wird, wenn OrderSelect() nicht aufgerufen wurde, bevor OrderTicket() aufgerufen wurde - dies ist die Situation, die in diesem Thread diskutiert wird.

 

Nein, was ich meinte, war eine garantierte Auswahl meiner Reihenfolge für jede der Funktionen unabhängig von den Übergängen (Ausgängen) nach außen.

d.h. die Speicherung des zuletzt gewählten Auftrags für jede Funktion Ihrer

 
FAQ:

Nein, was ich meinte, war eine garantierte Auswahl meiner Reihenfolge für jede der Funktionen unabhängig von den Übergängen (Ausgängen) nach außen.

d.h. die Speicherung des zuletzt gewählten Auftrags für jede Funktion als eigene

Wenn es mehrere verschachtelte Funktionen gibt, die die Kontrolle über die zuletzt gewählte Reihenfolge haben - d. h. eine Funktion ruft eine andere auf und die andere eine dritte, dann behält jede Funktion die Auswahl der Reihenfolge in dem Moment, in dem sie aufgerufen wird, und bringt die Auswahl bei der Rückkehr in diesen Zustand zurück, wenn ich die Frage richtig verstanden habe. Aber das ist eine wirklich schwierige Lösung. Normalerweise ist mehr als eine Verschachtelungsebene unwahrscheinlich. Die Hauptsache ist, die Umgebung jeder solchen Funktion zu kontrollieren, damit ein Aufruf dieser Funktion nicht zu logischen Fehlern führt, weil eine frühere Auftragsauswahl zurückgesetzt wird. Dies wird nur für Servicefunktionen benötigt, die von der Hauptschleife des Auftragsabrufs aus aufgerufen werden können und trotzdem die Aufträge selbst abrufen, um etwas zu berechnen.

 

Übrigens, es scheint, dass, wenn die Service-Funktion in der Bibliothek ist - dann gibt es keine Notwendigkeit, den "Zeiger"(um Auswahl) zu speichern, gibt es? Da der Haupt-EA und die Bibliothek ihre eigenen "Zeiger" haben, d.h. ein in der Bibliothek ausgewählter Auftrag wird nicht im EA ausgewählt und andersherum.

Dies scheint eine perfekte Lösung für das Problem zu sein, wenn sich die beiden Funktionen A und B nicht im selben Modul befinden

 

Ideologie: eine Funktion zur Auswahl der Reihenfolge (eine für alle) mit den notwendigen Filtern außerhalb (in jeder Funktion muss man diese Reihenfolge irgendwo auswählen (wahrscheinlich am Anfang))

int OrdersTicket(filters, int function_id, bool new = false){static int tickets[functions count];int ticket = -1;
   if(!new){
      if(OrderSelect(tickets[function_id],SELECT_BY_TICKET)){return(OrderTicket());}
   }
   // Выбор и возврат тикета ордера с нужными фильтрами
   return(ticket);
}

die mit Sicherheit das Ticket der zuvor ausgewählten Bestellung zurückgibt (in dieser Funktion), oder aber eine neue Suche mit den von uns angegebenen Filtern durchführt

In diesem Fall funktioniert die Konstruktion ticket = OrdersTicket(); perfekt.

 
Ant_TL:

Was Sie sagen, ist nicht wahr, denn der Fehler 4105 tritt auf, wenn Funktionen aufgerufen werden, denen das Ticket nicht übergeben werden muss.

Zum Beispiel, wenn OrderTicket() aufgerufen wird, wenn OrderSelect() nicht aufgerufen wurde, bevor OrderTicket() aufgerufen wurde - dies ist die Situation, die in diesem Thread diskutiert wird.


Woher bekommen Sie das Ticket aus den EA-Einstellungen, externe Datei - woher?

wenn ja, dann ja, es wird ein Fehler, weil die Tatsache der OrderSelect() Aufruf bleibt am Anfang auf die nächsten Ticks (zumindest in der Tester),...

 
Ant_TL:

Übrigens, es scheint, dass, wenn die Service-Funktion in der Bibliothek ist - dann gibt es keine Notwendigkeit, den "Zeiger" (um Auswahl) zu speichern, gibt es? Da der Haupt-EA und die Bibliothek ihre eigenen "Zeiger" haben, d.h. ein in der Bibliothek ausgewählter Auftrag wird nicht im EA ausgewählt und andersherum.

Dies scheint eine perfekte Lösung für das Problem zu sein, wenn sich die beiden Funktionen A und B nicht im selben Modul befinden


Es hängt alles vom Grad der Globalität der externen Variablen ab.
 
Ant_TL:

Übrigens, es scheint, dass, wenn die Service-Funktion in der Bibliothek ist - dann gibt es keine Notwendigkeit, den "Zeiger" (um Auswahl) zu speichern, gibt es? Da der Haupt-EA und die Bibliothek ihre eigenen "Zeiger" haben, d.h. ein in der Bibliothek ausgewählter Auftrag wird nicht im EA ausgewählt und andersherum.

Dies scheint eine perfekte Lösung für das Problem zu sein, wenn sich die beiden Funktionen A und B nicht im selben Modul befinden


Ich verzichte. Bei allem anderen kann ich Ihnen nicht helfen. Runde um Runde ohne mich!!!
 
FAQ:

Es hängt alles davon ab, wie global die externe Variable ist.

Konkret ist der "Zeiger" - der Zustand der aktuellenAuftragsauswahl - innerhalb des Moduls global, d.h. dieser Zeiger ist für die Bibliothek gleich und für das Programmmodul unterschiedlich. Das heißt, wenn die Funktion A im Programm eine bestimmte Reihenfolge in der Schleife auswählt und dann die Hilfsfunktion B aus der Bibliothek aufruft, dann sollte die Auswahl der Reihenfolge in der Funktion A bei der Rückkehr nicht geändert werden, selbst wenn B während seiner Operation eine andere Reihenfolge auswählt. Befinden sich jedoch beide Funktionen innerhalb eines Moduls, sollte bei der Rückkehr von B die aktuelle Auswahl der Reihenfolge gespeichert und entweder vor und nach dem Aufruf von B in A selbst oder in B zu Beginn und nach Abschluss seiner Arbeit wiederhergestellt werden, damit die Logik der Arbeit von A an diesem Punkt nicht verletzt wird.

Grund der Beschwerde: