1C में प्लेटफ़ॉर्म के संस्करण 8.2 के साथ, डेटाबेस के साथ इंटरफ़ेस और उपयोगकर्ता इंटरैक्शन के निर्माण के लिए नए सिद्धांतों का उपयोग किया जाने लगा। नई तकनीक को "प्रबंधित एप्लिकेशन" कहा जाता है। 1सी सर्वर के उपयोगकर्ता और डेटाबेस के बीच प्रपत्रों के निर्माण और इंटरेक्शन योजना के तंत्र में सबसे बड़ी प्रोसेसिंग हुई है। सामान्य मोड अभी भी प्लेटफ़ॉर्म द्वारा समर्थित है, लेकिन समय के साथ सभी 1C उपयोगकर्ता प्रबंधित फॉर्म पर स्विच कर देंगे।

सामान्य उपयोगकर्ताओं के लिए, 1C दस्तावेज़ का प्रबंधित रूप केवल दिखने में सामान्य से भिन्न होता है। डेवलपर के लिए, यह अपने नियमों, कानूनों और शर्तों के साथ एक नया तंत्र है। कई क्षेत्रों में बदलाव हुए हैं, लेकिन अनुभवी 1C डेवलपर्स के बीच निम्नलिखित नवाचारों को महत्वपूर्ण माना जाता है:

  • प्लेटफ़ॉर्म द्वारा प्रपत्र संरचना और फ़ील्ड्स की नियुक्ति का स्वतंत्र गठन। यदि पहले डेवलपर्स पिक्सेल निर्दिष्ट करके किसी फ़ील्ड की स्थिति का वर्णन करते थे, तो अब केवल समूहीकरण के प्रकार को निर्दिष्ट करना संभव है;
  • प्रपत्र में प्रपत्र डेटा का प्रतिनिधित्व करने वाले विवरण और आदेश - निष्पादित की जाने वाली प्रक्रियाएं और कार्य शामिल हैं;
  • प्रपत्र कोड सर्वर और क्लाइंट दोनों पक्षों पर निष्पादित होता है। आखिरकार, फॉर्म स्वयं सर्वर पर बनाया गया एक कॉन्फ़िगरेशन ऑब्जेक्ट है और क्लाइंट पर प्रदर्शित होता है। इसका मतलब है कि यह क्लाइंट और सर्वर भागों को जोड़ता है;
  • क्लाइंट की ओर से, कई प्रकार के डेटा अनुपलब्ध हो गए हैं और इन्फोबेस में डेटा को बदलना अब संभव नहीं है;
  • प्रत्येक प्रक्रिया या फ़ंक्शन के लिए, एक विशेष सेटिंग निर्दिष्ट की जानी चाहिए - एक संकलन निर्देश। यह इस बात के लिए ज़िम्मेदार है कि कोड कहाँ निष्पादित किया गया है और निम्नलिखित मान ले सकता है:
    • नैक्लाइंट;
    • सर्वर पर;
    • ऑनसर्वरविथआउटकॉन्टेक्स्ट;
    • ऑनक्लाइंटऑनसर्वर;
    • क्लाइंट पर सर्वर पर बिना संदर्भ के।

प्रबंधित प्रपत्र मोड में अंतिम बिंदु विशेष रूप से तीव्र है। यदि किसी डेवलपर को निर्देशों या क्लाइंट-सर्वर इंटरैक्शन की कम समझ है, तो उसके लिए प्रबंधित फॉर्म बनाना बेहद मुश्किल होगा। 1सी:एंटरप्राइज़ 8.3 में प्रबंधित प्रपत्रों के निर्माण के सभी नए सिद्धांत त्रि-स्तरीय वास्तुकला की सामान्य अवधारणा से एकजुट हैं। इसमें क्लाइंट कंप्यूटर, एक 1सी सर्वर और एक डीबीएमएस शामिल है जहां डेटा संग्रहीत किया जाता है।

विन्यासकर्ता में प्रबंधित प्रपत्र को संपादित करना भी अलग हो गया है। कई पहलू बदल गए हैं और संस्करण 7.7 के डेवलपर्स, जिनके पास प्रबंधित प्रपत्र नहीं थे, आश्चर्यचकित हो सकते हैं। यहां तक ​​कि फॉर्म डिजाइनर का स्वरूप भी बदल गया है, जिसे किसी भी कॉन्फ़िगरेशन ऑब्जेक्ट फॉर्म को खोलकर देखा जा सकता है। किसी ऑब्जेक्ट को खोलते समय, हमें एक विंडो कई खंडों में विभाजित दिखाई देती है:

  1. प्रपत्र इंटरफ़ेस तत्व। ऊपर बाईं ओर एक विंडो है जो चयनित फॉर्म पर प्रदर्शित सभी फ़ील्ड को सूचीबद्ध करती है जो उपयोगकर्ता के साथ प्रोग्राम की सहभागिता सुनिश्चित करती है;
  2. प्रपत्र विवरण. शीर्ष दाईं ओर वह सारा डेटा है जिसके साथ फ़ॉर्म काम करता है। वे वे स्थान हैं जहां ग्राहक पक्ष पर जानकारी संग्रहीत की जाती है;
  3. एक प्रबंधित प्रपत्र प्रदर्शित करें. नीचे हम इंटरफ़ेस तत्वों के आधार पर एक प्रारंभिक रूप देखते हैं;
  4. फॉर्म मॉड्यूल. इस प्रपत्र द्वारा उपयोग की जाने वाली प्रक्रियाओं और कार्यों वाला अनुभाग। यहां आप उपयोगकर्ता और डेटाबेस दोनों के साथ प्रोग्राम के इंटरैक्शन के लिए एल्गोरिदम का कोड पा सकते हैं।

1सी डेवलपर्स ग्राहकों को प्रबंधित फॉर्म पर स्विच करने के लिए प्रोत्साहित कर रहे हैं, इसलिए प्रबंधित फॉर्म विकसित करने के सिद्धांतों को सीखना समय की बात है। एक बार जब आप इस प्रकार के फॉर्म के साथ काम करना शुरू कर देंगे, तो आपको एहसास होगा कि यह विकास को मानकीकृत करने और समान नियमों का पालन करने की दिशा में एक कदम है। इसलिए, 1C 8.3 में प्रबंधित प्रपत्रों के साथ काम करने की क्षमता 1C डेवलपर के रूप में आपके स्तर को बढ़ाती है।

प्रबंधित प्रपत्र डिज़ाइन सिद्धांत

सबसे पहले, 1सी प्रबंधित मोड के तंत्र को समझने के लिए, आपको याद रखना चाहिए कि फॉर्म सर्वर और क्लाइंट दोनों पर मौजूद है। इसके अलावा, क्लाइंट पर यह ऑब्जेक्ट प्रोग्राम के साथ उपयोगकर्ता के इंटरैक्शन के लिए इंटरफ़ेस की केवल एक छवि है। सभी गणनाएँ, एल्गोरिदम, परिकलन और प्रोसेसिंग केवल सर्वर साइड पर ही होनी चाहिए। यह न केवल क्लाइंट पर कई कार्यों और मापदंडों का उपयोग करने में असमर्थता से, बल्कि प्रदर्शन आवश्यकताओं से भी तय होता है।

