In diesem Artikel geht es darum, wie Sie das Debuggen auf einem 1C-Server 8.1, 8.2 und 8.3 unter Windows- und Ubuntu-Betriebssystemen aktivieren.

Darüber hinaus stelle ich fest, dass dieser Artikel Teil einer kleinen Artikelserie zum Debuggen in 1C ist:

• So aktivieren Sie das Debuggen auf einem 1C-Server

Aktivieren Sie das Debuggen auf dem 1C-Server in Windows

Starten Sie den Registrierungseditor, indem Sie den Befehl regedit ausführen (mit Win+R oder Start->Ausführen).

Weitere Informationen zum HTTP-Debugging und zum Debug-Server finden Sie im nächsten Artikel der Serie.

Aktivieren Sie das Debuggen auf dem 1C-Server in Ubuntu

Zuerst installieren wir den Server:

Sudo-Dienst srv1cv83 stoppen

Öffnen Sie anschließend die Datei /etc/init.d/srv1cv83 als Superuser und suchen Sie darin die Zeile:

Und wir bringen es in diese Form:

Dann starten wir den Server erneut:

Sudo-Dienst srv1cv83 starten

Gehen Sie im Konfigurator auf dem Client-Rechner zu „Einstellungen“ -> „1C:Enterprise starten“ -> „Erweitert“ und aktivieren Sie zwei Elemente:

• „Debug-Aktivierungsmodus festlegen“
• „Debuggen beim Start starten“

Lesen Sie, wie Sie einen 1C-Server unter Ubuntu 16.04/18.04 installieren.

Das ist alles, ich hoffe, dieser Artikel war für Sie nützlich. Ich möchte Sie auch an andere Artikel in der Reihe zum Debuggen in 1C erinnern; Links dazu finden Sie am Anfang dieses Artikels.

Um Serverprozeduren debuggen zu können, müssen Sie die Flags im Formular „Service->Parameters“ des Konfigurators setzen:

Debuggen auf dem Anwendungsserver

Dies ist in der Dokumentation beschrieben:

Buch „1C:Enterprise 8.1. Konfiguration und Administration“

Kapitel 18. Konfigurationstools

Debugger- und Leistungsmessungen

„Debugging-Code auf dem Server

Um den Debug-Modus zu installieren, sollten Sie den 1C:Enterprise-Server mit dem Befehlszeilenschalter /Debug (ragent.exe /debug) starten.

Die Startschlüssel des Serveragenten werden im Buch beschrieben:

„1C:Enterprise 8.1. Kundenserver. Merkmale der Installation und Verwendung“

„Der Serveragent wird als Dienst ausgeführt

Wenn Sie bei der Installation eines Serverclusters die Option ausgewählt haben, den zentralen Serveragenten als Dienst zu starten, wird dieser Dienst automatisch während des Installationsvorgangs und auch beim Start des Betriebssystems gestartet.

Wenn der zentrale Serveragent als Anwendung installiert wurde, ist es möglich, den Dienst manuell zu registrieren und dann zu starten.

Die Dienstregistrierung wird mit dem folgenden Befehl durchgeführt:

Ragent.exe -instsrvc -usr<пользователь>-pwd<пароль>-Hafen<порт>-Reichweite<диапазоны>-seclev<уровень>-debug | -rmsrvc | -start | -stoppen

Instsrvc – Registrieren des Cluster-Agenten als Windows-Dienst. Wenn ragent.exe mit diesem Schlüssel gestartet wird, wird es in der Liste der Windows-Dienste registriert und beendet. Nicht kompatibel mit den Schaltern -srvc, -rmsrvc;

Usr<имя пользователя>

Pwd<пароль пользователя>– Name und Passwort des Windows-Benutzers, unter dessen Namen ragent.exe als Windows-Dienst gestartet werden soll. Kann nur in Verbindung mit dem Schlüssel -instsrvc verwendet werden, wenn ragent.exe als Windows-Dienst registriert wird;

Hafen<порт>– Nummer des Hauptports des Cluster-Agenten. Dieser Port wird von der Cluster-Konsole für den Zugriff auf den zentralen Server verwendet. Der Cluster-Agent-Port wird auch als IP-Port des Arbeitsservers angegeben;

