Es gab hier die Idee, unserer Hauptbuchhalterin mehr oder weniger originell zu gratulieren, zum Beispiel mit Hilfe ihres Lieblingsprogramms 1C? Aber wie?
Nach einigem Überlegen kam die Idee, das Hintergrundbild im Clientbereich herkömmlicher Formulare für Konfigurationen auf 1C77-1C82 oder in einem externen Fenster für verwaltete Formulare 1C82 und in allen Fällen für 1C83 als Hintergrundglückwunsch zu verwenden. Zeigen Sie darauf die gewünschte Nachricht an und geben Sie Links zum Glückwunschvideo an, wie in der Abbildung gezeigt.
Erster Teil - Ergebnis
Offensichtlich ist diese Idee nicht neu. Daher wurde 2011
von Aleksey Fedorov alias ALF eine
ähnliche Lösung basierend auf
FormEx.dll vorgeschlagen. Und
wie dies erreicht werden kann, wurden bereits 2008 gestellt.
Zu einer Zeit haben wir diese Komponente auch verwendet, um das Hintergrundbild in 1C77 zu laden. Das Herunterladen großer BMP-Dateien (und anderer konnte nicht verwendet werden) war jedoch langsam (aus diesem Grund wurden kleine Bilder mit Kacheln verwendet), sodass der Wunsch bestand, eine eigene externe Komponente (VK) zu schreiben, die nur die erforderlichen Bilder herunterlädt und nichts weiter, es sei denn Was gibt es sonst noch als Testgelände für Experimente?
Eine solche Komponente wurde geschrieben (auch nur für BMP-Dateien, ggf. mit Kacheln). Dort wurde die Funktion
WinAPI LoadImage () verwendet. Diese DLL stand nicht in Konflikt mit FormEx.dll, sie war einfach, schnell genug und diente lange Zeit.
All dies war wunderbar, aber es war Zeit, seine Fähigkeiten zu erweitern, und hier war ein anderer Ansatz erforderlich.
In diesem Artikel werden die Probleme beim Erstellen von Multimediadateien nicht behandelt. Dies ist nicht unsere Spezialität. Wir beschränken uns nur auf einige Nuancen der Programmierung externer Komponenten für 1C.
1C77
Da die Versionen der 1C-Plattform unterschiedlich sein können, kann es mehrere Lösungen geben. In unserem Fall waren dies Konfigurationen auf 1C77 (Abb. 1).
Abb. 1. Glückwunschbild in der Testkonfiguration auf 1C77.
Das Video hier ist zwar ein eigenes, aber die Idee seiner Entstehung stammt von
Anna Shiyanova unter dem Spitznamen "Special Case" . Dieses Mädchen hat Talent, sie kann nachgeahmt werden, aber es ist kaum möglich, den Stil vollständig zu wiederholen. In diesem Fall wollte ich zumindest ein Element der Kreativität.
Wenn einer der Kollegen es bereits satt hat, die Glückwünsche anderer zu betrachten, kann er das Bild mit „
Alt + I “ überladen (Abb. 2-3).
Abb. 2. Wählen Sie ein anderes Hintergrundbild im Menü "Datei / Hintergrund auswählen" oder mit "Alt + I".
Gleichzeitig finden Sie Informationen zu dem von "
Alt + L " verwendeten Modul (Abb. 3).
Abb. 3. Überladenes Hintergrundbild mit Informationen zum Programm („Hilfe / Informationen zum LionExt32.dll-Modul“ oder „Alt + L“).
1C82 konventionelle Formen
Natürlich orientiert sich die Mehrheit jetzt am G8 (1C8x). Das Arbeiten mit dem Hintergrundbild in 1C ist jedoch nur auf normalen Formularen in Version 8.2 und weniger möglich. Wenn Sie keine Verarbeitung verwenden, die im Desktop-Modus beginnt, überlappt sich unser Hintergrund einfach vollständig (Abb. 4).
Abb. 4. Glückwunschbild in der Testkonfiguration zu den üblichen Formularen 1C82.
Beachten Sie, dass die Links zu Abb. 4 zeigen nicht unser Video an. Sie werden nur für den Test angezeigt.
In gewöhnlichen Formen bietet 1C82 nicht mehr die Standardmethode für den Zugriff auf das Menü, da es dort nicht systemisch ist, wie bei den "sieben", sondern "eigenen" (obwohl das System erstellt werden kann, aber warum benötigen wir zwei Hauptmenüs?). Es können jedoch Hotkeys verwendet werden. Aus dem gleichen Grund rufen wir in unserer Komponente „Alt + I“ einen Dialog wie in Abb. 2 auf und laden einen weiteren Hintergrund (Abb. 5).
Abb. 5. Überladenes Hintergrundbild in „dicken“ 1C82-Formularen.
Ebenso können Sie Informationen über das Modul erhalten, indem Sie die Taste "Alt + L" drücken, wie in Abb. 3.
1C82 verwaltete Formulare
Für verwaltete Formulare in 1C82 finden Sie immer noch das Fenster, das wir auf der siebten Verschachtelungsebene benötigen, z. B. "
V8FormElement ", und zeichnen darauf, aber irgendwie ist es nicht interessant.
Aus diesen Überlegungen folgt für uns, dass es einfacher ist, ein externes Fenster mit einer Glückwunschbotschaft zu erstellen (Abb. 6), als jeden Einzelfall zu behandeln. Das Fenster selbst kann durch "
Esc ", "
Strg + F4 ", "
Alt + F4 " oder durch Klicken auf das "
Kreuz " geschlossen oder vielmehr minimiert werden.
Abb. 6. Glückwunschbild in einer Testkonfiguration auf verwalteten Formularen 1C82.
Darüber hinaus kann das minimierte Fenster (Abb. 7) wieder erweitert werden.
Abb. 7. Ein minimiertes Bild des externen Fensters in verwalteten Formularen 1C82.
Die Abmessungen und die relative Position des Außenfensters können geändert werden, hier ist alles wie gewohnt (siehe vergrößerte Bilder der Außenfenster in Abb. 6 und Abb. 10). Beachten Sie, dass Hotkeys nur funktionieren, wenn das externe Fenster aktiv ist.
1C83 herkömmliche Formen
In 1C83 gibt es überhaupt keine untergeordneten Fenster mehr, die als Kriterium für Version 1C in unserer DLL dienen können. Darüber hinaus sind „dicke“ Formulare ein Rahmenfenster (Abb. 8) und verwaltete Formulare rahmenlos (Abb. 9). Das heißt, alles, was kein Rahmen ist, kann neu gezeichnet werden. Ein Frame kann auch neu gezeichnet werden, jedoch nur als Systemelement.
Hier haben wir ein Testfenster mit einer dynamischen Bibliothek erstellt und es dem 1C-Hauptfenster untergeordnet. Der Unterschied im Verhalten ist in den Figuren zu sehen.
1C83 verwaltete Formulare
Im Fall von 1C83, wie in den verwalteten Formularen 1C82, werden wir unsere Glückwünsche nicht vor dem Hintergrund, sondern in einem separaten Fenster ziehen, dessen Prototyp in Abb. 1 dargestellt ist. 8-9. Als Ergebnis
liefert die gewünschte Komponente (
LionExt32.dll oder
LionExt64.dll ) das folgende Ergebnis (Abb. 10-12).
Abb. 10. Das Hintergrundbild im externen Fenster für herkömmliche Formulare 1C83.
Abb. 11. Das Hintergrundbild im externen Fenster der verwalteten Formulare 1C83, Version 14, 64-Bit-Version.
Abb. 12. Das Hintergrundbild im externen Fenster der verwalteten Formulare 1C83, Version 15, 64-Bit-Version.
Vorläufige Ergebnisse
Diese Komponente wurde tatsächlich in der Praxis eingesetzt (Abb. 1), der Hauptbuchhalter war zufrieden, alles lief wunderbar. Dabei stellte sich heraus, dass Benutzer gerne ihre eigenen Hintergrundbilder auswählen, in diesem Fall um an den "Sieben" zu arbeiten. Für den G8 ist unsere Komponente mit einer Reserve für die Zukunft angepasst, während sie als Demoversion betrachtet werden sollte.
Das Interesse hierbei war, dass für
diese Komponente keine Konformität mit der Technologie zur Erstellung externer Komponenten aus 1C erforderlich war . Vielleicht entstehen zusätzliche Ideen, um seine Fähigkeiten zu erweitern. Beispielsweise möchten Sie für Konfigurationen, die vollständig unterstützt werden, keine Änderungen am 1C-Code ohne besondere Notwendigkeit vornehmen. In diesem Fall könnte man die Möglichkeit bieten, eine beliebige DLL extern in den Adressraum 1C zu laden. Dies ist jedoch das Thema eines anderen Artikels.
Bei technischen Neuerungen wurde ein Schloss verwendet, um unsere Komponente mit der 1C-Plattform zu entladen (da sie nicht dem VK-Format entspricht). Ein weiterer Trick ermöglichte es außerdem, dem untergeordneten Fenster ein
lokales Menü zuzuweisen, da das Windows-Betriebssystem die Erstellung eines solchen Menüs für untergeordnete Fenster blockiert. Daher werden lokale Menüs nirgendwo im selben
MDI (Multi Document Interface) angezeigt. Er wird durch Befehlsfelder, Symbolleisten und ein Kontextmenü ersetzt. Es gibt noch einen Moment zum Aktualisieren von Fenstern. Manchmal kommt es vor, dass weder
UpdateWindow () noch
InvalidateRect () ordnungsgemäß funktionieren. In diesem Fall sind jedoch einige Funktionen erfolgreich:
ShowWindow(hWnd, SW_HIDE); ShowWindow(hWnd, SW_SHOW);
Es sollte auch beachtet werden, dass unsere Komponente möglicherweise mit anderen in Konflikt steht, z. B. mit FormEx.dll für 1C77. In diesem Fall muss es zuletzt geladen werden.
Übrigens wird bemerkt, dass beim Erstellen einer Konfiguration in Version 1C-8.3.14 und höher die Komponente nicht regelmäßig geladen wird. Wenn die Datenbank jedoch in einer früheren Version von 1C erstellt und in den neuesten Versionen geöffnet wurde, gibt es keine Probleme beim Laden unserer VK. Dies weist erneut auf die Notwendigkeit hin, einen externen Bootloader zu erstellen.
Dieses Projekt verwendet das
WinAPI GDI + -Subsystem. Mit ihm können Sie Bilder in verschiedenen Formaten anzeigen:
bmp, jpg, gif, png, tif und andere. In derselben Reihenfolge versucht die Komponente, die erste verfügbare
Main. * -Datei aus dem lokalen
Pics- Verzeichnis in der aktuellen Konfiguration zu laden. Wenn keine dieser Dateien gefunden wird, wird ein einfaches Hintergrundbild aus Komponentenressourcen verwendet. In Abb. Abbildung 13 zeigt dieses Hintergrundbild für die üblichen Formen von 64-Bit 1C83, Version 15. Zur Änderung wurde das externe Fenster des Slang vergrößert und ein weiteres Bild aus der Datei
Main1.png , das „gekachelt“ wurde, zu seinem Hintergrund hinzugefügt.
Abb. 13. Das Standard-Hintergrundbild für die üblichen Formen von 64-Bit-1C83, Version 15. Außerdem wurde ein weiteres Bild aus der Datei Main1.png hinzugefügt, das als „Kacheln“ ausgelegt ist.
Es gibt keinen Unterschied in der Funktionsweise der Komponente in verschiedenen Bitmodi.
Es kann auch angemerkt werden, dass unsere Komponente das Hauptfenster von 1C und gegebenenfalls dessen MDI-Client unterklassifiziert. Dies dient anscheinend als Konfliktquelle für FormEx.dll, wenn es zuletzt geladen wird (in 1C77).
Zweiter Teil - Technisch
Das Projekt selbst finden Sie unter folgenden Links:
Ein
C ++ - Projekt kann problemlos für Version
10 angepasst werden, wenn die Zeichenfolge "
v120 " in den Konfigurationsdateien durch "
v100 " und "
ToolsVersion =" 12.0 "durch"
ToolsVersion = "4.0" ersetzt wird .
Der Code für die
32- Bit- und
64- Bit-Versionen von
1C ist derselbe und kann gleichzeitig kompiliert werden.
Version 1C77 wird in der externen Komponente durch das Funktionshandle GetMenu
() ungleich Null und Version 1C83 durch das Fehlen von untergeordneten Fenstern im Hauptfenster bestimmt, deren Handle durch die Funktion
GetForegroundWindow () bestimmt wird.
Informationen zur Technologie zum Erstellen externer Komponenten für 1C
Auf den ITS-Discs der Firma 1C und im Internet finden Sie leicht Informationen zur Erstellung von VC und den entsprechenden Vorlagen in verschiedenen Programmiersprachen. In den Zeiten von 1C77 erfüllten diese Muster jedoch "nicht nur alle".
Wenn Sie sich einige weit verbreitete Komponenten ansehen, insbesondere für 1C77, werden Sie feststellen, dass ihre Autoren häufig spezielle Programmiermethoden verwendeten, um die Funktionen ihrer Designs zu erweitern.
Möglicherweise war eine der ersten derartigen externen Komponenten
"RAINBOW ADDIN 2000 für 1C: Enterprise 7.7". Das vielleicht wichtigste war hier ein tieferes Eindringen in die Eingeweide der „Sieben“, als es die offizielle VK-Technologie erlaubte, obwohl sie dem VK-Format folgte. Dies wurde aufgrund der empfangenen, möglicherweise nicht standardmäßigen Methoden, Header (* .h-Dateien) von 1C77-Bibliotheksdateien erreicht, die in anderen weithin bekannten Projekten verwendet wurden.
Wenn 1C-Funktionen wie
LoadExternalComponent () und
ConnectExternalComponent () es Ihnen ermöglichen,
externe DLLs in Ihren eigenen Adressraum einzubetten (zunächst einmal, die das VK-Technologieformat erfüllen), warum erliegen Benutzerprogramme dann nicht der Versuchung und versuchen, auf andere verborgene zuzugreifen sie, Prozeduren und andere Objekte der Zielplattform? Dieser Ansatz wurde von der
Rainbow.dll- Komponente erfolgreich demonstriert.
Später wurde ein ähnlicher Mechanismus von anderen Autoren der Komponente 1C Version 7.7 übernommen. Besonders hervorzuheben ist die Komponente für die "sieben"
1C ++. Dll und
sozusagen ein Sonderfall von
FormEx.dll .
Der nicht triviale Ansatz für das Design externer Komponenten für 1C77 endete jedoch nicht dort. Anscheinend hätte jemand sagen sollen: „Warum brauchen wir einen Schmied? Wir brauchen keinen Schmied! " Mit „Schmied“ meinen wir hier die COM-Technologie von MicroSoft, auf die gewissermaßen die VK-Technologie für die „Sieben“ folgte. Nein, wirklich, warum brauchen wir eine Registrierung, wenn wir unsere VK direkt herunterladen? Dies mag für Webbrowser, die mit dem Internet arbeiten, sinnvoll sein, für den lokalen Betrieb ist die Verwendung der Registrierung jedoch eindeutig redundant. Zumindest sollte dies keine Voraussetzung sein. Darüber hinaus benötigen Sie zum Bearbeiten der Registrierung Administratorrechte.
Beachten Sie, dass 1C diese Technologie sehr mochte (zumindest bis zur Portierung von 1C auf Linux). Wir behandeln sie ziemlich cool. COM ist praktisch für die Verwendung der ActiveX-Komponente, und dies ist natürlich, da letztere ursprünglich für das Internet entwickelt wurden.
In den neuesten Versionen hat 1C jedoch die Möglichkeit hinzugefügt, die
native API- Technologie zu verwenden, sodass keine Registrierung erforderlich ist. Im Prinzip ist dies das, was wir brauchen, außer dass diese Technologie in den "Sieben" nicht anwendbar ist und für einige immer noch relevant ist.
Manchmal treten jedoch relativ einfache Aufgaben auf, wenn Sie keinen Haufen Boilerplate-Code für VK verwenden möchten und es ratsam ist, mit 1C nur von der Seite der externen Komponente aus zu arbeiten. Wie in unserem Fall beispielsweise die Demonstration eines Glückwunschbildes im Kundenbereich oder, falls erforderlich, in einem separaten Fenster, Konfiguration 1C.
Mit anderen Worten, wenn wir keine Daten direkt zwischen 1C und VK austauschen wollen, werden wir mit einer einfacheren und universelleren Version der externen Komponente für 1C sehr zufrieden sein. Einfachheit wird hier aufgrund des Fehlens von Boilerplate-Code erreicht.
Alternative Technologie zum Erstellen von VK für 1C
Da VK für 1C ein Sonderfall eines
COM-Servers ist (vor der
Native API- Technologie), gab es VK-Entwickler, die sagten: „COM - nein!“. Besonders auffällig ist die Tätigkeit von
Alexander Orefkov in dieser Richtung. Die Komponenten "
1sqlite.dll ", "
TurboMD.dll " und möglicherweise andere verwenden COM aus dem Wort "vollständig" nicht. Auf diesem Weg entwickelt sich auch die
Yoksel- Komponente ("
SpreadSheet.dll ").
Aber wie lädt dann der VK-Lader von 1C77 diese Komponenten? Schließlich versuchen sie dort nicht einmal, eine Art COM nachzuahmen. Wenn wir versuchen, eine Standard-DLL, die beispielsweise vom
MS VC ++ - Assistenten generiert wurde, unverblümt in die
LoadExternalComponent () -Funktion zu verschieben, haben wir einen Mist.
In der "Sieben" erhalten wir eine Nachricht wie:
Beim Erstellen eines Objekts aus der DLL-Komponente <Vollständiger Pfad \ Komponentenname> ist ein Fehler aufgetreten (CLSID fehlt).
Im "dicken" 32-Bit-Client ist die "Acht" -Nachricht ähnlich. Dieselbe DLL verursacht ein ähnliches Fluchen (Abb. 15):
Fehler beim Aufrufen der Kontextmethode (Externe Komponente laden): Fehler beim Laden der externen Komponente
Wie lösen die genannten Bibliotheken dieses Problem? Wenn wir die Texte der Programme Orefkov und Yoksel studieren, kommen wir letztendlich zu dem Schluss, dass die folgenden „
magischen Linien “ in der Ressourcendatei (* .rc oder * .rc2) „schuld“ sind:
STRINGTABLE DISCARDABLE BEGIN 100 "\0sd" // 1sqlite.dll 100 "\0tmd" // TurboMD.dll 100 "\0f" // SpreadSheet.dll END
Das heißt, In den Programmressourcen gibt es eine Zeile mit dem Bezeichner
100 und einem Zeichenfolgenwert, dessen erstes Zeichen Null ist. Sie können mit Variationen solcher Zeichenfolgen experimentieren, aber die Zeichenfolge "
\ 0L " ist für mich in Ordnung. Daher erstellen wir eine Ressourcendatei und schreiben Zeilen wie folgt:
STRINGTABLE DISCARDABLE BEGIN 100 "\0L" // 1 ! END
Wir verbinden diese Datei mit unserem einfachsten DLL-Projekt, das vom MS C ++ - Assistenten generiert wurde. Fügen Sie den folgenden Code hinzu:
BOOL APIENTRY DllMain(HANDLE hModule, DWORD dwReason, LPVOID lpReserved) { switch(dwReason) { case DLL_PROCESS_ATTACH: MessageBox(NULL, ", DllMain()!", "", MB_OK); break; case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: break; case DLL_PROCESS_DETACH: break; }
und beobachten (Abb. 14).
Abb. 14. Verwendung des einfachsten „VK“ in 1C82.
Ohne "magische Linien" in der Ressourcendatei wird unsere DLL nach dem Anzeigen von MessageBox sofort mit einem Fluch von 1C entladen (Abb. 15).
Abb. 15. Fehler beim Laden der regulären DLL in 1C82.
Das heißt, diese Leitungen haben wirklich einen magischen Effekt auf den Lader externer 1C-Komponenten.
Der erste, wie es scheint, "magische Linien" wurde in seinem alten Artikel von
Alexei Fedorov (ALF) beschrieben , aber der Link dazu ist nicht mehr verfügbar, und der Autor sieht den Punkt in seiner Neuveröffentlichung nicht. Darüber hinaus hat
Alexander Orefkov sie am intensivsten genutzt, und anscheinend war der Autor nach seiner Vorlage
Yoksel . Deshalb werden wir über die
„magischen“ Linien von Fedorov-Orefkov sprechen . Ihre Bedeutung ist es, das Entladen von nicht standardmäßigen (aus Sicht von 1C) DLL-Dateien durch die Funktion
LoadExternalComponent () zu blockieren . Darüber hinaus funktioniert diese Technik, wie wir sehen, nicht nur in 1C77, sondern auch in „dicken“ 1C82-Formen.
In den verwalteten Formularen 1C82 und in allen Versionen von 1C83 wurde diese Funktion jedoch bereits vollständig unterbrochen (ein weiterer Loader wurde ebenfalls angezeigt -
ConnectExternalComponent () ).
In modernen Versionen von 1C müssen Sie daher nach anderen einfachen Alternativen zu den „magischen“ Linien von Fedorov-Orefkov suchen.
Und eine solche Alternative ist einfach anzubieten. Der Punkt ist einfach. Der 1C-Loader entlädt die "falsche" Komponente, wenn er eine Ausnahme auslöst, wenn er versucht, mit dem angegebenen Protokoll darauf zuzugreifen, z. B. wenn er die Version der Komponente anfordert. Natürlich haben wir nichts dergleichen, was als Grundlage für das Entladen einer nicht standardmäßigen DLL dient. Die Anforderung von 1C, dass das Betriebssystem diese dynamische Bibliothek entlädt, kann vom System ignoriert werden, wenn diese VK noch irgendwo verwendet wird. Anstelle des Löschens selbst reduziert das System einfach den Nutzungszähler des gewünschten Moduls. Und physisch nicht früher löschen, als dieser Zähler zurückgesetzt wird. Daher ist es unsere Aufgabe, diesen Zähler künstlich zu erhöhen.
Dazu können Sie unsere DLL-Funktion WinAPI
LoadLibrary () im Abschnitt
DLL_THREAD_ATTACH erneut
aufrufen BOOL APIENTRY DllMain(HANDLE hModule, DWORD dwReason, LPVOID lpReserved) { switch(dwReason) { case DLL_PROCESS_ATTACH: { WCHAR szDllName[_MAX_PATH] = {0};
Das ist alles! Das Problem ist gelöst. Durch das Abrufen derselben dynamischen Bibliothek wird der Nutzungszähler um eins erhöht, und das Entladen (mit vorläufigem Zugriff auf den Abschnitt
DLL_THREAD_DETACH ) wird um eins verringert. Insgesamt haben wir
2 - 1 = 1> 0 , daher wird das Betriebssystem unsere DLL nicht entladen. Darüber hinaus wird eine
Neuinitialisierung des Abschnitts
DLL_PROCESS_ATTACH nicht durchgeführt.
Daraus lässt sich übrigens ersehen, wie 1C in seinen neuesten Versionen mit einem ähnlichen Trick umgehen kann (und dies anscheinend bereits in den in 1C-8.3.14 und höher erstellten Konfigurationen). Es kann die Funktion
LoadLibraryEx () mit einem Parameter verwenden, der die Ausführung des Initialisierungsabschnitts
DLL_PROCESS_ATTACH blockiert.
Danach werden sofort die erforderlichen exportierten Funktionen aufgerufen. Wenn Sie sich den Code des VK-Beispiels für die native API ansehen, sehen Sie, dass der Initialisierungscode nicht aufgerufen werden muss, da er im VK-Format leer sein muss.
In Bezug auf die Beispiele für die Verwendung der COM-Technologie ist es offensichtlich, dass die Ausführung des Initialisierungsabschnitts
DLL_PROCESS_ATTACH dort erforderlich ist. Daher ist in nicht zu neuen Versionen von 1C, genauer gesagt in den Konfigurationen in 1C-8.3.13 und darunter, der 1C-Loader für uns geeignet:
(, , .COM);
Hier kann der letzte Parameter entfernt werden, da er standardmäßig impliziert ist. Gleichzeitig können sie in jeder höheren Version normal geöffnet werden. In den Versionen 1C83 passt der vorherige Bootloader
LoadExternalComponent (Component Address) nicht mehr zu uns (bzw. die „magischen Linien“ von Fedorov-Orefkov funktionieren dort nicht).
Im allgemeinen Fall kann das Problem, wie bereits erwähnt, mit einem externen Bootloader gelöst werden. Oder, was ganz natürlich ist, die Technologie der externen Komponenten von 1C auf die eine oder andere Weise zu beobachten.
Es sollte auch beachtet werden, dass die Experimente in Dateiversionen von 1C mit unterschiedlichen Bittiefen durchgeführt wurden. Um unsere Komponente herunterzuladen, müssen Sie möglicherweise die Eigenschaft "
Synchronous Call Usage Mode " in der Konfiguration auf "
Use " setzen.
Es versteht sich auch, dass Sie die Verwendung einer solchen Technik auf eigenes Risiko durchführen, im Voraus mit Testkonfigurationen oder Kopien von Arbeitern experimentieren, um mögliche Probleme in den Hauptprogrammen zu vermeiden.
Update vom 11.09.2019
Es stellte sich heraus, dass ich vergeblich besorgt war: „In den Versionen 1C-8.3.14 und höher wird der Initialisierungsabschnitt in der externen Komponente nicht mehr mit dem Wort„ vollständig “ausgeführt.“
Es stellt sich heraus, dass nur die Rückmeldung in der Funktion
ConnectExternalComponent () nicht verarbeitet werden muss. Unabhängig davon, welchen Komponententyp wir angeben:
COM oder
native API .
Sie können also eine Konfiguration in allen derzeit verfügbaren Versionen von 1C erstellen. Unsere Komponente sollte überall einwandfrei funktionieren. Das Erstellen eines externen Bootloaders ist relevant, es sei denn, Sie möchten die Konfiguration nicht ändern, was vollständig unterstützt wird.
In dieser Hinsicht wird der Code in den Testkonfigurationen für 1C82 und 1C83 geringfügig geändert, obwohl die Unterschiede zwischen ihnen nicht mehr grundlegend sind.
Gleichzeitig bleibt unsere Bemerkung, dass das 1C-Unternehmen die Ausführung des Initialisierungscodes in jedem VK leicht blockieren kann, zumindest für externe Komponenten wie die
native API , offensichtlich gültig, da dies nach ihrer Vorlage nicht erforderlich ist. Für einen
COM vom Typ VK
besteht bisher ein solcher Bedarf, aber was verhindert, dass er beseitigt wird? Mal sehen, ob diese Informationen berücksichtigt werden.