आप निर्देश के नाम से यह पता लगा सकते हैं कि प्रक्रिया कहां निष्पादित की गई है, जिसे फॉर्म मॉड्यूल में प्रत्येक प्रक्रिया और फ़ंक्शन से पहले लिखा जाना चाहिए। शब्द "कोई संदर्भ नहीं" इंगित करता है कि प्रबंधित प्रपत्र पर डेटा सर्वर पर इस प्रक्रिया में पारित नहीं किया जाएगा। इस प्रकार, ऐसी प्रक्रियाओं में उपयोगकर्ता द्वारा दर्ज किए गए मानों के आधार पर एल्गोरिदम लिखना संभव नहीं होगा। यदि यह शब्दांकन निर्दिष्ट नहीं है, तो फॉर्म सभी विवरणों के साथ संपूर्ण रूप से प्रेषित होता है, और आप उन तक पहुंच पाएंगे।

1C डेवलपर्स दृढ़ता से गैर-प्रासंगिक सर्वर कॉल का उपयोग करने, उनकी संख्या को यथासंभव कम करने और क्लाइंट पर गणना न करने का प्रयास करने की दृढ़ता से सलाह देते हैं। सैद्धांतिक प्रशिक्षण के बिना नौसिखिए डेवलपर्स के लिए इन सभी नियमों का पालन करना और कोड को सही ढंग से बदलना मुश्किल है। इससे पहले कि आप स्वयं काम करना शुरू करें, प्रबंधित कॉन्फ़िगरेशन फॉर्म को खोलना और सिंटैक्स को देखना और क्लाइंट और सर्वर कैसे इंटरैक्ट करते हैं, यह देखना उपयोगी होगा।

&सर्वर प्रक्रिया पर स्टोरेज से भुगतान निपटान दस्तावेज़ प्राप्त करें (स्टोरेज में नया पता) और संदर्भ के बिना सर्वर पर फ़ंक्शन क्लाइंट के साथ गणना करता है (दस्तावेज़ आधार) और संदर्भ प्रक्रिया के बिना सर्वर पर चेकपॉइंट चयन सूची भरें (चयन सूची, प्रतिपक्ष, सूचना दिनांक) और क्लाइंट प्रक्रिया पर हेड काउंटरपार्टी को भरने के लिए पूर्णता (चयनित मूल्य, अतिरिक्त पैरामीटर) और सर्वर प्रक्रिया सेट पर भुगतान और निपटान दस्तावेजों का पाठ() और सर्वर फ़ंक्शन पर प्रारंभिक दस्तावेज़() भरा जाता है

यदि सभी डेवलपर्स उनका पालन करें तो 1सी फॉर्म विकसित करने के नए नियमों से बहुत लाभ होगा। इसके अलावा, हर कोई बेहतरी के लिए बदलाव महसूस करेगा - प्रोग्रामर, 1सी में काम करने वाली कंपनियां, फ्रेंचाइजी और 1सी डेवलपर्स। 1सी में प्रबंधित प्रपत्रों के सही उपयोग के मुख्य परिणाम:

  1. कॉन्फ़िगरेशन रखरखाव में आसानी और कोड पठनीयता में वृद्धि। इससे हम यह निष्कर्ष निकाल सकते हैं कि एक डेवलपर द्वारा लिखे गए एल्गोरिदम को दूसरे कर्मचारी द्वारा बहुत अधिक समय खर्च किए बिना हमेशा ठीक किया जा सकता है;
  2. क्लाइंट और सर्वर पर चल रहे कोड को अलग करना। यह देखते हुए कि इनमें से प्रत्येक पक्ष पर उपलब्ध कार्यक्षमता कितनी भिन्न है, उन्हें अलग करना सही कदम होगा;
  3. प्लेटफ़ॉर्म लॉजिक, क्लाइंट-सर्वर इंटरैक्शन और उनके द्वारा लिखे गए एल्गोरिदम की डेवलपर्स द्वारा गहरी समझ। संस्करण 8.0 और इससे पहले के संस्करणों में, क्लाइंट-सर्वर भाग को समझे बिना विकसित किए गए दस्तावेज़ों या संदर्भ पुस्तकों के प्रपत्र मिलना बहुत आम बात थी;
  4. कॉन्फ़िगरेशन का प्रदर्शन बढ़ाना और क्लाइंट कंप्यूटर पर लोड कम करना;
  5. शक्तिशाली पीसी खरीदने की आवश्यकता के अभाव के कारण कार्यस्थलों के लिए कंप्यूटर खरीदने की लागत कम हो गई।

मुख्य 1सी लॉन्च मोड के रूप में प्रबंधित फॉर्म का चयन करना कई आश्चर्य प्रस्तुत कर सकता है। लेकिन सही दृष्टिकोण के साथ, यह कदम बड़ा लाभ लाएगा, यही वजह है कि पूरे रूस में अधिक से अधिक 1C उपयोगकर्ता इसे लेने का निर्णय ले रहे हैं। इस तथ्य को ध्यान में रखते हुए कि 1सी कंपनी भविष्य में प्रबंधित रूपों के विकास पर भरोसा कर रही है, पुराने पारंपरिक रूपों पर बने रहना जोखिम भरा है।

शुभ दिन।

आप यहां क्या प्राप्त कर सकते हैं इसकी एक सूची यहां दी गई है:

  1. दस्तावेज़ के सारणीबद्ध भाग को एक पेड़ के रूप में प्रदर्शित करता है और इसे वापस सारणीबद्ध भाग में परिवर्तित करता है।
  2. सशर्त स्वरूपण और उसके प्रोग्रामेटिक उपयोग के साथ कार्य करना।
  3. प्रपत्र विवरण की संरचना में गतिशील परिवर्तन
  4. पेड़ को संपादित करने के लिए सुविधाजनक इंटरफ़ेस

और अब यहां हल की जा रही समस्या का प्रारंभिक डेटा दिया गया है:

हम किसी चीज़ के निर्माण के अनुमान के बारे में बात करेंगे। इसमें कार्य के प्रकार (इसके बाद इसे केवल कार्य के रूप में संदर्भित किया गया है) और सामग्रियों की एक निर्देशिका है। कार्य की प्रति इकाई सामग्री की खपत की एक दर होती है। एक दस्तावेज़ विकसित करना आवश्यक है जिसमें उपयोगकर्ता प्रत्येक कार्य के लिए भवन की प्रत्येक मंजिल पर इस कार्य की एक निश्चित मात्रा को करने के लिए आवश्यक मात्रा में सामग्रियों की एक सूची निर्दिष्ट कर सके (वास्तव में, कभी-कभी यह बिल्कुल भी मंजिल नहीं होती है) , लेकिन एक कमरा, एक खंड,... जो कुछ भी आप चाहते हैं कि निर्माणाधीन वस्तु को तोड़ना संभव है)।

वे। हमारे पास दस्तावेज़ के सारणीबद्ध भाग की निम्नलिखित संरचना है:

मंज़िल - यह अभी तक स्पष्ट नहीं है कि यह क्या है

कार्य का दायरा - क्रमांक 15.3

सामग्री की मात्रा - संख्या 15.3