Reichweite<диапазоны>– IP-Portbereiche für dynamische Auswahl. Daraus werden Service-Ports von Cluster-Prozessen ausgewählt, wenn eine Auswahl aus den Einstellungen des entsprechenden Arbeitsservers nicht möglich ist. Standard: 1560-1591. Beispielwerte<диапазоны>: „45:49“, „45:67,70:72,77:90“;

Seclev<уровень>– Sicherheitsstufe des Cluster-Agent-Prozesses. Bestimmt die Sicherheitsstufe von Verbindungen, die mit dem Prozess ragent.exe hergestellt werden.<уровень>kann folgende Werte annehmen: 0 (Standard) Verbindungen sind nicht sicher, 1 – sichere Verbindungen nur für die Dauer der Benutzerauthentifizierung, 2 – dauerhaft sichere Verbindungen.;

Rmsrvc – hebt die Registrierung des Cluster-Agenten als Windows-Dienst auf. Wenn ragent.exe mit diesem Schlüssel gestartet wird, bricht es seine Registrierung in der Liste der Windows-Dienste ab und wird beendet. Nicht kompatibel mit den Schaltern -srvc, -daemon, -instsrvc.

Start – Starten Sie ragent.exe, registriert als Windows-Dienst. Startet ragent.exe, das zuvor als Windows-Dienst registriert war, und beendet es dann;

Stop – stoppt die Registrierung und Ausführung von ragent.exe als Windows-Dienst. Stoppt ragent.exe, das zuvor als Windows-Dienst registriert und ausgeführt wurde, und wird dann beendet;

Debuggen – Starten eines Serverclusters im Konfigurations-Debugging-Modus. "

Wenn also der 1C:Enterprise-Server als Dienst gestartet wurde und aus irgendeinem Grund auch als Dienst im Debug-Modus gestartet werden soll, müssen Sie zunächst die Registrierung des Dienstes aufheben (den Schlüssel -rmsrvc) und ihn dann erneut bei registrieren der -debug-Schlüssel.

Offensichtlich kann ein ähnlicher Effekt auch auf andere Weise erzielt werden, beispielsweise durch direkte Bearbeitung der Windows-Registrierung. Hierzu sollten Sie wahrscheinlich Ihre Windows-Dokumentation zu Rate ziehen.

Funktioniert nur, wenn der Schlüssel „-debug“ in der Registrierung festgelegt ist. In allen anderen Fällen funktioniert es aus irgendeinem Grund nicht.

„ImagePath“=

war „F:\Programme\1cv81\bin\ragent.exe“ -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d „F:\Programme\1cv81\server“

set „F:\Programme\1cv81\bin\ragent.exe“ -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -debug -d „F:\Programme\1cv81\server“

8 besteht (wie unten erläutert) Bedarf an einer erheblichen Überarbeitung des Debugging-Verfahrens. Dies spiegelte sich in Version 8.3.7.1759 wider. Zum einen wurde für dieses Verfahren eine universelle Schnittstelle geschaffen, zum anderen sorgt diese Änderung für die Weiterentwicklung des Programms selbst. Schließlich können Sie jetzt mit dem Debuggen nicht nur über den Konfigurator, sondern auch mit Entwicklungstools arbeiten. Schauen wir uns an, wie Sie das Debuggen auf dem 1C-Server ab der neuen Version aktivieren.

Verwendung des neuen Protokolls

Der vorherige Debugger, der in früheren Versionen implementiert wurde, verwaltete Client- und Serveranwendungen mithilfe des TCP/IP-Protokolls.

Derzeit schränkt die Verwendung eines solchen Protokolls den Zugriff des 1C:Enterprise-Programms auf das Internet ein und verursacht Unannehmlichkeiten beim Betrieb mobiler Anwendungen.

Für den freien Zugriff auf Informationsdatenbanken, die sich möglicherweise außerhalb des lokalen Netzwerks befinden, wurde daher nun das flexible HTTP-Protokoll eingeführt.

Neue Architektur

