Ada ide di sini untuk memberi selamat kepada kepala akuntan kami dengan cara yang kurang lebih orisinal, misalnya, dengan bantuan program 1C favoritnya? Tapi bagaimana caranya?
Setelah beberapa pemikiran, idenya mulai digunakan untuk latar belakang selamat gambar latar belakang di area klien dari bentuk konvensional untuk konfigurasi pada 1C77-1C82 atau di jendela eksternal untuk formulir yang dikelola 1C82 dan dalam semua kasus untuk 1C83. Di atasnya, tampilkan pesan yang diinginkan dan berikan tautan ke video ucapan selamat, seperti yang ditunjukkan pada gambar.
Bagian Satu - Menghasilkan
Jelas, ide ini bukanlah hal baru. Jadi, pada 2011,
solusi serupa diusulkan berdasarkan
FormEx.dll, oleh Aleksey Fedorov alias ALF . Dan pertanyaan tentang
bagaimana mencapai ini ditanyakan kembali pada tahun 2008.
Pada suatu waktu, kami juga menggunakan komponen ini untuk memuat gambar latar belakang ke 1C77. Tetapi mengunduh file-file bmp besar (dan yang lain tidak dapat digunakan) lambat (karena ini, gambar-gambar kecil yang diletakkan dengan ubin digunakan), jadi ada keinginan untuk menulis komponen eksternal Anda sendiri (VK), yang hanya akan mengunduh gambar yang diperlukan dan tidak lebih, kecuali apa lagi yang menjadi dasar pengujian untuk eksperimen.
Komponen seperti itu ditulis (juga, hanya untuk file-file bmp, menggunakan, jika perlu, ubin). Fungsi
WinAPI LoadImage () digunakan di sana. Dll ini tidak bertentangan dengan FormEx.dll, itu sederhana, cukup cepat dan disajikan untuk waktu yang lama.
Semua ini luar biasa, tetapi sudah waktunya untuk memperluas kemampuannya, dan di sini diperlukan pendekatan yang berbeda.
Dalam artikel ini, kami tidak membahas masalah membuat file multimedia. Ini bukan spesialisasi kami. Kami membatasi diri hanya untuk beberapa nuansa pemrograman komponen eksternal untuk 1C.
1C77
Karena versi platform 1C dapat berbeda, mungkin ada beberapa solusi. Dalam kasus kami, ini adalah konfigurasi pada 1C77 (Gbr. 1).
Fig. 1. Gambar selamat dalam konfigurasi tes pada 1C77.
Video di sini, meskipun miliknya sendiri, tetapi gagasan penciptaannya diperoleh dari
Anna Shiyanova, dengan nama panggilan "Kasus khusus" . Gadis ini memiliki bakat, dia bisa ditiru, tetapi hampir tidak mungkin untuk mengulangi gaya sepenuhnya. Dalam hal ini, saya hanya ingin setidaknya beberapa unsur kreativitas.
Jika salah satu rekan sudah bosan melihat ucapan selamat orang lain, maka mereka dapat membebani gambar dengan "
Alt + I " (Gbr. 2-3).
Fig. 2. Memilih gambar latar belakang yang berbeda di menu "File / Select Background" atau dengan "Alt + I".
Dan pada saat yang sama lihat informasi tentang modul yang digunakan oleh "
Alt + L " (Gbr. 3).
Fig. 3. Gambar latar kelebihan beban bersama dengan informasi tentang program ("Bantuan / Tentang modul LionExt32.dll" atau "Alt + L").
1C82 bentuk konvensional
Secara alami, mayoritas sekarang berorientasi pada G8 (1C8x). Namun, bekerja dengan gambar latar belakang dalam 1C hanya dimungkinkan pada formulir biasa dalam versi 8.2 dan lebih sedikit, dan jika Anda tidak menggunakan pemrosesan apa pun yang dimulai dalam mode "desktop", yang hanya akan sepenuhnya tumpang tindih dengan latar belakang kami (Gbr. 4).
Fig. 4. Gambar selamat dalam konfigurasi tes pada formulir biasa 1C82.
Perhatikan bahwa tautan ke Fig. 4 menunjukkan bukan video kami. Mereka ditampilkan hanya untuk tes.
Dalam bentuk biasa, 1C82 tidak lagi bekerja dengan cara standar untuk mengakses menu, karena tidak sistemik di sana, seperti pada "tujuh", tetapi "milik" (meskipun sistem dapat dibuat, tetapi mengapa kita memerlukan dua menu utama?). Namun, hotkey dapat digunakan. Dengan token yang sama, "Alt + I", di komponen kami, kami memanggil dialog, seperti pada Gambar. 2, dan memuat latar belakang lain (Gambar 5).
Fig. 5. Gambar latar kelebihan beban dalam bentuk "tebal" 1C82.
Demikian pula, Anda dapat memperoleh informasi tentang modul dengan menekan tombol "Alt + L", seperti pada gambar. 3.
1C82 formulir terkelola
Untuk formulir terkelola di 1C82, Anda masih dapat menemukan jendela yang kami butuhkan di tingkat sarang ketujuh, seperti "
V8FormElement " dan menggambar di atasnya, tetapi entah bagaimana itu tidak menarik.
Bagi kami, dari pertimbangan ini maka lebih mudah untuk membuat jendela eksternal dengan pesan ucapan selamat (Gbr. 6) daripada menangani setiap kasus individu. Jendela itu sendiri dapat ditutup, lebih tepatnya, diminimalkan oleh "
Esc ", "
Ctrl + F4 ", "
Alt + F4 " atau dengan mengklik pada "
cross ".
Fig. 6. Gambar ucapan selamat dalam konfigurasi pengujian pada formulir yang dikelola 1C82.
Selain itu, jendela yang diperkecil (Gbr. 7) dapat diperluas lagi.
Fig. 7. Gambar jendela eksternal yang diperkecil pada formulir terkelola 1C82.
Dimensi dan posisi relatif jendela eksternal dapat diubah, semuanya seperti biasa di sini (lihat gambar yang diperbesar dari jendela eksternal pada Gambar. 6 dan Gambar. 10). Perhatikan bahwa hotkey hanya berfungsi jika jendela eksternal aktif.
1C83 bentuk konvensional
Di 1C83 tidak ada jendela anak sama sekali, yang dapat berfungsi sebagai kriteria untuk versi 1C di dll kami. Selain itu, bentuk "tebal" adalah bingkai jendela (Gbr. 8), dan formulir yang dikelola tanpa bingkai (Gbr. 9). Artinya, segala sesuatu yang bukan bingkai bisa digambar ulang. Bingkai juga dapat digambar ulang, tetapi hanya sebagai elemen sistem.
Di sini kami membuat jendela uji menggunakan perpustakaan dinamis dan menempatkannya ke jendela 1C utama. Perbedaan perilaku terlihat pada gambar.
1C83 formulir yang dikelola
Dalam kasus 1C83, seperti pada formulir yang dikelola 1C82, kami akan menarik ucapan selamat kami tidak dengan latar belakang, tetapi di jendela terpisah, prototipe yang ditunjukkan pada Gambar. 8-9. Akibatnya, komponen yang diinginkan (
LionExt32.dll atau
LionExt64.dll ) akan memberikan hasil berikut (Gbr. 10-12).
Fig. 10. Gambar latar belakang di jendela eksternal untuk bentuk konvensional 1C83.
Fig. 11. Gambar latar belakang di jendela eksternal bentuk terkelola 1C83, rilis 14, versi 64-bit.
Fig. 12. Gambar latar belakang di jendela eksternal formulir terkelola 1C83, rilis versi 15, 64-bit.
Temuan awal
Komponen ini sebenarnya digunakan dalam praktik (Gbr. 1), kepala akuntan puas, semuanya berjalan dengan luar biasa. Sepanjang jalan, ternyata pengguna suka memilih gambar latar belakang mereka sendiri, dalam hal ini, untuk bekerja pada "tujuh". Untuk G8, komponen kami disesuaikan dengan cadangan untuk masa depan, sementara itu harus dianggap sebagai versi demo.
Yang menarik di sini adalah bahwa
komponen ini tidak memerlukan kepatuhan dengan teknologi menciptakan komponen eksternal dari 1C . Mungkin ide-ide tambahan akan muncul untuk memperluas kemampuannya. Misalnya, untuk konfigurasi yang didukung penuh, Anda tidak ingin membuat perubahan pada kode 1C tanpa perlu khusus. Dalam hal ini, seseorang dapat menawarkan opsi untuk memuat eksternal dll. Sewenang-wenang ke ruang alamat 1C. Tetapi ini adalah topik dari artikel lain.
Dari inovasi teknis, kunci digunakan untuk membongkar komponen kami dengan platform 1C (karena tidak sesuai dengan format VK). Selain itu, trik lain memungkinkan untuk menetapkan
menu lokal ke jendela anak, karena sistem operasi Windows memblokir pembuatan menu seperti itu untuk jendela di bawahnya. Karenanya, Anda tidak akan melihat menu lokal di
MDI (Multi Document Interface) yang sama di mana saja. Ia digantikan oleh panel perintah, bilah alat, dan menu konteks. Masih ada waktu untuk memperbarui windows. Kadang-kadang terjadi bahwa
UpdateWindow () atau
InvalidateRect () tidak berfungsi dengan baik. Tetapi beberapa fungsi dalam kasus ini berhasil:
ShowWindow(hWnd, SW_HIDE); ShowWindow(hWnd, SW_SHOW);
Juga harus dicatat bahwa komponen kami dapat bertentangan dengan yang lain, misalnya, dengan FormEx.dll untuk 1C77. Dalam hal ini, itu harus dimuat terakhir.
Omong-omong, diketahui bahwa jika Anda membuat konfigurasi dalam versi 1C-8.3.14 dan lebih tinggi, maka komponen tidak dimuat dengan cara biasa. Tetapi jika database dibuat dalam versi 1C sebelumnya, dan terbuka di versi terbaru, maka tidak ada masalah memuat VK kami. Sekali lagi ini mengisyaratkan perlunya membuat bootloader eksternal.
Proyek ini menggunakan subsistem
WinAPI GDI + . Dengan menggunakannya, Anda dapat menampilkan gambar berbagai format:
bmp, jpg, gif, png, tif, dan lainnya. Dalam urutan yang sama, komponen mencoba memuat
Main pertama yang tersedia
. * File dari direktori
Pics lokal dalam konfigurasi saat ini. Jika tidak ada file-file ini yang ditemukan, maka gambar latar belakang sederhana dari sumber daya komponen digunakan. Dalam gbr. Gambar 13 menunjukkan gambar latar belakang ini untuk bentuk biasa 64-bit 1C83, rilis 15. Untuk perubahan, jendela eksternal bahasa gaul telah diperbesar dan gambar lain dari file
Main1.png , yang telah "ubin", telah ditambahkan ke latar belakangnya.
Fig. 13. Gambar latar belakang default untuk bentuk biasa 64-bit 1C83, rilis 15. Selain itu, gambar lain dari file Main1.png, meletakkan "ubin", telah ditambahkan.
Tidak ada perbedaan dalam pengoperasian komponen dalam mode bit yang berbeda.
Dapat juga dicatat bahwa komponen kami mensubklasifikasikan jendela 1C utama dan klien MDI-nya, jika ada. Ini, tampaknya, berfungsi sebagai sumber konflik dengan FormEx.dll ketika dimuat terakhir (dalam 1C77).
Bagian Dua - Teknis
Proyek itu sendiri dapat ditemukan di tautan berikut:
Proyek
C ++ dapat dengan mudah diadaptasi untuk versi
10 jika string "
v120 " diganti oleh "
v100 " dan "
ToolsVersion =" 12.0 " " oleh "
ToolsVersion =" 4.0 " dalam file konfigurasi.
Kode untuk versi
1C 32- bit dan
64- bit
adalah sama dan dapat dikompilasi pada saat yang sama.
Versi 1C77 ditentukan dalam komponen eksternal oleh
gagang fungsi GetMenu
() yang tidak nol, dan versi 1C83, oleh tidak adanya jendela anak di jendela utama, pegangan yang ditentukan oleh fungsi
GetForegroundWindow () .
Tentang teknologi pembuatan komponen eksternal untuk 1C
Pada cakram ITS dari perusahaan 1C, dan di Internet, orang dapat dengan mudah menemukan informasi tentang pembuatan VC dan templat yang sesuai dalam berbagai bahasa pemrograman. Namun, pada masa 1C77, pola-pola ini memuaskan "tidak hanya semua orang."
Jika Anda melihat beberapa komponen yang banyak digunakan, terutama untuk 1C77, Anda akan melihat bahwa penulisnya sering menggunakan metode pemrograman khusus untuk memperluas kemampuan desain mereka.
Mungkin salah satu komponen eksternal pertama tersebut adalah
"RAINBOW ADDIN 2000 untuk 1C: Enterprise 7.7 .
" Mungkin yang paling penting di sini adalah penetrasi yang lebih dalam ke dalam usus "tujuh" daripada yang diizinkan teknologi VK resmi, meskipun mengikuti format VK. Ini dicapai karena metode header yang diterima, sangat mungkin tidak standar, file * .h dari file library 1C77 yang digunakan dalam proyek-proyek lain yang dikenal luas.
Memang, jika fungsi 1C seperti
LoadExternalComponent () dan
ConnectExternalComponent () memungkinkan Anda untuk menanamkan
dll eksternal ke dalam ruang alamat Anda sendiri (pertama-tama, yang memenuhi format teknologi VK), lalu mengapa tidak program-program pengguna menyerah pada godaan dan mencoba mengakses yang lain yang tersembunyi dari mereka, prosedur dan objek lain dari platform target? Pendekatan ini telah berhasil ditunjukkan oleh komponen
Rainbow.dll .
Kemudian, mekanisme serupa diadopsi oleh penulis lain dari komponen 1C versi 7.7. Catatan khusus adalah komponen untuk "tujuh"
1C ++. Dll dan, seolah-olah, kasus khusus dari
FormEx.dll .
Tetapi pendekatan nontrivial untuk desain komponen eksternal untuk 1C77 tidak berakhir di sana. Rupanya, seseorang seharusnya mengatakan: “Mengapa kita membutuhkan pandai besi? Kami tidak membutuhkan pandai besi! " Di sini, dengan "pandai besi" yang kami maksud adalah teknologi COM dari MicroSoft, yang, dalam arti tertentu, diikuti oleh teknologi VK untuk "tujuh". Tidak, well, sungguh, mengapa kita memerlukan registri jika kita mengunduh VK kita secara langsung? Ini mungkin masuk akal untuk browser web yang bekerja dengan Internet, tetapi untuk operasi lokal, menggunakan registri jelas berlebihan. Paling tidak, ini bukan prasyarat. Selain itu, untuk mengedit registri Anda memerlukan hak administratif.
Perhatikan bahwa 1C sangat menyukai teknologi ini (setidaknya sampai porting 1C ke Linux). Kami memperlakukannya dengan sangat keren. COM nyaman untuk menggunakan komponen ActiveX dan ini wajar, karena yang terakhir awalnya dikembangkan untuk Internet.
Namun, dalam versi terbaru, 1C menambahkan kemampuan untuk menggunakan teknologi
Native API , yang menghilangkan kebutuhan untuk registri. Pada prinsipnya, inilah yang kita butuhkan, kecuali bahwa teknologi ini tidak berlaku dalam "tujuh", dan itu, bagi sebagian orang, masih relevan.
Tetapi terkadang tugas yang relatif sederhana muncul ketika Anda tidak ingin menggunakan banyak kode boilerplate untuk VK dan disarankan untuk bekerja dengan 1C dari sisi komponen eksternal saja. Seperti, katakanlah, dalam kasus kami, demonstrasi gambar ucapan selamat di area klien atau, jika perlu, di jendela terpisah, konfigurasi 1C.
Dengan kata lain, jika kita tidak akan secara langsung bertukar data antara 1C dan VK, maka kita akan cukup senang dengan versi komponen eksternal yang lebih sederhana dan lebih universal untuk 1C. Kesederhanaan di sini akan tercapai karena kurangnya kode boilerplate.
Teknologi alternatif untuk membuat VK untuk 1C
Karena VK untuk 1C adalah kasus khusus dari
server COM (sebelum teknologi
Native API ), ada pengembang VK yang mengatakan: "COM - no!". Aktivitas ke arah
Alexander Orefkov ini terutama terlihat. Komponennya "
1sqlite.dll ", "
TurboMD.dll ", dan mungkin yang lain, jangan gunakan COM dari kata "sepenuhnya". Komponen
Yoksel ("
SpreadSheet.dll ") juga berkembang di sepanjang jalur ini.
Tetapi bagaimana cara VK loader dari 1C77 memuat komponen-komponen ini? Lagi pula, mereka bahkan tidak mencoba meniru semacam COM di sana. Memang, jika kita mencoba terus terang menyelipkan beberapa dll standar yang dihasilkan oleh, katakanlah, wizard
MS VC ++ ke dalam fungsi
LoadExternalComponent () , maka kita akan memiliki gelandangan.
Dalam "tujuh" kita mendapatkan pesan seperti:
Terjadi galat saat membuat objek dari komponen <Full Path \ Component Name> .dll (CLSID tidak ada)
Dalam klien "tebal" 32-bit dari pesan "delapan" akan serupa. Dll yang sama akan menyebabkan bersumpah serupa (Gbr. 15):
Metode konteks panggilan kesalahan (Memuat Komponen Eksternal): Kesalahan saat memuat komponen eksternal
Jadi, bagaimana perpustakaan yang disebutkan bisa menyelesaikan masalah ini? Mempelajari teks-teks dari program Orefkov dan Yoksel, kami akhirnya menyimpulkan bahwa "
garis ajaib " berikut dalam file sumber daya (* .rc atau * .rc2) adalah "yang harus disalahkan":
STRINGTABLE DISCARDABLE BEGIN 100 "\0sd" // 1sqlite.dll 100 "\0tmd" // TurboMD.dll 100 "\0f" // SpreadSheet.dll END
Yaitu tanpa gagal, dalam sumber daya program ada garis dengan pengenal
100 dan beberapa nilai string, karakter pertama yang nol. Anda dapat bereksperimen dengan variasi string semacam itu, tetapi string "
\ 0L " tidak masalah bagi saya. Jadi, kami membuat file sumber daya dan menulis baris seperti ini:
STRINGTABLE DISCARDABLE BEGIN 100 "\0L" // 1 ! END
Kami menghubungkan file ini ke proyek dll kami yang paling sederhana yang dihasilkan oleh wizard MS C ++, tambahkan kode:
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; }
dan amati (Gbr. 14).
Fig. 14. Penggunaan "VK" paling sederhana di 1C82.
Tanpa "garis ajaib" dalam file sumber daya, dll. Kami, setelah menampilkan MessageBox, segera bongkar dengan kutukan dari 1C (Gbr. 15).
Fig. 15. Kesalahan memuat dll biasa di 1C82.
Artinya, garis-garis ini benar-benar memiliki efek ajaib pada pemuat komponen 1C eksternal.
Yang pertama, tampaknya, "garis ajaib" dijelaskan dalam artikel lamanya oleh
Alexei Fedorov (ALF) , tetapi tautan ke sana tidak lagi tersedia, dan penulis tidak melihat titik dalam publikasi ulang. Selain itu,
Alexander Orefkov menggunakannya secara paling intensif, dan tampaknya, dari pengajuannya, penulisnya adalah
Yoksel . Oleh karena itu, kita akan berbicara tentang garis
"ajaib" dari Fedorov-Orefkov . Arti mereka adalah untuk memblokir pembongkaran file-file non-standar (dari sudut pandang 1C) dll dengan fungsi
LoadExternalComponent () . Selain itu, seperti yang kita lihat, teknik ini bekerja tidak hanya dalam 1C77, tetapi juga dalam bentuk 1C82 "tebal".
Namun, dalam bentuk terkelola 1C82 dan di semua versi 1C83, fitur ini sudah benar-benar rusak (loader lain juga muncul -
ConnectExternalComponent () ).
Dengan demikian, dalam versi modern 1C, Anda perlu mencari alternatif sederhana lain dari garis "ajaib" Fedorov-Orefkov.
Dan alternatif seperti itu mudah ditawarkan. Intinya sederhana. Loader 1C mengeluarkan komponen "salah" jika ia mengeluarkan pengecualian ketika mencoba mengaksesnya menggunakan protokol yang ditentukan, misalnya, ketika meminta versi komponen. Secara alami, kami tidak memiliki yang seperti ini, yang berfungsi sebagai dasar untuk menurunkan dll yang tidak standar. Tetapi persyaratan 1C untuk sistem operasi untuk membongkar pustaka dinamis ini dapat diabaikan oleh sistem jika VK ini masih digunakan di suatu tempat. Alih-alih penghapusan itu sendiri, sistem hanya mengurangi penghitung penggunaan modul yang diinginkan. Dan secara fisik hapus tidak lebih awal dari penghitung ini diatur ulang. Oleh karena itu, tugas kami adalah meningkatkan penghitung ini secara buatan.
Untuk melakukan ini, Anda dapat memanggil fungsi dll kami WinAPI
LoadLibrary () lagi di bagian
DLL_THREAD_ATTACH BOOL APIENTRY DllMain(HANDLE hModule, DWORD dwReason, LPVOID lpReserved) { switch(dwReason) { case DLL_PROCESS_ATTACH: { WCHAR szDllName[_MAX_PATH] = {0};
Itu saja! Masalahnya teratasi. Memanggil kembali perpustakaan dinamis yang sama akan menambah penghitung penggunaannya satu, dan membongkar (dengan akses awal ke bagian
DLL_THREAD_DETACH ) akan berkurang satu. Total yang kita miliki
2 - 1 = 1> 0 , oleh karena itu, sistem operasi tidak akan membongkar dll. Selain itu, yang penting,
reinisialisasi bagian
DLL_PROCESS_ATTACH tidak akan terjadi.
Dari sini, omong-omong, orang dapat melihat bagaimana 1C dapat menangani trik serupa dalam versi terbarunya (dan, tampaknya, sudah melakukan ini dalam konfigurasi yang dibuat pada 1C-8.3.14 dan lebih tinggi). Itu dapat menggunakan fungsi
LoadLibraryEx () dengan parameter yang memblokir eksekusi bagian inisialisasi
DLL_PROCESS_ATTACH , setelah itu akan segera memanggil fungsi yang diperlukan yang diekspor. Dan, memang, jika Anda melihat kode contoh VK untuk Native API, Anda dapat melihat bahwa tidak perlu memanggil kode inisialisasi, karena harus kosong oleh format VK.
Mengenai contoh-contoh menggunakan teknologi COM, jelas bahwa pelaksanaan bagian inisialisasi
DLL_PROCESS_ATTACH diperlukan di sana, oleh karena itu, dalam versi 1C yang tidak terlalu baru, lebih tepatnya, dalam konfigurasi yang dibuat pada 1C-8.3.13 dan di bawahnya, loader 1C cocok untuk kita:
(, , .COM);
Di sini parameter terakhir dapat dihapus, karena tersirat secara default. Pada saat yang sama, mereka dapat membuka secara normal di versi yang lebih tinggi. Dalam versi 1C83, bootloader
LoadExternalComponent (Komponen Alamat) sebelumnya tidak lagi cocok untuk kita (masing-masing, "garis ajaib" Fedorov-Orefkov tidak berfungsi di sana).
Dalam kasus umum, seperti yang telah disebutkan, masalah dapat diselesaikan dengan menggunakan bootloader eksternal. Atau, yang cukup alami, untuk mengamati, sampai taraf tertentu, teknologi komponen eksternal 1C.
Juga harus dicatat bahwa percobaan yang kami lakukan dalam versi file 1C dengan kedalaman bit berbeda. Untuk mengunduh komponen kami, Anda mungkin perlu mengatur properti "
Mode Penggunaan Panggilan Sinkron " menjadi "
Gunakan " dalam konfigurasi.
Juga harus dipahami bahwa Anda melakukan penggunaan teknik semacam itu dengan risiko Anda sendiri, bereksperimen terlebih dahulu pada konfigurasi tes atau salinan pekerja untuk menghindari kemungkinan masalah dalam program utama.
Pembaruan dari 09/11/2019
Ternyata saya khawatir sia-sia bahwa: "dalam versi 1C-8.3.14 dan lebih tinggi, bagian inisialisasi dalam komponen eksternal tidak lagi dilakukan dari kata" sepenuhnya "."
Ternyata hanya pesan kembali di fungsi
ConnectExternalComponent () yang tidak perlu diproses. Selain itu, apa pun jenis komponen yang kami tentukan:
COM atau
Native API .
Dengan demikian, Anda dapat membuat konfigurasi di semua versi 1C yang tersedia saat ini, komponen kami akan berfungsi dengan baik di mana-mana, dan membuat bootloader eksternal akan relevan, kecuali untuk kasus ketika Anda tidak ingin mengubah konfigurasi, yang didukung sepenuhnya.
Dalam hal ini, kode dalam konfigurasi tes untuk 1C82 dan 1C83 sedikit berubah, meskipun perbedaan di antara mereka tidak lagi mendasar.
Pada saat yang sama, komentar kami bahwa perusahaan 1C dapat dengan mudah memblokir eksekusi kode inisialisasi dalam VK apa pun, setidaknya untuk komponen eksternal seperti
API Asli , jelas tetap valid, karena menilai dari templat mereka, ini tidak perlu. Untuk tipe VK
COM, ada kebutuhan seperti itu sejauh ini, tetapi apa yang mencegahnya menyingkirkan? Pada saat yang sama, mari kita lihat apakah mereka akan mempertimbangkan informasi ini?