यह सरल लगता है, लेकिन व्यवहार में हमें बहुत सारी दोहराव वाली जानकारी प्राप्त होती है। उदाहरण के लिए, हमारे पास दो कार्य हैं, प्रत्येक में 10 सामग्रियां और 9 मंजिलें हैं। यह दस्तावेज़ में 180 पंक्तियाँ होंगी, जिसमें "कार्य" कॉलम लगभग हर जगह समान है, प्रत्येक सामग्री को 9 बार दोहराया गया है।

नीचे एक ही जानकारी के दो निरूपण दिए गए हैं। 1 - रैखिक रूप से, 2 - गतिशील मात्रा स्तंभों वाले एक पेड़ के रूप में। स्पष्टता के लिए, मैंने अलग-अलग डेटा को रंगों में हाइलाइट किया: लाल - काम, नीला - सामग्री, फर्श - बकाइन, हरा - काम की मात्रा, नारंगी - लागत, काला - सामग्री की मात्रा।

दूसरा विकल्प स्पष्ट रूप से स्क्रीन स्थान बचाता है। पहले में हमारे पास जानकारी के साथ 150 सेल हैं, दूसरे में - 52। इसके अलावा, काम में जितनी अधिक मंजिलें और सामग्री होगी, बचत उतनी ही अधिक होगी।

यह दूसरा विकल्प है जिसे हम इस पाठ में लागू करेंगे।

तो, विन्यासकर्ता खोलें। मुझे लगता है कि आप दो निर्देशिकाओं, एक दस्तावेज़ और एक सूचना रजिस्टर से एक डेटा संरचना तैयार कर सकते हैं। इसलिए, मैं कहानी उस क्षण से शुरू करूंगा जब हमारे पास पहले से ही कुछ ऐसा होगा:

  • निर्देशिका "कार्य"
  • निर्देशिका "सामग्री" (या नामकरण - इससे कोई फर्क नहीं पड़ता)
  • दस्तावेज़ "..." (आप इसे "अनुमान" या कुछ और कह सकते हैं)
  • सूचना का रजिस्टर, आवधिक, जिसमें माप: कार्य, सामग्री; संसाधन: व्यय खाता (आप इसके लिए एक रिकॉर्डर बना सकते हैं, आप सीधे संपादन छोड़ सकते हैं)

सबसे पहले, आपको सारणीबद्ध भाग को पेड़ में परिवर्तित करने की विधि पर निर्णय लेने की आवश्यकता है। पहला (सरल) कार्य क्षेत्र के लिए कुल योग बनाने के लिए अनुरोध का उपयोग करना है। यहां नकारात्मक पक्ष यह है कि हम सारणीबद्ध भाग में सामग्रियों की विभिन्न रचनाओं के साथ दो समान कार्यों को नहीं जोड़ सकते हैं, क्योंकि कार्य एक प्रमुख क्षेत्र होगा. हमारे काम को पेड़ के एक नोड में संयोजित किया जाएगा, और इसमें मौजूद सामग्रियों को संयोजित किया जाएगा। दूसरा तरीका एक कुंजी फ़ील्ड जोड़ना है जो यह निर्धारित करेगा कि पंक्तियाँ एक ही नोड से संबंधित हैं या नहीं।

मुझे दूसरी विधि अधिक कष्टप्रद लगती है; यह दस्तावेज़ में अतिरिक्त विवरण जोड़ती है, लेकिन कोड पारदर्शी, समझने योग्य और विश्वसनीय हो जाता है। हम संख्या को कुंजी के रूप में उपयोग करेंगे। आइए कार्य में फ़ील्ड कार्य संख्या और सामग्री संख्या जोड़ें।

यहां हमारे पास तीसरे विश्लेषण-मंजिल का अभाव है। हमारे मामले में यह एक धनात्मक पूर्णांक होगा. सुविधा के लिए, हम हेडर में "मंजिलों की संख्या" फ़ील्ड जोड़ देंगे। यह क्षेत्र हमारे जीवन को बहुत सरल बना देगा। हम उस मामले पर विचार करते हैं जब सारणीबद्ध भाग में मंजिल संख्या 9 होती है, और मंजिलों की अधिकतम संख्या 8 होती है, तो ये पंक्तियाँ अस्वीकार्य होंगी;

अगला कदम "कार्य की मात्रा" फ़ील्ड से छुटकारा पाना और केवल मात्रा छोड़ना है। उन पंक्तियों में जहांmaterialNumberInWork = 0 हम मात्रा को कार्य की मात्रा के रूप में मानेंगे।

संरचना के साथ बस इतना ही, आइए आकार में आएं। आइए एक डिफ़ॉल्ट फॉर्म बनाएं जिसमें हम अपने पास मौजूद सभी चीज़ों को रखेंगे।

सबसे पहले, हम संख्या और तारीख को एक पंक्ति में बनाएंगे, यह क्रिया हमेशा स्वचालित रूप से की जानी चाहिए, यह कोड में एक सीढ़ी की तरह है।

इसके बाद, मान प्रकार "वैल्यू ट्री" के साथ फॉर्म विशेषता "वर्क ट्री" बनाएं। आइए इसमें कॉलम जोड़ें: संख्या, कार्यसामग्री, व्यय, यह कार्य है। हम तत्वों के बीच दो पेज बनाएंगे: एक सेवा पृष्ठ, जहां हम वास्तविक सारणीबद्ध भाग भेजेंगे, और एक पेड़, जहां हम पेड़ भेजेंगे। हम "यह एक काम है" चेकबॉक्स को छोड़कर पेड़ के सभी कॉलम प्रदर्शित करेंगे।

अब आइए कोड पर आते हैं। हमें एक ऐसी प्रक्रिया की आवश्यकता होगी जो मंजिलों की संख्या के आधार पर मात्राओं के साथ कॉलम बनाए। चलिए इसे "UpdateColumnComposition()" कहते हैं। इसमें हम फॉर्म विवरण और फॉर्म तत्वों को गतिशील रूप से बनाएंगे/हटाएंगे। यह प्रक्रिया तब लागू की जाएगी जब फॉर्म बन जाएगा और जब मंजिलों की संख्या बदल जाएगी। वे। प्रक्रिया बुलाए जाने के समय हमारे पास पहले से ही कुछ कॉलम हो सकते हैं और हमें उन्हें छोड़ना होगा ताकि डेटा न खोएं।

यहाँ इसका वाक्यविन्यास है:

&सर्वर पर
प्रक्रिया अद्यतन कॉलम संरचना()
//1. प्रपत्र संशोधन को संपादित करना, ट्री में कॉलम जोड़ना
पेड़ = फॉर्मएट्रिब्यूट्सवैल्यू ("वर्कट्री");
mCUremove = नई सारणी;
मैक्सकॉलमनंबर = 0;
लकड़ी से बने प्रत्येक कॉलम के लिए
यदि लेव(कॉलम.नाम, 3) = "गिनें"।
क्वांटिटीनंबर = संख्या(औसत(कॉलम.नाम,4));
यदि क्वांटिटीनंबर>ऑब्जेक्ट.नंबरऑफफ्लोर तो
mCUremove.Add(कॉलम);
अगर अंत;
यदि क्वांटिटीनंबर>मैक्सकॉलमनंबर तो
MaxColumnNumber = मात्रा संख्या;
अगर अंत;
अगर अंत;
अंतचक्र;
//2.
हटाने के लिए विवरण = नई सारणी;
प्रत्येक तत्व के लिएMKUMKU से हटाएँचक्र हटाएँ
हटाने के लिए विवरण। जोड़ें("कार्य वृक्ष।" + हटाने के लिए तत्व। नाम);
//प्रॉप्स से पहले फॉर्म एलिमेंट को क्रैश किया जाना चाहिए
Elements.Delete(Elements["वर्क ट्री" + MKUdelete element.Name])
अंतचक्र;
//3.
विवरण जोड़ें = नई सरणी;