Bisher musste sich ein Mitarbeiter beim Konfigurations-Debugging mit der Informationsbasis verbinden. Dazu war es notwendig, ihm Administratorrechte zu geben.

In der neuen Version ist keine direkte Verbindung zu den Datenbanken erforderlich – es reicht aus, einfach die gleiche Datenbank wie der Client zu haben. Und Sie können es aus einer Datei laden.

Mobile Anwendungen

Mithilfe des HTTP-Protokolls ist es jetzt möglich, Serverdaten, Clientdaten und Anwendungen zu debuggen.

Weitere Änderungen

Mit der neuen Version ist es möglich, Werte für lokale Variablen im Debugging-Vorgang zu ändern; hierfür wurde ein neues Schnellansichtsfenster implementiert.

Der Berechnungsmodus wurde auf asynchron umgestellt, sodass Sie weiterarbeiten können, ohne auf Ergebnisse warten zu müssen.

Debugger in Entwicklungstools

Die Interaktion mit dem neuen Verfahren erfolgt in einer speziell entwickelten universellen Softwareschnittstelle. Diese Schnittstelle wird zum einen vom Konfigurator genutzt. Andererseits ist es in der neuen 1C:Enterprise Development Tools-Umgebung implementiert.

Wie sieht es jetzt aus?

Nach dem Programmwechsel läuft der Ablauf nach folgendem Szenario ab:

Jetzt geht es nicht nur um den Debugger und die Items, wie es bisher der Fall war. Jetzt wurde ein zusätzliches Element in die Kette eingeführt – der Server.

Es wird nicht nur hinzugefügt, sondern dient auch als Hauptelement des Informationsaustauschs zwischen dem Debugger und Objekten. Und der Austausch selbst erfolgt über in einer Warteschlange aufgereihte Nachrichten.

Und da dieser Austausch über das HTTP-Protokoll erfolgt, spielt es keine Rolle mehr, wo genau sich die Daten befinden.

Aus dem Debugger und Objekten werden Aufrufe an den Server in Form zusätzlicher Verbindungsanfragen gebildet. Wenn sie erscheinen, werden ihnen entsprechende Antworten gesendet.

Aktivieren Sie das Debuggen in verschiedenen Szenarien

Für den Anwendungsentwickler gab es keine Änderungen. Der wesentliche Unterschied besteht darin, dass der neue Mechanismus aktiviert werden muss. Immerhin ist es jetzt standardmäßig deaktiviert.

Schauen wir uns an, was passiert, wenn der Modus startet, wenn wir eines von zwei Szenarien wählen.

Dateiskript

Zu Beginn der Dateiversion müssen Sie in den Konfigurationseinstellungen die Verwendung eines neuen Mechanismus angeben – „Debugging über HTTP-Protokoll“.

Dann schlägt der Konfigurator automatisch die Verwendung eines lokalen Servers vor. Diese Bedingung muss akzeptiert und das Programm im Konfiguratormodus neu gestartet werden.

Danach speichert der neu gestartete Konfigurator die von uns gewählte neue Methode in der nächsten Sitzung. Aber für die gleiche Informationsbasis. Daher muss beim Zugriff auf eine andere Infobase diese ebenfalls aktiviert werden.

Der aktivierte Mechanismus startet nun automatisch den Debugger-Server, bei dem es sich um eine spezielle Anwendung dbgs.exe handelt. Es wird im Task-Manager-Fenster angezeigt.

Der Wert des Parameters „ownerPID“ entspricht der ID der Anwendung, die an ihn gebunden ist.

Wenn Sie eine Debugging-Sitzung über den Konfigurator starten, wird die Serververbindung automatisch hergestellt. Und die verbundenen Objekte werden sich darin widerspiegeln.

Wenn das 1C-Programm ohne den neuen Mechanismus aktiviert wurde, müssen Sie das Debuggen auf dem 1C-Server manuell aktivieren. Erst jetzt müssen Sie die Serveradresse angeben:

Gehen Sie zu Service – Optionen

Es befindet sich in den Elementeinstellungen:

Gehen Sie zu Verbindung – Einstellungen