NewFormAttributes = NewFormAttributes("नंबर"+NewNumber, NewTypeDescription("Number", NewNumberQualifiers(15,3)), "WorkTree", "से "+NewNumber);
विवरणToAdd.Add(NewFormAttributes);
अंतचक्र;
//4.
विवरण बदलें(विवरण जोड़ने के लिए, विवरण हटाने के लिए);
//5. हम नए फॉर्म तत्व बनाते हैं; उन्हें विशेषताएँ बनाने के बाद जोड़ा जाना चाहिए
एफ = 1 के लिए वस्तु के अनुसार मंजिलों की संख्या - कॉलम चक्र की अधिकतम संख्या
न्यूनंबर = मैक्सकॉलमनंबर + डब्ल्यू;
NewColumn = Elements.Add("WorkTreeNumber"+NewNumber, प्रकार("FormField"), Elements.WorkTree);
NewColumn.View = फॉर्मफ़ील्डव्यू.इनपुटफ़ील्ड;
NewColumn.DataPath = "TreeWork.Number"+NewNumber;
न्यूकॉलम.चौड़ाई = 7;
NewColumn.SetAction('OnChange', 'QuantityOnChange');
NewColumn.Header = "to" + w;
अंतचक्र;
प्रक्रिया का अंत

आइए हम इसके कार्य के चरणों पर टिप्पणी करें:

1. हम यह पता लगाने के लिए पेड़ के सभी स्तंभों को देखते हैं कि हमारे पास पहले से कितने हैं। यहां हम कॉलम के नाम से इसकी संख्या निर्धारित करते हैं और, यदि यह आवश्यक मात्रा से अधिक है, तो हम इसे हटाने के लिए सूची में जोड़ते हैं। हम मौजूदा कॉलम की अधिकतम संख्या भी ज्ञात करते हैं। (हम फॉर्म विवरण के साथ काम कर रहे हैं!!!)

2. हटाए जाने वाले स्तंभों की सूची को डेटा नामों वाली पंक्तियों की सूची में बदलें। एक बात के लिए, हम फॉर्म के तत्वों को तुरंत नष्ट कर देते हैं, क्योंकि... आप प्रपत्र पर प्रदर्शित विशेषताएँ नहीं हटा सकते।

3. उन स्तंभों की एक सूची बनाएं जिन्हें बनाने की आवश्यकता है।

4. अंतर्निहित प्रक्रिया परिवर्तन विवरण को कॉल करें, जिसके बाद हमारे पास अतिरिक्त कॉलम नहीं रह जाते हैं और गायब कॉलम दिखाई देते हैं।

दरअसल, इस प्रक्रिया में हमने देखा कि प्रपत्र विवरण और प्रपत्र तत्वों को सही ढंग से गतिशील रूप से कैसे खींचा जाए। महत्वपूर्ण बारीकियों में से:

-आप उन विवरणों को हटा नहीं सकते जो प्रोग्रामेटिक रूप से नहीं बनाए गए थे

-आप फॉर्म तत्वों में प्रयुक्त विवरण नहीं हटा सकते

उद्यम को सहेजने और लॉन्च करने के बाद, हम देखेंगे कि जब हम किसी मौजूदा दस्तावेज़ को खोलते हैं, तो आवश्यक संख्या में कॉलम तुरंत खींचे जाते हैं, और जब मंजिलों की संख्या बदलती है, तो सब कुछ तुरंत गतिशील रूप से फिर से तैयार हो जाता है।

आइए अब एक टेबल को ट्री में बदलने की प्रक्रिया लिखें। परीक्षण के लिए, दस्तावेज़ में सारणीबद्ध भाग को चित्र के अनुसार भरें:

इस उद्देश्य के लिए, हमने फॉर्म पर वास्तविक टैब भाग छोड़ दिया ताकि हम डिबग कर सकें और परिणाम की जांच कर सकें।

&सर्वर पर
प्रक्रिया TabPartInTree()
वृक्ष = फॉर्मएट्रिब्यूट्सवैल्यू('वर्कट्री');
पेड़.पंक्तियाँ.साफ़ करें();
लाइनवर्क = "";
जॉबनंबर = "";
सामग्री संख्या = "";
ऑब्जेक्ट.टेबुलरपार्ट1.सॉर्ट('जॉबनंबर,मटेरियलनंबरइनजॉब');
प्रत्येक चयन के लिए object.TabularPart1 लूप से
// मंजिलों की संख्या नियंत्रित करें
मंजिल = चयन.मंजिल;
यदि मंजिल > वस्तु. मंजिलों की संख्या तो
जारी रखना;
अगर अंत;
यदि मंजिल = 0 तो
जारी रखना;
अगर अंत;
यदि कार्य क्रमांक<>फिर जॉब नंबर चुनें
rowWorks = Tree.Lines.Add();
लाइनजॉब.नंबर = सिलेक्टजॉबनंबर;
लाइनवर्क.वर्कमटेरियल = चयन.कार्य;
stringJob.ThisJob = सत्य;
// अगला काम शुरू हो गया है, हम शुरुआत से ही सामग्रियों की गिनती शुरू करेंगे
सामग्री संख्या = "";
जॉबनंबर = सिलेक्टजॉबनंबर;
अगर अंत;
यदि चयनितMaterialNumberInJob = 0 है तो//यह जॉब लाइन है
लाइनवर्क["मात्रा"+तल] = चयन करें.मात्रा;
अन्यथा // यह सामग्री वाली एक पंक्ति है
यदि सामग्री संख्या<>फिर कार्य में सामग्री संख्या का चयन करें
stringMaterial = stringWork.Strings.Add();
stringMaterial.Number = चुनें.MaterialNumberInJob;
stringMaterial.WorkMaterial = चयन करें.Material;
लाइनमटेरियल.केकंसप्शन = चयन.केकंसप्शन;
stringMaterial.ThisWork = गलत;
मटेरियलनंबर=SelectedMaterialNumberInJob;
अगर अंत;
लाइनमटेरियल["मात्रा"+तल] = चयन करें.मात्रा;
अगर अंत;
अंतचक्र;
वैल्यू फॉर्मप्रॉप्स(ट्री,'वर्कट्री');
प्रक्रिया का अंत

यहां टिप्पणी करने के लिए बहुत कुछ नहीं है। फ़ील्ड "जॉब नंबर" और "मटेरियल नंबरइनजॉब" का उपयोग करके मैं यह निर्धारित करता हूं कि हमारे पास नौकरी या सामग्री के साथ एक पंक्ति है, क्रमशः रूट या कार्य में एक पंक्ति जोड़ें। यदि केवल फर्श बदला है, तो हम केवल मात्रा लेते हैं। अतिरिक्त फर्श काट दिए जाते हैं, गायब फर्श पेड़ की संरचना को खराब नहीं करेंगे।

हम इस प्रक्रिया को "UpdateColumnComposition()" के बाद सर्वर पर बनाते समय कहते हैं।

अब आप एंटरप्राइज़ लॉन्च करके और पहले बनाए गए दस्तावेज़ को खोलकर इसका परीक्षण कर सकते हैं।

अब हमें दस्तावेज़ लिखने से पहले इसके विपरीत करने की ज़रूरत है, पेड़ को एक सारणीबद्ध अनुभाग में सहेजना। हम प्रक्रिया लिखते हैं:

&ऑनक्लाइंट
प्रक्रिया PlaceTreeВTabPart()
वस्तु.सामग्री.साफ़ करें();
TreeWork.GetElements() लूप से प्रत्येक पेजवर्क के लिए


पी.फर्श = डब्ल्यू;
str.मात्रा = strWork["मात्रा"+w];
अंतचक्र;
PageWork.GetElements() लूप से प्रत्येक पृष्ठ सामग्री के लिए
डब्ल्यू = 1 के लिए मंजिलों की संख्या चक्र
str = ऑब्जेक्ट.सामग्री.जोड़ें();
पी.जॉबनंबर = पी.जॉब.नंबर;
p.MaterialNumberInWork = p.Material.Number;
पी.कार्य = str.कार्य.कार्यसामग्री;
str.Material = strMaterial.WorkMaterial;
str.Kउपभोग = str.Material.Kउपभोग;
पी.फर्श = डब्ल्यू;
str.मात्रा = strMaterial["मात्रा"+f];
अंतचक्र;
अंतचक्र;
अंतचक्र;
प्रक्रिया का अंत

1सी 8 में सशर्त प्रपत्र डिज़ाइन का उपयोग प्रबंधित प्रपत्र के तालिका तत्वों की दृश्यता, पहुंच और रंग को नियंत्रित करने के लिए किया जाता है (और इसका उपयोग एसीएस और गतिशील सूचियों में भी किया जाता है)। इसका उपयोग करने की सुविधा इस तथ्य में निहित है कि आप एक बार वह शर्त निर्धारित कर लें जिसके द्वारा आपके फॉर्म का डिज़ाइन बदलना चाहिए। इसके बाद जब यूजर फॉर्म के साथ काम करेगा तो कंडीशन चालू होने पर डिजाइन अपने आप बदल जाएगा। फॉर्म ईवेंट का उपयोग करने और अनावश्यक कोड लिखने की कोई आवश्यकता नहीं है।

इसे प्रतिस्थापित किया जाना चाहिए कि सशर्त प्रपत्र डिज़ाइन केवल प्रबंधित एप्लिकेशन (अकाउंटिंग 3.0, ZUP 3.0/3.1, ट्रेड मैनेजमेंट 11, आदि) का उपयोग करके कॉन्फ़िगरेशन में काम करता है।

सशर्त डिजाइन 1 एस। इंटरैक्टिव सेटअप

सशर्त स्टाइलिंग का एक अन्य लाभ यह है कि आप कोड की एक भी पंक्ति लिखे बिना इसे अनुकूलित कर सकते हैं। ऐसा करने के लिए, प्रपत्र की आवश्यकता है:

  • फॉर्म गुण खोलें -> उपस्थिति टैब -> सशर्त उपस्थिति खोलें;
  • एक टेबल खुलेगी ;
  • पहले कॉलम में आपको एक डिज़ाइन (या एक साथ कई) का चयन करना होगा;
  • दूसरे कॉलम में, वह शर्त सेट करें जिसके द्वारा चयनित डिज़ाइन ट्रिगर किया जाएगा;
  • तीसरे कॉलम में, आपको उन फॉर्म तत्वों का चयन करना होगा जो चयनित डिज़ाइन से प्रभावित होंगे।

कृपया ध्यान दें कि सशर्त स्टाइल केवल प्रपत्र तालिका कॉलम को प्रभावित करता है। आप कॉलम में अन्य प्रपत्र तत्वों का भी चयन कर सकते हैं स्वरूपित फ़ील्ड, लेकिन इससे कोई नतीजा नहीं निकलेगा.

सशर्त रूप डिजाइन। इंटरैक्टिव सेटअप उदाहरण

उदाहरण के तौर पर, मैंने एक सरल प्रसंस्करण लिखा, जिसके रूपों पर प्रकार के साथ एक विशेषता जोड़ी गई थी मूल्यों की तालिका, तीन कॉलम के साथ। और प्रकार सहित तीन विवरण भी बूलियन. आप प्रोसेसिंग डाउनलोड कर सकते हैं.

प्रोसेसिंग फॉर्म इस तरह दिखता है:

आइए इस फॉर्म के लिए निम्नलिखित सशर्त डिज़ाइन सेट करें: विवरण सेट करते समय कॉलम छुपाएं1अर्थ में सत्य, प्रपत्र तालिका में विवरण छिपाएँ स्तम्भ 1.

  • सशर्त प्रपत्र सेटिंग्स सेटिंग्स खोलें;
  • आइए तालिका में एक नई पंक्ति जोड़ें;
  • एक कॉलम में असबाबतीन बिंदुओं वाले बटन पर क्लिक करें और पैरामीटर चुनें दृश्यता, अर्थ नहीं;

  • एक कॉलम में स्थितितीन बिंदुओं वाले बटन पर क्लिक करें और खुलने वाली विंडो में एक नया चयन जोड़ें। आइए वहां निम्नलिखित मान दर्ज करें: बायाँ मान - HideColumn1, तुलना प्रकार - बराबर, दायाँ मान - हाँ;

  • एक कॉलम में स्वरूपित फ़ील्डतीन बिंदुओं वाले बटन पर क्लिक करें, खुलने वाली विंडो में एक नया तत्व जोड़ें और मान चुनें TableShapesColumn1;
  • परिणामस्वरूप, हमारे पास निम्नलिखित चित्र के समान एक सशर्त उपस्थिति सेटिंग होनी चाहिए;

  • चलिए बटन दबाते हैं ठीक है, हमारी प्रोसेसिंग को सेव करें और इसे मोड में चलाएं 1सी एंटरप्राइज;
  • बॉक्स को चेक करते समय कॉलम 1 छिपाएँ, फॉर्म के डिज़ाइन में निम्नलिखित परिवर्तन होंगे।


सशर्त पंजीकरण 8.3. सॉफ़्टवेयर कॉन्फ़िगरेशन उदाहरण

पिछले पैराग्राफ की तरह ही बाहरी प्रसंस्करण का उपयोग करते हुए, हम सशर्त उपस्थिति की प्रोग्रामेटिक सेटिंग का एक उदाहरण देंगे। आपको निम्नलिखित कार्य करने की आवश्यकता है: प्रॉप्स स्थापित करते समय रंग बदलेंकॉलम2अर्थ में सत्य, तालिका आकार में पृष्ठभूमि को रंग दें कॉलम 2, प्रॉप्स सेट करते समय कॉलम 3 को अनुपलब्ध बनाएंअर्थ में सत्य, प्रपत्र तालिका में अनुपलब्ध बनाएं प्रॉप्स कॉलम3.

आइए प्रपत्र मॉड्यूल में एक सर्वर प्रक्रिया बनाएं और उसे कॉल करें सशर्त उपस्थिति सेट करेंऔर तुरंत इसकी कॉल को प्रक्रिया में जोड़ें जब सर्वर पर बनाया गया.