Wenn Sie ein Dateiskript mit mehreren Datenbanken gleichzeitig verwenden, müssen Sie eine wichtige Nuance berücksichtigen – jeder der Konfiguratoren (mit aktiviertem HTTP-Mechanismus) sendet seinen eigenen Server:

Wenn also mehrere Konfiguratoren geöffnet sind, müssen Sie zum Verbinden des Clients den richtigen angeben.

Client-Server-Szenario

Das Debuggen auf einem 1C-Server mithilfe eines Client-Server-Szenarios beginnt wie im vorherigen Fall mit dem Starten des Modus. Dies spezifiziert die Verwendung des neuen HTTP-Mechanismus. Das geht so:

ragent.exe -debug -http

Beim Start startet automatisch der Debugger dahinter.

Der Wert des OwnerPID-Parameters entspricht der Identifikationsnummer des 1C-Cluster-Managers.

Das Programm generiert einen Vorschlag, jetzt den Cluster-Debug-Server zu verwenden (und nicht einen lokalen wie im vorherigen Szenario). Wir stimmen zu und starten es neu.

In Zukunft wird alles wie ein Dateiskript ablaufen. Erst wenn Sie den Server Database Configurator starten, startet der lokale Debugger-Server nicht mehr.

Wir hoffen, dass unsere Veröffentlichung Ihnen dabei geholfen hat, das Problem herauszufinden, wie Sie das Debuggen auf einem 1C-Server aktivieren können.

Implementiert in Version 8.3.7.1759.

Wir haben den Debugging-Mechanismus erheblich überarbeitet. Dafür gab es mehrere Gründe. Erstens wollten wir Ihnen die Möglichkeit geben, jede heute verfügbare Anwendung zu debuggen. Zweitens erforderte die bisherige Debugger-Architektur Änderungen, um mit aktuellen Trends Schritt zu halten und zukünftige Entwicklungen zu berücksichtigen. Drittens wurde eine universelle Debugging-Schnittstelle benötigt, mit der nicht nur der 1C:Enterprise-Konfigurator, sondern auch .

Hauptvorteile

Damit Sie sich den Umfang der von uns vorgenommenen Änderungen vorstellen können, listen wir kurz die wichtigsten Vorteile des neuen Mechanismus auf.

HTTP-Debugging

Der bisherige Debugging-Mechanismus basierte auf der Tatsache, dass der im 1C:Enterprise-Konfigurator implementierte Debugger direkt mit Debug-Elementen (Client- und Serveranwendungen) interagierte. Diese Interaktion wurde über das TCP/IP-Protokoll durchgeführt.

Mit der Veröffentlichung von 1C:Enterprise-Anwendungen im Internet und insbesondere mit dem Aufkommen mobiler Anwendungen ist dieser Ansatz jedoch zu einer Quelle von Einschränkungen und Unannehmlichkeiten geworden. Das TCP/IP-Protokoll ermöglicht es dem Debugger nicht immer, die zu debuggenden Elemente zu „erreichen“. Schließlich können sie sich außerhalb des lokalen Netzwerks befinden, in dem der Debugger läuft.

Daher haben wir uns im neuen Mechanismus für das „allgegenwärtigere“ HTTP-Protokoll als Transportprotokoll entschieden, das übrigens auch von Clientanwendungen zur Verbindung mit Informationsdatenbanken verwendet wird.

Moderne Debugging-Architektur

Ein Merkmal des vorherigen Debugging-Mechanismus war die Notwendigkeit, über den Konfigurator eine Verbindung zur Infobase herzustellen. Dadurch hatte der Debugging-Entwickler vollen Zugriff auf alle Verwaltungsfunktionen.

Der neue Debugging-Mechanismus erfordert keine Verbindung mehr zur zu debuggenden Infobase. Das Wichtigste, was der Debugger jetzt benötigt, ist die gleiche Konfiguration, die für Clients funktioniert. Um es zu erhalten, ist keine Verbindung zur zu debuggenden Infobase erforderlich. Sie können es beispielsweise aus einer Datei laden.

Debuggen mobiler Anwendungen