&OnServerProcedureWhenCreatingOnServer(विफलता, मानक प्रसंस्करण) SetConditionalDesign(); प्रक्रिया का अंत और सर्वर पर प्रक्रिया सेट सशर्त उपस्थिति() प्रक्रिया का अंत

हम निम्नलिखित सभी कोड को एक प्रक्रिया में लिखेंगे सशर्त उपस्थिति सेट करें. हमें एक नया सशर्त प्रपत्र तत्व जोड़ने की आवश्यकता है; इसके लिए हम मानक प्रपत्र संग्रह का उपयोग करते हैं सशर्त गठन।

तत्व = कंडीशनलडिज़ाइन.एलिमेंट्स.एड();

इंटरैक्टिव संस्करण की तरह, हमें बनाए गए तत्व में डिज़ाइन, शर्तें और फ़ील्ड भरने की आवश्यकता है। किसी फ़ील्ड को निर्दिष्ट करने के लिए, हमें उस कॉलम के नाम के साथ एक डेटा संरचना फ़ील्ड बनाना होगा, जिस पर डिज़ाइन लागू किया जाएगा। यदि कई फ़ील्ड हैं, तो आवश्यक संख्या में डेटा संरचना फ़ील्ड जोड़ें। चयन के लिए, हम डेटा संरचना के लिए चयन तत्व बनाते हैं और उनके लिए बायां मान, दायां मान और तुलना प्रकार भरते हैं। आवश्यक डिज़ाइन सेट करने के लिए, उपलब्ध डिज़ाइन के पैरामीटर भरें। हमारा उदाहरण निम्नलिखित कोड उत्पन्न करता है:

तत्व = कंडीशनलडिज़ाइन.एलिमेंट्स.एड(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn2.Name); तत्व चयन = तत्व.चयन.तत्व.जोड़ें(प्रकार("डेटा संरचना चयन तत्व")); तत्व चयन.LeftValue = NewDataCompositionField('ChangeColumnColor2'); तत्व चयन.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = सत्य; Element.Design.SetParameterValue('BackgroundColor', NewColor(255, 0, 0));

इस प्रकार, हमने तालिका के दूसरे कॉलम के लिए एक डिज़ाइन बनाया। तीसरे कॉलम के लिए यह इसी तरह से किया जाता है, इसलिए हम इस पर विस्तार से ध्यान नहीं देंगे। अंतिम प्रक्रिया कोड सशर्त उपस्थिति सेट करेंइस तरह दिखेगा:

&सर्वर प्रक्रिया पर SetConditionalAppearance() तत्व = सशर्तAppearance.Elements.Add(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn2.Name); तत्व चयन = तत्व.चयन.तत्व.जोड़ें(प्रकार("डेटा संरचना चयन तत्व")); तत्व चयन.LeftValue = NewDataCompositionField('ChangeColumnColor2'); तत्व चयन.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = सत्य; Element.Design.SetParameterValue('BackgroundColor', NewColor(255, 0, 0)); तत्व = कंडीशनलडिज़ाइन.एलिमेंट्स.एड(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn3.Name); तत्व चयन = तत्व.चयन.तत्व.जोड़ें(प्रकार("डेटा संरचना चयन तत्व")); आइटम चयन.LeftValue = नया डेटाकंपोज़िशनफ़ील्ड('कॉलम3 को अनुपलब्ध बनाएं'); तत्व चयन.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = सत्य; Element.Design.SetParameterValue("उपलब्धता", गलत); प्रक्रिया का अंत

मैं आपको याद दिला दूं कि आप विश्लेषण किए गए उदाहरणों के आधार पर लिखी गई प्रोसेसिंग को डाउनलोड कर सकते हैं।

फार्म 1C में: एंटरप्राइज़ का उद्देश्य डेटाबेस में निहित जानकारी को प्रदर्शित करना और संपादित करना है। प्रपत्र विशिष्ट कॉन्फ़िगरेशन ऑब्जेक्ट से संबंधित हो सकते हैं या उनसे अलग मौजूद हो सकते हैं और संपूर्ण एप्लिकेशन समाधान द्वारा उपयोग किए जाते हैं।

उदाहरण के लिए, एक निर्देशिका नामपद्धतिइसके कई रूप हो सकते हैं जिनका उपयोग विशिष्ट उद्देश्यों के लिए किया जाएगा - एक निर्देशिका तत्व को संपादित करना, एक सूची प्रदर्शित करना, आदि:

इसके साथ ही, ऐसे सामान्य रूप भी हो सकते हैं जो विशिष्ट विन्यास वस्तुओं से संबंधित नहीं हैं - सामान्य रूप।

मूल रूप

प्रत्येक कॉन्फ़िगरेशन ऑब्जेक्ट का उपयोग कुछ मानक क्रियाएँ करने के लिए किया जा सकता है। उदाहरण के लिए, किसी भी निर्देशिका के लिए आपको उसके तत्वों की एक सूची प्रदर्शित करने, निर्देशिका के अलग-अलग तत्वों को प्रदर्शित करने, निर्देशिका का एक समूह प्रदर्शित करने, निर्देशिका से तत्वों और तत्वों के समूह का चयन करने की आवश्यकता हो सकती है। किसी भी दस्तावेज़ के लिए, ऐसी कार्रवाइयों की सूची बहुत छोटी होगी: दस्तावेज़ों की सूची देखना, दस्तावेज़ों की सूची से चयन करना और एक अलग दस्तावेज़ देखना।

यह सुनिश्चित करने के लिए कि ऐसी मानक क्रियाएं एप्लिकेशन समाधान ऑब्जेक्ट के डेटा के साथ की जाती हैं, उनमें से प्रत्येक के लिए बुनियादी रूपों का एक सेट होता है जिसका उपयोग संबंधित क्रियाएं करते समय किया जाएगा। इस वस्तु के अधीनस्थ किसी भी रूप को मुख्य के रूप में सौंपा जा सकता है। उदाहरण के लिए, निर्देशिका में नामपद्धतिनिम्नलिखित मूल रूप मौजूद हो सकते हैं:

और दस्तावेज़ वस्तुओं और सेवाओं की प्राप्तिमुख्य रूपों की संरचना भिन्न होगी:

इस प्रकार, यदि उपयोगकर्ता निर्देशिका सूची देखना चाहता है नामपद्धतिया दस्तावेज़ों की सूची वस्तुओं और सेवाओं की प्राप्ति, सिस्टम इन ऑब्जेक्टों के लिए सूची प्रपत्र के रूप में निर्दिष्ट संबंधित प्रपत्र खोलेगा।

स्वतः उत्पन्न प्रपत्र

1सी:एंटरप्राइज़ 8 प्रणाली की एक महत्वपूर्ण विशेषता स्वतः-जनित प्रपत्रों का तंत्र है। यह तंत्र डेवलपर को प्रत्येक कॉन्फ़िगरेशन ऑब्जेक्ट के लिए सभी संभावित फॉर्म बनाने से मुक्त करता है। डेवलपर को बस एक नया कॉन्फ़िगरेशन ऑब्जेक्ट जोड़ने की आवश्यकता है, और सिस्टम स्वयं उपयोगकर्ता के काम में सही समय पर, इस ऑब्जेक्ट में निहित जानकारी को प्रदर्शित करने के लिए आवश्यक फॉर्म उत्पन्न करेगा।

इस प्रकार, डेवलपर को एप्लिकेशन सॉल्यूशन ऑब्जेक्ट के अपने स्वयं के फॉर्म बनाने की आवश्यकता होती है, यदि उनमें सिस्टम द्वारा स्वचालित रूप से उत्पन्न फॉर्म से अंतर (अलग डिज़ाइन या विशिष्ट व्यवहार) होना चाहिए।

किसी प्रपत्र को डेटा से लिंक करना

कोई प्रपत्र किसी विशेष कॉन्फ़िगरेशन ऑब्जेक्ट से संबंधित है या नहीं, यह प्रपत्र में प्रदर्शित डेटा की संरचना को निर्धारित नहीं करता है। तथ्य यह है कि प्रपत्र, उदाहरण के लिए, एक निर्देशिका से संबंधित है नामपद्धति, आपको इसे इस निर्देशिका के लिए मुख्य प्रपत्रों में से एक के रूप में निर्दिष्ट करने की अनुमति देता है, लेकिन किसी भी तरह से यह निर्धारित नहीं करता है कि यह प्रपत्र कौन सा डेटा प्रदर्शित करेगा और इसका व्यवहार क्या होगा।

किसी प्रपत्र को डेटा के साथ जोड़ने के लिए, प्रपत्र विवरण का उपयोग किया जाता है, जो प्रपत्र द्वारा प्रदर्शित डेटा की सूची को दर्शाता है। सभी रूपों का व्यवहार समान होता है, चाहे वे कोई भी डेटा प्रदर्शित करें। हालाँकि, प्रपत्र विशेषताओं में से एक को इसके लिए मुख्य विशेषता के रूप में नामित किया जा सकता है (इसे बोल्ड में हाइलाइट किया गया है), इस स्थिति में प्रपत्र और उसके गुणों का मानक व्यवहार इस आधार पर पूरक किया जाएगा कि मुख्य प्रपत्र विशेषता किस प्रकार की है:

उदाहरण के लिए, यदि किसी दस्तावेज़ को मुख्य प्रपत्र विशेषता के रूप में निर्दिष्ट किया गया है वस्तुओं और सेवाओं की प्राप्ति, फिर फॉर्म बंद करते समय, सिस्टम इस दस्तावेज़ को रिकॉर्ड करने और पोस्ट करने की पुष्टि का अनुरोध करेगा। यदि आप, मान लीजिए, प्रपत्र की मुख्य विशेषता के रूप में एक निर्देशिका निर्दिष्ट करते हैं नामपद्धति, तो फॉर्म बंद करते समय ऐसा कोई पुष्टिकरण अनुरोध दिखाई नहीं देगा।

प्रपत्र संरचना

प्रपत्रों की मुख्य विशेषता यह है कि वे डेवलपर द्वारा "पिक्सेल दर पिक्सेल" विस्तार से तैयार नहीं किए जाते हैं। कॉन्फ़िगरेशन में एक फॉर्म फॉर्म की संरचना का तार्किक विवरण है। और प्रपत्र प्रदर्शित होने पर तत्वों का विशिष्ट प्लेसमेंट सिस्टम द्वारा स्वचालित रूप से किया जाता है।

प्रपत्र का प्रदर्शित भाग (उपयोगकर्ता को दिखाई देने वाला) प्रपत्र तत्वों वाले एक पेड़ के रूप में वर्णित है।

तत्व इनपुट फ़ील्ड, चेक बॉक्स, रेडियो बटन, बटन आदि हो सकते हैं। इसके अतिरिक्त, एक तत्व एक समूह हो सकता है जिसमें अन्य तत्व शामिल होते हैं। एक समूह को एक फ्रेम के साथ एक पैनल, पेज (बुकमार्क) के साथ एक पैनल, एक पेज या कमांड पैनल के रूप में दर्शाया जा सकता है। इसके अलावा, तत्व एक तालिका हो सकता है, जिसमें तत्व (कॉलम) भी शामिल हैं। तत्व संरचना बताती है कि फॉर्म कैसा दिखेगा।

प्रपत्र की सभी कार्यक्षमता विवरण और आदेशों के रूप में वर्णित है। विवरण वह डेटा है जिसके साथ फ़ॉर्म काम करता है, और आदेश निष्पादित की जाने वाली क्रियाएं हैं। इस प्रकार, प्रपत्र संपादक में डेवलपर को प्रपत्र में आवश्यक विवरण और आदेश शामिल करने होंगे, उन्हें प्रदर्शित करने वाले प्रपत्र तत्व बनाने होंगे और यदि आवश्यक हो, तो तत्वों को समूहों में व्यवस्थित करना होगा।

इस तार्किक विवरण के आधार पर, सिस्टम स्वचालित रूप से उपयोगकर्ता को प्रदर्शित करने के लिए फॉर्म की उपस्थिति उत्पन्न करता है। इस मामले में, सिस्टम उपयोगकर्ता के लिए फॉर्म तत्वों को यथासंभव सुविधाजनक रूप से व्यवस्थित करने के लिए प्रदर्शित डेटा के विभिन्न गुणों (उदाहरण के लिए, प्रकार) को ध्यान में रखता है।

डेवलपर विभिन्न सेटिंग्स के साथ तत्वों की व्यवस्था को प्रभावित कर सकता है। यह तत्वों का क्रम निर्धारित कर सकता है, वांछित चौड़ाई और ऊंचाई इंगित कर सकता है। हालाँकि, यह सिस्टम को फ़ॉर्म प्रदर्शित करने में मदद करने के लिए बस कुछ अतिरिक्त जानकारी है।

प्रपत्रों में, डेवलपर न केवल प्रपत्र के आदेशों का उपयोग कर सकता है, बल्कि संपूर्ण कॉन्फ़िगरेशन के कमांड इंटरफ़ेस में उपयोग किए जाने वाले वैश्विक आदेशों का भी उपयोग कर सकता है। इसके अलावा, पैरामीटर योग्य कमांड बनाना संभव है जो वर्तमान फॉर्म के विशिष्ट डेटा को ध्यान में रखते हुए अन्य फॉर्म खोलेंगे। उदाहरण के लिए, यह गोदाम में शेष राशि पर एक रिपोर्ट बुला सकता है जो वर्तमान में चालान फॉर्म में चयनित है।

मुख्य समस्या यह है कि 10-15 वर्षों में सामान्य रूपों के लिए बहुत सारे कोड पहले ही संकलित किए जा चुके हैं। कोई भी क्लाइंट-सर्वर पर यह सब दोबारा नहीं लिखना चाहता + बहुत से लोगों को इंटरफ़ेस के साथ काम करने के लिए प्रशिक्षित किया जाता है। अगले साल से शुरू होने वाले बीपी 3.0 में अनिवार्य परिवर्तन डेवलपर्स और एकाउंटेंट के मन में घबराहट पैदा कर रहा है। प्रतिक्रिया बहुत अप्रिय होगी. इसके अलावा, पेशे में प्रवेश के लिए मानक बढ़ रहे हैं, प्रोग्रामिंग अधिक कठिन हो गई है, और मानक प्रोग्रामिंग और भी अधिक कठिन हो गई है। मानक दस्तावेज़ों में नए एल्गोरिदम की लागत क्या है? जब आपके दस्तावेज़ों पर 2-3 बटन होते हैं तो यूवी बहुत अच्छा दिखता है, यूवी मोबाइल उपकरणों पर काम करने के लिए बहुत अच्छा है, लेकिन 0.01% कंपनियां इसका उपयोग करती हैं। यदि 1C कुछ नया लेकर नहीं आता है तो आपको स्विच करना होगा, लेकिन यह सभी के लिए लंबा और दर्दनाक होगा। और कंपनियों को खुद ही पैसा देना होगा.