Dank der Verwendung des HTTP-Protokolls ist es möglich, von der mobilen Plattform ausgeführte Anwendungen zu debuggen. Darüber hinaus können Sie beliebige Kontexte debuggen: Client, Server sowie Hintergrundjobs.

Jetzt können Sie während des Debuggens die Werte aller beschreibbaren Variablen ändern. Um lokale Variablen schnell anzeigen und ändern zu können, haben wir ein separates Fenster implementiert. Und die Berechnung der vom Debugger angezeigten Ausdrücke erfolgt jetzt im asynchronen Modus.

Debuggen in Entwicklungstools

Bei der Erstellung eines neuen Debugging-Mechanismus haben wir eine neue, universelle Softwareschnittstelle für die Interaktion damit implementiert. Diese Schnittstelle wird vom 1C:Enterprise-Konfigurator verwendet, und dieselbe Schnittstelle wird jetzt von der neuen Entwicklungsumgebung verwendet. Daher sind jetzt alle Debugging-Funktionen verfügbar, wenn Sie in arbeiten.

Debuggen der Prozessarchitektur

Die neue Debugging-Architektur sieht folgendermaßen aus:

Das Debuggen umfasst einen Debugger, Debugging-Elemente und ein neues Element – Debug-Server.

Es gibt keine direkte Informationsübertragung zwischen dem Debugger und den Debug-Elementen. Die gesamte Interaktion wird über den Debugging-Server organisiert. Dies ist das Hauptelement des Mechanismus. Der Debug-Server verfügt über eine Nachrichtenwarteschlange, über die der Debugger und die Debug-Elemente Informationen aneinander weitergeben.

Sowohl der Debugger selbst als auch die Debug-Elemente kommunizieren über HTTP mit dem Debug-Server. Jetzt spielt es also keine Rolle mehr, wo sich diese Debugging-Elemente befinden.

Die Interaktion mit dem Debug-Server wird durch den Debugger und die Debug-Elemente initiiert. Zu diesem Zweck werden zusätzliche Verbindungen organisiert. Ihr Hauptzweck besteht darin, herauszufinden, ob auf dem Debug-Server Informationen für sie erschienen sind. Und wenn es erscheint, holen Sie sich diese Informationen.

Somit ist die Interaktion einseitig. Informationen werden ständig vom Debug-Server an den Debugger und an Debug-Objekte übertragen.

Identifizierung von Informationsbasen

Im vorherigen Mechanismus wurde eine Verbindungszeichenfolge zur Identifizierung von Infobases verwendet. Diese Lösung verursachte in einigen Fällen Schwierigkeiten beim Abgleich von Debugging-Elementen und dem Konfigurator. Denn erstens wurde die Groß-/Kleinschreibung beachtet, und zweitens generierte die Plattform beim Debuggen einiger Kontexte die Verbindungszeichenfolge automatisch. Und es stimmte nicht immer mit dem überein, das Sie beim Anschließen der Infobase im Konfigurator angegeben haben. Das Finden und Korrigieren solcher Situationen erschwerte den Debugging-Prozess.

Im neuen Mechanismus haben wir die Verbindungszeichenfolge entfernt. Jetzt verwenden wir Infobase-ID. In der Datei-Infobase wird eine solche Kennung beim ersten Aufbau einer Client-Verbindung generiert. In der Server-Infobase wird als solche Kennung die Infobase-Registrierungskennung im Cluster verwendet.

Ein schöner zusätzlicher Punkt hier ist, dass wir den alten Debugging-Mechanismus vorerst in der Plattform beibehalten haben (er könnte in Zukunft ausgeschlossen werden). Und Sie können es verwenden, wenn Sie möchten oder wenn es nötig ist. Deshalb haben wir den alten Mechanismus geändert und verwenden jetzt auch die Infobase-ID und nicht die Verbindungszeichenfolge.

Typische Debugging-Szenarien

Aus Sicht eines Anwendungsentwicklers haben sich typische Debugging-Szenarien nicht geändert. Der einzige wesentliche Unterschied besteht darin, dass der neue Debugging-Mechanismus aktiviert sein muss. Denn standardmäßig ist es deaktiviert.

Unabhängig davon ist es sinnvoll, sich damit vertraut zu machen, was jetzt passiert, wenn Sie das Debuggen ausführen. Weil es für Sie in einigen nicht standardmäßigen Arbeitsszenarien nützlich sein kann.

Dateioption

Bevor Sie mit dem Debuggen in der Dateiversion beginnen, müssen Sie in den Konfiguratoreinstellungen angeben, dass Sie den neuen Debugging-Mechanismus verwenden möchten – „ HTTP-Debugging».

In diesem Fall werden Sie vom Konfigurator automatisch aufgefordert, einen lokalen Debugging-Server zu verwenden. Sie müssen dem zustimmen und den Konfigurator neu starten.

Die von Ihnen festgelegte Debugging-Methode wird zwischen Konfiguratorsitzungen gespeichert, jedoch im Kontext von Infobases. Daher müssen Sie diese für eine andere Infobase erneut aktivieren.

Wenn Sie nun den Konfigurator starten oder neu starten, startet die Plattform automatisch den Debugging-Server. Dies ist eine separate dbgs.exe-Anwendung. Sie können es im Task-Manager sehen.

Der Parameter „ownerPID“ gibt die Kennung der Anwendung an, die diesen Debug-Server besitzt. In diesem Fall handelt es sich um den 1C:Enterprise-Konfigurator.

Wenn Sie nun eine 1C:Enterprise-Debugging-Sitzung über den Konfigurator starten, wird automatisch eine Verbindung zum Debugging-Server hergestellt und im Konfigurator werden die verbundenen Debugging-Elemente angezeigt.

Wenn die 1C:Enterprise-Sitzung ohne Debugging gestartet wurde, können Sie sie wie zuvor mit dem Debugger verbinden. Erst jetzt müssen Sie die Debug-Serveradresse angeben:

Sie finden diese Adresse in den Einstellungen für Debugging-Elemente:

Es gibt einen ungewöhnlichen Punkt beim gleichzeitigen Arbeiten mit mehreren Dateidatenbanken. In der Dateiversion startet jeder Konfigurator mit aktiviertem HTTP-Debugging seine eigene Kopie des Debug-Servers auf verschiedenen Ports:

Wenn Sie also mehrere Konfiguratoren gleichzeitig geöffnet haben, müssen Sie zum Verbinden der Clientanwendung mit dem Debugger den richtigen auswählen.

Client-Server-Option

Bevor Sie mit dem Debuggen in der Client-Server-Version beginnen, müssen Sie wie bisher den 1C:Enterprise-Server im Debugging-Modus starten, aber angeben, dass der neue HTTP-Mechanismus zum Debuggen verwendet wird. Zum Beispiel so:

ragent.exe -debug -http

Wenn der Server auf diese Weise gestartet wird, wird auch der Debugging-Server gestartet.

Der Parameter „ownerPID“ gibt die Kennung des 1C:Enterprise-Clustermanagers an.

Nun müssen Sie in den Konfiguratoreinstellungen, wie im Fall der Dateidatenbank, angeben, dass Sie den neuen Debugging-Mechanismus verwenden möchten – „ HTTP-Debugging».

In diesem Fall werden Sie vom Konfigurator automatisch aufgefordert, den Cluster-Debugging-Server und nicht den lokalen Server zu verwenden. Sie müssen dem zustimmen und den Konfigurator neu starten.

Debugging-Elemente verbinden

Wenn Sie Debug-Sitzungen über den Konfigurator starten, verbinden Anwendungen automatisch Debug-Elemente (sowohl Client als auch Server) mit dem Debug-Server.

Gleichzeitig haben Sie wie bisher die Möglichkeit, den Konfigurator so zu konfigurieren, dass Debugging-Elemente automatisch verbunden werden, unabhängig davon, wie sie gestartet wurden. Jetzt sind diese Möglichkeiten viel reicher geworden.

Erstens bietet Ihnen die Plattform jetzt alle möglichen Debugging-Elemente zur Auswahl.

Und zweitens ist eine andere, subtilere Art der Inszenierung aufgetaucht. Dies ist die Verwendung vorgefertigter Auswahlen.