मैंने भी अब तक केवल नियंत्रित रूपों से नकारात्मक चीजों का अनुभव किया है, यहां नवाचार के कुछ और नुकसान हैं:

  • कुछ नहीं? खैर, मुझे इसका सामना कई बार हुआ, उदाहरण के लिए, ZUP कॉन्फ़ में एक बाहरी प्रिंटिंग फॉर्म लिखना और संलग्न करना, वहां एक संपूर्ण महाकाव्य को संसाधित करना, इंटरनेट पर निर्देशों और कोड के पृष्ठों से भरा होना चाहिए।
    एक मोटे क्लाइंट पर मापदंडों के साथ एक प्रक्रिया होती है यानी। विकास तो मिनटों की बात है.
    और ब्रेक नग्न आंखों से बहुत कम दिखाई देते हैं
  • जहां तक ​​प्रबंधनीय फॉर्म तैयार करने में सक्षम होने की बात है - यह कला के लिए कला है, लेकिन व्यावहारिक बिंदु क्या है, खासकर फ़ाइल संस्करण के लिए?
  • मैंने 3 वर्षों तक यूवी में मूर्तिकला बनाई, लेकिन अब मैं सरल रूपों में वापस आ गया हूं, और मेरा विश्वास करो, यह परिवर्तन मनोवैज्ञानिक रूप से करना काफी कठिन था, लेकिन यह मेरी सचेत पसंद है क्योंकि यूवी में 1सी जो प्रदान करता है वह पूरी तरह से यूजी है…। हो सकता है कि कुछ वर्षों में 1सी कोई सफलता हासिल कर ले, लेकिन अब वह बस उस जगह की तलाश कर रही है जहां यह सफलता हासिल की जा सके...
  • कॉन्फिगरेटर में यूवी को खुलने में अधिक समय लगता है।
    उसके बाद, 8.1 में फॉर्म खोलना एक ट्रक से विमान में स्थानांतरित करने जैसा है!
  • सभी के लिए अधिक समस्याएं हैं, उपयोगकर्ता नए इंटरफ़ेस से हैरान हैं (हर कोई इसे स्वीकार नहीं करता है, लेकिन वे छोटी चीज़ों के बारे में बहुत अधिक मूर्ख हैं), आधे प्रोग्रामर व्यावसायिकता के लिए अनुपयुक्त हो गए हैं, औसत विशेषज्ञ के लिए यह कठिन हो गया है नौकरी ढूंढें और गुणवत्तापूर्ण उत्पाद कैसे तैयार करें। और यूवी का सबसे अच्छा विपणन विषय यह है कि वे हर जगह बढ़ते हैं कि संक्रमण एक साधारण अद्यतन के साथ होता है, लेकिन हर कोई भूल जाता है कि शुरुआत से आपको नवीनतम रिलीज के साथ पकड़ने की जरूरत है! लेकिन सिद्धांततः मुझे यह विचार पसंद आया!
  • मैं नहीं जानता, मेरा अनुभव इसके विपरीत दिखाता है। जहां कई वर्षों से सख्त रूपों में उछाल स्वचालित रूप से आ रहा है, नए यूवी मानक वाले में हर महीने यह शुरू होता है "क्यों, इस बटन को अपडेट करने के बाद 1C अब कहां है और अब यह काम क्यों नहीं करता है," जो, आप देखते हैं , गति नहीं जोड़ता.
  • - और भी कोड है
    - कोड अधिक जटिल हो गया है
    — मानक संशोधन करना कहीं अधिक कठिन है
    - जिन उपयोगकर्ताओं को मैंने UT11 दिया, उन्हें 10.x की तुलना में कोई लाभ नहीं मिला
    - लेकिन उन्हें कुछ मंदी और खोज जैसे कुछ कार्यों की कमी मिली (किसी कारण से वे आगे-पीछे खोज चाहते थे न कि चयन)
    मेरी राय है कि वेब क्लाइंट और टैबलेट के लिए बलिदान बहुत बड़े हैं। इसके अलावा, व्यक्तिगत रूप से, मैंने अभी तक किसी वेब क्लाइंट के साथ वास्तविक काम नहीं देखा है, जिसे रिमोट एक्सेस का सफलतापूर्वक उपयोग करने की आवश्यकता हो
  • क्लाइंट-सर्वर बेडलैम को प्रदर्शन और स्केलेबिलिटी में वृद्धि प्रदान करनी चाहिए, जबकि साथ ही लागत में कोडिंग में वृद्धि भी शामिल होनी चाहिए।
    हालाँकि, सभी को वृद्धि का अनुभव नहीं हुआ, इसलिए निराशा हुई। और साथ ही, हर कोई कोडिंग लागत पर आमादा था।
    पी.एस. दरअसल, मुझे नियंत्रित लोग पसंद हैं, मैं शांति से उनका सहारा लेता हूं। लेकिन ठेठ विकृत हो गए हैं.
  • अपने घरेलू कंप्यूटर (सामान्य कंप्यूटर) पर मैं अपना पेय व्यक्तिगत उद्यमियों के अनुसार संचालित करता हूं।
    8.3, बीपी3, चेकर्ड। मुख्य धारणा यह है कि मैं काम नहीं करता, बल्कि हर समय इंतजार करता हूं। बवासीर संबंधी प्रतिक्रिया. खाते के लिए SALT बस आश्चर्यजनक रूप से बनता है - यह मेगा-होल्डिंग में वर्ष के लिए खाता कार्ड जैसा लगता है।
  • UT11 एक जंगली ब्रेक, डरावनी और आम तौर पर एक बुरा सपना है।
    UT11 की तुलना में UT10 उड़ता है।
    यूवी के संबंध में - कीड़े वर्षों से संक्रमित हैं, सब कुछ टेढ़ा है, कॉलम कभी भी एक स्क्रीन पर फिट नहीं होते हैं, कई मामलों में स्ट्रेचिंग भयानक है।
    और मैं अभी भी बहुत सारे नुकसान सूचीबद्ध कर सकता हूं, लेकिन मैं शायद प्लसस के बारे में कुछ नहीं कहूंगा। उनका अस्तित्व ही नहीं है.
    फर्मों ने विशेष रूप से इन रूपों को समाप्त कर दिया, क्योंकि विकास की लागत अधिक थी, कोई विशेष नहीं थे और कोई सामान्य नहीं थे।

इसके कुछ फायदे हैं, लेकिन निश्चित रूप से वे मौजूद हैं...

पेशेवरों:

उत्तर प्रदेश ने क्या दिया, इसका उत्तर बहुत समय से मौजूद है:

क्रॉस प्लेटफ़ॉर्म क्लाइंट

  • खराब संचार लाइनों पर काम करना
  • ब्राउज़र के माध्यम से काम करने की क्षमता (क्लाइंट इंस्टॉल किए बिना)