Sie können diese Auswahl sowohl beim Verbinden von Debug-Elementen als auch zum Anzeigen verfügbarer Debug-Elemente verwenden.

In der Auswahl können Sie zusätzlich zu den Debugging-Elementen selbst bestimmte Benutzer angeben, deren Sitzungen für Sie von Interesse sind, und bei Verwendung der Datentrennung auch den Bereich der Infobase angeben, der debuggt werden soll.

Variablen und Objekteigenschaften ändern und Ausdrücke asynchron auswerten

Mit dem neuen Debugging-Mechanismus können Sie Variablenwerte während des Debuggens ändern. Im bisherigen Mechanismus gab es diese Möglichkeit nicht.

Um lokale Variablen bequem anzeigen und ändern zu können, was die häufigste Aufgabe zu sein scheint, haben wir Folgendes implementiert: Lokale Variablen».

Äußerlich ähnelt es stark dem „Scoreboard“, das Sie gewohnt sind. Aber erstens ist dieses Fenster bereits automatisch mit allen lokalen Variablen gefüllt und zweitens können Sie nun die Werte der Variablen ändern.

Sie können die Werte primitiver Typen direkt in der Zelle ändern. Bedeutung»:

Und um andere Werte zu ändern, können Sie das Ausdruckseingabefenster verwenden:

Ein schöner Bonus ist, dass der kontextbezogene Tooltip in diesem Fenster voll funktionsfähig ist.

Genauso können Sie die Werte beliebiger (nicht nur lokaler) Variablen und beschreibbarer Eigenschaften ändern. Im Ausdrucksberechnungsfenster (das mit dem Befehl Umschalt+F9 aufgerufen wird) können Sie die Werte von Variablen sowohl in der Zelle „Wert“ als auch über einen separaten Dialog ändern.

Die Ausdrucksberechnung selbst erfolgt jetzt übrigens asynchron. Das bedeutet, dass der Konfigurator die Berechnung des Debugging-Items anordnet. Und diese Berechnung wird noch einige Zeit auf dem Server erwartet. Ist die Berechnung abgeschlossen, werden die Ergebnisse sofort an den Konfigurator übermittelt. Wenn die Berechnung über einen längeren Zeitraum durchgeführt wird, gelangen die Ergebnisse dieser Berechnungen später asynchron zum Konfigurator. Diese Vorgehensweise ermöglicht es Ihnen, nicht auf langwierige Berechnungen im Konfigurator zu warten und Ihre Arbeit fortzusetzen.

18.10.2016

Debuggen auf einem 1C-Server (8.2, 8.3...)

Wenn die 1C-Datenbank in einer Client-Server-Version ausgeführt wird, ist der Code-Debugging-Modus auf der Serverseite deaktiviert. Daher ist es nicht möglich, Schritt für Schritt zu sehen, was bei der Ausführung einer Funktion oder Prozedur passiert. Um das serverseitige Debuggen zu aktivieren, müssen Sie ein paar einfache Schritte ausführen.

Aktivieren Sie das Debuggen auf dem 1C:Enterprise-Server 8.2, 8.3

Öffnen Sie nach dem Stoppen den Windows-Registrierungseditor („Start – Ausführen“ (oder die Tastenkombination „Windows + R“), schreiben Sie „regedit“) und suchen Sie den Zweig mit dem Namen "" oder "" abhängig von der Plattformversion

Uns interessiert der Registrierungsschlüssel mit dem Namen „ImagePath“. Fügen Sie „-debug“ am Ende des Schlüsselwerts hinzu. Dies bedeutet, dass der Debugging-Modus auf der 1C-Serverseite aktiviert ist.
War: „C:\Programme\1cv8\8.3.6.2530\bin\ragent.exe“ -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d „C:\Programme\1cv8\srvinfo“
Wurde: „C:\Programme\1cv8\8.3.6.2530\bin\ragent.exe“ -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d „C:\Programme\1cv8\srvinfo“ -debug

Speichern und starten Sie den 1C-Dienst. Alles ist fertig! Viel Spaß beim Debuggen!