دکمه های رادیویی، برنامه معمولی، فرم های مدیریت شده. سوئیچ ها، برنامه معمولی، فرم های مدیریت شده 1c مشکلات با فرم های مدیریت شده

پلت فرم 1C: Enterprise به شما امکان می دهد عناصر یک فرم مدیریت شده را به صورت برنامه نویسی اضافه و تغییر دهید. بیایید ببینیم چرا ممکن است این مورد نیاز باشد.

ممکن است در چند مورد نیاز به تغییر برنامه ای فرم باشد:

• هنگام نهایی کردن پیکربندی های معمولی برای تسهیل روند به روز رسانی بعدی. در این صورت فقط ماژول فرم تغییر خواهد کرد. به روز رسانی ماژول ها بسیار ساده تر از یک فرم است.
• هنگام پیاده سازی برخی از الگوریتم های کلی. برای مثال در زیرسیستم «ممنوعیت ویرایش جزئیات اشیاء» برای تمامی اشیاء متصل به زیرسیستم، دکمه ای به صورت برنامه نویسی ایجاد می شود تا امکان ویرایش جزئیات را فراهم کند.
• هنگام پیاده سازی برخی از الگوریتم های خاص. به عنوان مثال، فیلدهایی برای ویرایش جزئیات اضافی در کتاب مرجع Nomenclature ایجاد می شود.

در یک فرم مدیریت شده، می توانید به صورت برنامه نویسی اضافه کنید، تغییر دهید و حذف کنید:

• ملزومات؛
• دستورات محلی؛
• عناصر.

تمام این عملیات فقط روی سرور امکان پذیر است.

تغییر شکل برنامه ای محدودیت هایی دارد:

• شما فقط می توانید ویژگی ها / دستورات / عناصر اضافه شده را حذف کنید. شما نمی توانید به صورت برنامه ریزی شده اشیاء ایجاد شده در پیکربندی را حذف کنید.
• تخصیص ویژگی به عنوان اصلی غیرممکن است.

تغییر دستورات فرم

برای مدیریت ترکیب دستورات برای یک شی فرم مدیریت شدهمجموعه داشته باشد تیم ها

اضافه کردن (< ИмяКоманды >)

تعداد ()

پیدا کردن (< ИмяКоманды >)

حذف (< Команда >)

مجموعه Commands هم روی کلاینت و هم روی سرور در دسترس است. تغییر مجموعه (روش های افزودن () و حذف ()) فقط در سرور امکان پذیر است. می‌توانید تعداد عناصر (روش‌های Find () و Quantity ()) را هم در کلاینت و هم در سرور جستجو کنید و دریافت کنید.

به عنوان مثالی از کار با دستورات فرم، اجازه دهید یک دستور ChangeHistory جدید با عنوان "Change History ..." ایجاد کنیم که کنترل کننده را فراخوانی می کند. تاریخچه نمایش() . ایجاد زمانی انجام می شود که فرم باز شود.

&روی سرور
روش OnCreateOnServer (شکست، پردازش استاندارد)
تیم = دستورات اضافه کردن( "تاریخچه تغییرات");
تیم . عمل = ;
تیم . عنوان = "تاریخچه تغییرات...";
پایان رویه
&AtClient
روش Connected_DisplayHistory(فرمان)
// اعمال فرمان
پایان رویه

کنترل کننده فرمان باید در فرم قرار داشته باشد و دارای دستورالعمل کامپایل &AtClient باشد.

تغییر جزئیات فرم

خواندن ترکیب صفات فرم توسط تابع انجام می شود دریافت جزئیات(< Путь >) که آرایه ای از نوع FormAttributes را برمی گرداند. پارامتر تابع مسیر صفت والد (به عنوان رشته) را مشخص می کند. اگر پارامتر حذف شود یا یک رشته خالی مشخص شود، اعتبار سطح بالا بازگردانده می شود.

تغییر جزئیات توسط روش انجام می شود EditRequisites(<جزئیات اضافه شده>, <جزئیات قابل جابجایی>) هدف - شی فرم مدیریت شده. گزینه ها جزئیات اضافه شدهو جزئیات قابل جابجاییآرایه هایی با عناصری از نوع Form Requisite ارسال می شوند.

توجه!

فرآیند تغییر ترکیب جزئیات کاملاً منابع فشرده است. در واقع فرم در حال بازسازی است. در این راستا کار با جزئیات فرم به صورت دسته ای انجام می شود.

بیایید یک ویژگی فرم جدید به نام Buyer ایجاد کنیم:

AddedAttributes = آرایه جدید.
جزئیات اضافه شده افزودن (ویژگی فرم جدید("خریدار"، New TypeDescription ("DirectoryReference.Counterparties")، "Client");

// تغییرات در ترکیب صفات
);

تغییر عناصر فرم

برای مدیریت ترکیب عناصر یک شی فرم مدیریت شدهمجموعه داشته باشد عناصر. این مجموعه چندین روش دارد:

درج کنید (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

اضافه کردن (< Имя>, < ТипЭлемента>, < Родитель >)

تعداد ()

پیدا کردن (< Имя >)

حرکت(< Элемент>, < Родитель>, < МестоРасположения >)

حذف (< Элемент >)

مجموعه Elements هم روی کلاینت و هم روی سرور در دسترس است. اصلاح مجموعه (روش ها را درج کنید () ، افزودن () ، انتقال () و حذف ()) فقط در سرور موجود هستند. می‌توانید تعداد عناصر (روش‌های Find () و Quantity ()) را هم در کلاینت و هم در سرور جستجو کنید و دریافت کنید. عناصر مجموعه می توانند عبارتند از:

• GroupForm;
• TableForms;
• FormField;
• ButtonForms.

می‌توانید به‌طور برنامه‌نویسی کنترل‌کننده‌های رویداد را برای عناصر تشکیل‌دهنده اختصاص دهید. برای این منظور روش SetAction(< ИмяСобытия>, < Действие >) .

بیایید به برخی از رایج ترین مثال های عملی کار با دستورات، ویژگی ها و عناصر فرم نگاه کنیم.

افزودن یک فرمان و دکمه مربوط به آن:

// یک تیم ایجاد کنید
تیم = دستورات اضافه کردن( "تاریخچه تغییرات");
تیم . عمل = "Connected_DisplayHistory"; // فرم باید حاوی رویه ای با نام مشخص شده باشد
تیم . سرتیتر = "تاریخچه تغییرات...";
// یک دکمه ایجاد کنید و آن را با یک دستور مرتبط کنید
عنصر = اقلام اضافه کردن( "تاریخچه تغییرات", Type("FormButton" ));
Element.CommandName = "تاریخچه تغییرات";

افزودن یک ویژگی و فیلد ورودی مرتبط با آن:

// شرح جزئیات اضافه شده
AddedAttributes = آرایه جدید.
جزئیات اضافه شده اضافه کردن(ویژگی فرم جدید («خریدار»، شرح نوع جدید ( "پیوند مرجع. طرف مقابل")، "مشتری" ))؛
// تغییر ترکیب صفات
EditAttributes(AddedAttributes);
// ایجاد یک فیلد ورودی و پیوند دادن به یک ویژگی
عنصر = اقلام Add("Customer" , Type("FormField" ));
عنصر . View = ViewFormFields. فیلد ورودی؛
عنصر . PathToData= "خریدار" ;

تخصیص یک کنترل کننده رویداد به یک عنصر فرم:

ItemBuyer. SetAction("وقتی تغییر می کند"، "Plug-in_BuyerOnChange");

&AtClient
روش Plugin_BuyerOnChange(عنصر)
// اقدامات رویداد
پایان رویه

توجه!

رویه هایی که به عنوان کنترل کننده رویداد از کد با استفاده از روش نصب می شوند SetAction()، توصیه می شود از پیشوند Connected_ استفاده کنید.

توجه!

می توانید پردازش را با نمونه هایی از جستجوی برنامه ای و تغییر جزئیات، دستورات و عناصر یک فرم مدیریت شده دانلود کنید.

و Data Transfer Object به ساختار کد، فرم مدیریت شده در محیط 1C 8.2.

معرفی

بیایید با توضیح کوتاهی از مفهوم "فرم مدیریت شده" و مفاهیم مرتبط با پلت فرم 1C شروع کنیم. کارشناسان پلتفرم می توانند از این بخش صرف نظر کنند.

در سال 2008، نسخه جدیدی از پلت فرم 1C: Enterprise 8.2 در دسترس قرار گرفت (از این پس به عنوان برنامه مدیریت شده نامیده می شود)، که به طور کامل کل لایه کار با رابط را تغییر می دهد. این شامل رابط فرمان، فرم ها و سیستم پنجره است. این نه تنها مدل توسعه رابط کاربری را در پیکربندی تغییر می دهد، بلکه یک معماری جدید برای جداسازی عملکرد بین برنامه مشتری و سرور پیشنهاد می کند.
یک برنامه مدیریت شده از انواع مشتریان زیر پشتیبانی می کند:

• Thick Client (حالت راه اندازی عادی و مدیریت شده)
• تین کلاینت
• مشتری وب

برنامه مدیریت شده از فرم های ساخته شده بر اساس فناوری جدید استفاده می کند. آنها نامیده می شوند فرم های مدیریت شده. برای سهولت انتقال، فرم‌های قدیمی‌تر (به اصطلاح فرم‌های معمولی) نیز پشتیبانی می‌شوند، اما عملکرد آنها توسعه‌یافته نیست و فقط در حالت راه‌اندازی مشتری غنی در دسترس هستند.
تفاوت های اصلی فرم های مدیریت شده برای توسعه دهنده:

• توضیحی، نه "توسط پیکسل" از ساختار. هنگام نمایش فرم، قرار دادن خاص عناصر به طور خودکار توسط سیستم انجام می شود.
• تمام عملکردهای فرم در فرم توضیح داده شده است جزئیاتو دستورات. جزئیات داده هایی هستند که فرم با آنها کار می کند و دستورات اقدامات انجام شده هستند.
• فرم هم روی سرور و هم روی کلاینت اجرا می شود.
• در زمینه مشتری، تقریباً همه انواع برنامه ها در دسترس نیستند و بر این اساس تغییر داده ها در پایگاه اطلاعات غیرممکن است.
• برای هر متد یا متغیر فرم باید مشخص شود دستورالعمل تدوین A که محل اجرا (کلاینت یا سرور) و دسترسی به زمینه فرم را مشخص می کند.

در اینجا دستورالعمل هایی برای کامپایل روش های فرم آمده است:

• &AtClient
• &روی سرور
• &OnServerWithoutContext
• &در مشتری در سرور بدون متن

بیایید موارد فوق را نشان دهیم. اسکرین شات نمونه ای از فرم مدیریت شده و ماژول آن را در حالت توسعه نشان می دهد. توضیحات اعلامی، لوازم جانبی، دستورالعمل های تدوین و غیره را بیابید.

تمام بحث های بعدی در مورد سمت راست تصویر، در مورد چگونگی ساختار کد ماژول و اصولی است که به شما اجازه می دهد تا تعامل موثر مشتری و سرور را پیاده سازی کنید.

بیایید مشکل را تعریف کنیم

چندین سال از استفاده فعالانه از نسخه جدید پلت فرم 1C می گذرد و بسیاری از راه حل ها (پیکربندی ها) هم توسط 1C و هم شرکای متعدد آن منتشر شده است.
آیا توسعه دهندگان درک مشترکی از اصول تعامل مشتری-سرور هنگام ایجاد فرم ها در این مدت ایجاد کرده اند و آیا رویکرد اجرای ماژول های برنامه در واقعیت های معماری جدید تغییر کرده است؟

ساختار کد (ماژول فرم) را به چندین شکل از همان پیکربندی معمولی در نظر بگیرید و سعی کنید الگوها را پیدا کنید.
در زیر ساختار، منظور ما بخش‌های کد است (اغلب اینها بلوک‌های نظر هستند) که توسط توسعه‌دهنده برای گروه‌بندی روش‌ها و دستورالعمل‌ها برای کامپایل این روش‌ها انتخاب شده‌اند.
مثال 1:
روش بخش کنترل کننده رویداد - روی روش کلاینت - روش روی سرور - روی مشتری بخش رویه ها و توابع سرویس عملکردهای کمکی کنترل ورودی
مثال 2:
رویه‌ها و عملکردهای خدمات اسناد پرداخت ارزش‌ها گردانندگان رویداد
مثال 3:
رویه‌های سرویس روی سرور رویه‌های سرویس روی سرویس گیرنده رویه‌های سرویس در سرور بدون زمینه کنترل‌کننده‌های رویداد سرصفحه کنترل‌کننده‌های رویداد فرمان
مثال 4:
رویه‌های همه‌منظوره گردانندگان رویداد فرم رویه‌های زیرسیستم «اطلاعات تماس»
در واقع، ساختار کد از دست رفته است، یا به زبان ساده، شبیه به آنچه در فرم های 8.1 بود:

• کلمات غیر آموزنده "عمومی، خدماتی، کمکی."
• ترسو تلاش می کند تا روش های کلاینت و سرور را از هم جدا کند.
• اغلب روش ها با عناصر رابط گروه بندی می شوند "کار با محصولات بخش جدولی، اطلاعات تماس".
• ترتیب خودسرانه روش ها و گروه های کد. به عنوان مثال، Event Handlers ممکن است در یک شکل در بالا، در شکل دیگر در پایین، به هیچ وجه در شکل سوم برجسته نشده باشند و غیره.
• و فراموش نکنیم که همه اینها در یک پیکربندی است.
• بله، تنظیماتی وجود دارد که در آنها کلمات "عمومی، خدمات، کمکی" همیشه در یک مکان قرار دارند، اما ...

چرا به ساختار کد نیاز دارید؟

• ساده سازی تعمیر و نگهداری
• یادگیری را ساده کنید.
• اصلاح اصول کلی/مهم/موفق.
• ... گزینه شما

چرا استاندارد توسعه موجود از 1C کمکی نمی کند؟

بیایید به اصول منتشر شده بر روی دیسک های ITS و در "راهنماهای توسعه دهنده ..." مختلف که هنگام نوشتن یک فرم مدیریت شده توصیه می شود نگاه کنیم.

• تعداد تماس های سرور را به حداقل برسانید.
• حداکثر محاسبات روی سرور
• تماس‌های سرور غیر متنی سریع‌تر از تماس‌های متنی هستند.
• برنامه ای با در نظر گرفتن تعامل مشتری و سرور.
• و غیره

اینها شعارهایی است که کاملا درست است، اما چگونه می توان آنها را محقق کرد؟ چگونه تعداد تماس ها را به حداقل برسانیم، برنامه نویسی در حالت سرویس گیرنده-سرور به چه معناست؟

الگوهای طراحی یا خرد نسلی

تعامل مشتری و سرور برای چندین دهه در فناوری های مختلف نرم افزاری مورد استفاده قرار گرفته است. پاسخ به سوالات مطرح شده در بخش قبل از دیرباز شناخته شده است و در دو اصل اساسی خلاصه شده است.

• نما از راه دور(از این پس رابط دسترسی از راه دور)
• شی انتقال داده(از این پس هدف انتقال داده نامیده می شود)

سخنی به مارتین فاولر، شرح او از این اصول:

• … هر شی به طور بالقوه برای دسترسی از راه دور باید داشته باشد رابط با دانه بندی کم، که تعداد تماس های مورد نیاز برای انجام یک روش خاص را به حداقل می رساند. به جای درخواست فاکتور و تمامی امتیازات آن به صورت جداگانه، لازم است تمامی نکات فاکتور را در یک تماس خوانده و به روز کنید. این روی کل ساختار شی تأثیر می گذارد ... به یاد داشته باشید: رابط دسترسی از راه دور شامل منطق دامنه نیست.
• ... اگر مادری دلسوز بودم، حتما به فرزندم می گفتم: هرگز اشیاء انتقال داده را ننویس! در بیشتر موارد، اشیاء انتقال داده چیزی بیش از این نیستند مجموعه مزارع متورم... ارزش این هیولای نفرت انگیز تنها در امکان نهفته است چندین مورد از اطلاعات را در یک تماس از طریق شبکه منتقل می کند- تکنیکی که برای سیستم های توزیع شده اهمیت زیادی دارد.

نمونه هایی از قالب ها در پلتفرم 1C

API در دسترس یک توسعه دهنده هنگام توسعه یک فرم مدیریت شده شامل نمونه های زیادی از این اصول است.
به عنوان مثال، روش OpenForm()، یک رابط معمولی "درشت".
OpenParameters = ساختار جدید ("Parameter1, Parameter2, Parameter3", Value1, Value2, Value3); Form = OpenForm (FormName, OpenParameters);
مقایسه با سبک v8.1.
Form = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

در زمینه یک فرم مدیریت شده، مجموعه ای از "اشیاء انتقال داده". قابل تشخیص است سیستمیکو توسط توسعه دهنده تعریف شده است.
آنهایی که سیستم یک شی برنامه کاربردی را در کلاینت به شکل یک یا چند عنصر داده فرم مدل می کنند. شما نمی توانید آنها را خارج از اتصال به جزئیات فرم ایجاد کنید.

• DataFormsStructure
• DataFormsCollection
• DataFormStructureCollection
• DataFormsTree

تبدیل اشیاء سیستم انتقال داده به انواع برنامه ها و بالعکس با روش های زیر انجام می شود:

• ValueVDataForm()
• FormDataToValue()
• CopyFormData()
• ValueVFormProps()
• FormAttributeToValue()

اغلب هنگام تطبیق راه حل موجود، از تبدیل صریح استفاده می شود. متدها ممکن است انتظار پارامترهای ورودی (ویژگی) مانند ValueTable به جای FormDataCollection را داشته باشند، یا متد در زمینه یک شی برنامه تعریف شده است و برای فراخوانی مستقیم از فرم در دسترس نیست.
مثال 1C v8.1:
// در کلاینت در زمینه فرم FillUsersCache(DepartmentReference)
مثال 1C v8.2:
// در سرور در زمینه فرم ProcessingObject = FormAttributeToValue("Object"); ProcessingObject.FillCacheUsers(DepartmentReference); ValueVFormAttribute(ProcessingObject، "Object");

اشیاء انتقال داده که ساختار آنها توسط توسعه دهنده تعریف می شود، زیرمجموعه کوچکی از انواع موجود در سرویس گیرنده و سرور هستند. اغلب، به عنوان پارامترها و نتایج روش های یک رابط "درشت"، موارد زیر استفاده می شود:

• انواع اولیه (رشته، عدد، بولی)
• ساختار
• مکاتبه
• آرایه
• پیوندها به اشیاء برنامه (شناسه منحصر به فرد و نمایش متن)

مثال: متد لیستی از دستورات را برای تغییر وضعیت می پذیرد و شرح خطاها را به مشتری برمی گرداند.
&OnServerWithoutContext تابع ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [order][شرح خطا] برای هر سفارش از Orders Loop StartTransaction(); تلاش DocOb = Order.GetObject(); …. سایر اقدامات، احتمالاً نه تنها با دستور... Exception CancelTransaction(); Errors.Insert(Order, DescriptionError()); پایان تلاش؛ چرخه پایان خطای بازگشت؛ EndFunction // ServerChangeOrderStatus()

ساختار کد

اهداف اصلی که ماژول فرم مدیریت شده باید منعکس کند و به راه حل نزدیک شود.

• جداسازی کد کلاینت و سرور را پاک کنید.فراموش نکنیم که در زمان اجرا این دو فرآیند متقابل هستند که در هر یک از آنها عملکردهای موجود به طور قابل توجهی متفاوت است.
• یک انتخاب واضح از رابط دسترسی از راه دور، کدام روش های سرور را می توان از مشتری فراخوانی کرد و کدام را نمی توان؟ نام روش های رابط راه دور با پیشوند "سرور" شروع می شود. این به شما امکان می دهد بلافاصله انتقال کنترل به سرور را هنگام خواندن کد مشاهده کنید و استفاده از نکات متنی را ساده می کند. توجه داشته باشید که توصیه رسمی (ITS) نامگذاری روش‌هایی را با پسوندها، مانند ChangeOrderStatusOnServer () پیشنهاد می‌کند. با این حال، برای تکرار، همه روش های سرور را نمی توان از مشتری فراخوانی کرد، بنابراین دسترسی منطقی مهم تر از مکان کامپایل است. بنابراین، با پیشوند "Server" ما فقط متدهای در دسترس مشتری را علامت گذاری می کنیم، متد نمونه به نام ServerChangeOrderStatus() است.
• خوانایییک موضوع سلیقه ای، زمانی که ماژول با مراحل ایجاد فرم در سرور و روش های دسترسی از راه دور شروع می شود، سفارش را می پذیریم.
• قابلیت نگهداری.محل افزودن کد جدید باید به وضوح مشخص باشد. نکته مهم این است که روش‌های خرد که به‌طور خودکار توسط پیکربندی‌کننده ایجاد می‌شوند به انتهای ماژول اضافه می‌شوند. از آنجایی که کنترل‌کننده‌های رویداد عنصر فرم اغلب به‌طور خودکار ایجاد می‌شوند، بلوک مربوطه در آخر قرار می‌گیرد تا هر کنترل‌کننده به مکان دیگری در ماژول کشیده نشود.

در زیر ساختار اصلی ماژول است که اهداف ذکر شده را پیاده سازی می کند.

• گزینه گرافیکی - به وضوح جریان اصلی اجرا را نشان می دهد.
• گزینه متن نمونه ای از طراحی قالب برای درج سریع ساختار در یک ماژول فرم جدید است.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" تاریخ = ""/> // <Описание> // // ///////////////////////////////////////////////////////////////////////// ///////////////////////////// // متغیرهای ماژول //////////////// ///////////////////////////////////////////////////////////////////////// ////////////// // روی سرور //******** رویدادهای روی سرور ******* &روی سرور رویه ایجاد در سرور (شکست، StandardProcessing) //درج محتویات کنترل کننده EndProcedure //******** رابط دسترسی از راه دور ******* //******** منطق تجاری روی سرور ****** * //////////////////////////////////////////////////////// ////////// //////////////////// // روش‌های کلی کلاینت و سرور //////////// ////////////////////////////////////////////////////////////////////////// //////////// //////// // در مورد مشتری //******** منطق کسب و کار بر مشتری ******* //** ***** دستورات ******* //******** رویدادهای روی مشتری ****** ////////////////// ///////////////////////////////////////////////////////////////////// //////////// / / اپراتورهای اصلی برنامه

سوالات مرتبط

در خاتمه، ما چند حوزه را بیان می کنیم که در برنامه نویسی تعامل مشتری و سرور مفید است.

• گزینه هایی برای پیاده سازی رابط دسترسی از راه دور. ناهمزمانی، دانه بندی...
• ذخیره سازی 1C یک تصمیم معماری ناخوشایند گرفت و حافظه پنهان را فقط در سطح روش های فراخوانی ماژول های رایج معرفی کرد و گزینه های کنترل را ارائه نکرد (زمان به روز، تنظیم مجدد در صورت تقاضا).
• تماس های ضمنی سرور. ویژگی های فناوری را فراموش نکنید، بسیاری از عملیات "بی ضرر" روی مشتری، پلت فرم را برای دسترسی به سرور تحریک می کند.

تشکیل می دهددر 1C: Enterprise برای نمایش و ویرایش اطلاعات موجود در پایگاه داده طراحی شده اند. فرم ها می توانند به اشیاء پیکربندی خاصی تعلق داشته باشند یا جدا از آنها وجود داشته باشند و توسط کل راه حل برنامه به عنوان یک کل استفاده شوند.

مثلا یک راهنما نامگذاریممکن است چندین فرم داشته باشد که برای اهداف خاص مورد استفاده قرار می گیرد - ویرایش یک عنصر دایرکتوری، نمایش یک لیست و غیره:

همراه با این، ممکن است اشکال کلی وجود داشته باشد که به اشیاء پیکربندی خاص تعلق ندارند - فرم های عمومی.

فرم های پایه

هر شیء پیکربندی را می توان برای انجام اقدامات استاندارد خاصی استفاده کرد. به عنوان مثال، برای هر دایرکتوری، ممکن است لازم باشد فهرستی از عناصر آن را نمایش دهید، عناصر جداگانه دایرکتوری را نمایش دهید، گروهی از دایرکتوری را نمایش دهید، عناصر و گروه هایی از عناصر را از فهرست انتخاب کنید. برای هر سند، لیست چنین اقداماتی بسیار کوچکتر خواهد بود: مشاهده لیست اسناد، انتخاب از لیست اسناد و مشاهده یک سند واحد.

برای اطمینان از عملکرد چنین اقدامات استاندارد با داده های اشیاء راه حل اعمال شده، برای هر یک از آنها مجموعه ای از اشکال اساسی وجود دارد که هنگام انجام اقدامات مربوطه استفاده می شود. اصلی را می توان به هر یک از فرم های تابع این شی اختصاص داد. به عنوان مثال، دایرکتوری نامگذاریاشکال اصلی زیر ممکن است وجود داشته باشد:

و سند دریافت کالا و خدماتترکیب فرم های اصلی متفاوت خواهد بود:

بنابراین، اگر کاربر بخواهد فهرست دایرکتوری را ببیند نامگذارییا لیستی از اسناد دریافت کالا و خدمات، سیستم فرم مربوطه را که به عنوان فرم لیست برای این اشیاء اختصاص داده شده است را باز می کند.

فرم های تولید شده به صورت خودکار

یکی از ویژگی های مهم سیستم 1C: Enterprise 8 مکانیسم فرم های تولید خودکار است. این مکانیسم توسعه دهنده را از ایجاد تمام اشکال ممکن برای هر یک از اشیاء پیکربندی آزاد می کند. کافی است توسعه دهنده یک شی پیکربندی جدید اضافه کند و خود سیستم در لحظات مناسب کار کاربر فرم های لازم را برای نمایش اطلاعات موجود در این شی ایجاد می کند.

بنابراین، توسعه‌دهنده تنها در صورتی نیاز به ایجاد اشکال خاص خود از اشیاء راه‌حل کاربردی دارد که باید تفاوت‌هایی (طراحی متفاوت یا رفتار خاص) با فرم‌های تولید شده به‌طور خودکار توسط سیستم داشته باشند.

پیوند دادن فرم به داده ها

این واقعیت که فرم به یک یا آن شی پیکربندی تعلق دارد، ترکیب داده هایی را که در فرم نمایش داده می شود تعیین نمی کند. اینکه فرم به عنوان مثال به یک دایرکتوری تعلق دارد نامگذاری، به شما امکان می دهد آن را به یکی از فرم های اصلی این دایرکتوری اختصاص دهید، اما به هیچ وجه تعیین نمی کند که این فرم چه نوع داده ای را نشان می دهد و رفتار آن چگونه خواهد بود.

برای پیوند فرم با داده ها از ویژگی های فرم استفاده می شود که نشان دهنده لیست داده های نمایش داده شده توسط فرم است. همه فرم ها به خودی خود رفتار یکسانی دارند، صرف نظر از اینکه چه داده هایی را نمایش می دهند. با این حال، یکی از ویژگی‌های فرم را می‌توان به‌عنوان ویژگی فرم اصلی تنظیم کرد (با پررنگ مشخص شده است)، در این صورت بسته به نوع ویژگی فرم اولیه، رفتار استاندارد فرم و ویژگی‌های آن تکمیل می‌شود:

به عنوان مثال، اگر یک سند به عنوان ویژگی اصلی فرم اختصاص داده شود دریافت کالا و خدمات، پس از بسته شدن فرم، سیستم درخواست تایید ثبت و ارسال این سند را می کند. اگر مثلاً یک کتاب مرجع به عنوان ویژگی اصلی فرم اختصاص داده شود نامگذاری، پس هنگام بستن فرم چنین درخواست تأییدی وجود نخواهد داشت.

ساختار فرم

ویژگی اصلی فرم ها این است که توسط توسعه دهنده با جزئیات ترسیم نشده اند، "با پیکسل". یک فرم در یک پیکربندی یک توصیف منطقی از ترکیب یک فرم است. و قرار دادن خاص عناصر توسط سیستم به صورت خودکار هنگام نمایش فرم انجام می شود.

بخشی از فرم که نمایش داده می شود (برای کاربر قابل مشاهده است) به عنوان یک درخت حاوی عناصر فرم توصیف می شود.

عناصر می توانند فیلدهای ورودی، چک باکس ها، دکمه های رادیویی، دکمه ها و غیره باشند. علاوه بر این، یک عنصر می تواند گروهی از عناصر دیگر باشد. یک گروه را می توان به عنوان یک پانل با یک قاب، یک پانل با صفحات (برگه ها)، یک صفحه، یک پانل فرمان نشان داد. علاوه بر این، یک عنصر می تواند جدولی باشد که شامل عناصر (ستون) نیز باشد. ساختار عنصر توضیح می دهد که فرم چگونه به نظر می رسد.

تمام عملکردهای فرم در قالب جزئیات و دستورات توضیح داده شده است. جزئیات داده هایی هستند که فرم با آنها کار می کند و دستورات اقدامات انجام شده هستند. بنابراین، توسعه دهنده در ویرایشگر فرم باید جزئیات و دستورات لازم را در فرم درج کند، عناصر فرم را ایجاد کند که آنها را نمایش می دهد و در صورت لزوم، عناصر را در گروه ها مرتب کند.

بر اساس این توصیف منطقی، سیستم به طور خودکار ظاهر فرم را برای نمایش به کاربر ایجاد می کند. در همان زمان، سیستم ویژگی های مختلف داده های نمایش داده شده (به عنوان مثال، نوع) را در نظر می گیرد تا عناصر فرم را تا حد امکان راحت برای کاربر مرتب کند.

توسعه دهنده می تواند بر ترتیب عناصر با تنظیمات مختلف تأثیر بگذارد. می تواند ترتیب عناصر را تعیین کند، عرض و ارتفاع مورد نظر را نشان دهد. با این حال، این فقط برخی اطلاعات اضافی برای کمک به سیستم در نمایش فرم است.

در فرم‌ها، توسعه‌دهنده می‌تواند نه تنها از دستورات خود فرم، بلکه از دستورات سراسری مورد استفاده در رابط فرمان کل پیکربندی استفاده کند. علاوه بر این، امکان ایجاد دستورات قابل پارامترسازی که با در نظر گرفتن داده های خاص فرم فعلی، فرم های دیگر را باز می کند، پیاده سازی شده است. به عنوان مثال، می تواند یک تماس برای گزارش موجودی در انبار باشد که در حال حاضر در فرم فاکتور انتخاب شده است.

همه ما می دانیم که شرکت 1C نسخه های مختلفی از پلتفرم 1C داشت، اکنون در زمان نوشتن این مقاله به یکی از آخرین نسخه ها علاقه مند خواهیم شد، اینها نسخه های 1C 8.2 و 1C 8.3 هستند. اگر مجبور شده‌اید در هر دوی این نسخه‌ها کار کنید، به احتمال زیاد تفاوت هایی را در رابط های این نسخه ها مشاهده کرد، برای کاربران فقط از نظر خارجی تفاوت دارند. در اصل، انتخاب برنامه منظم یا مدیریت شدهبه سیستم می گوید که کدام فرم ها را نمایش دهد تا اجرا شوند، منظم یا کنترل شدهو همچنین اینکه کدام برنامه کاربردی به طور پیش فرض استفاده می شود، ضخیم یا نازک. برای اطلاعات بیشتر در مورد مشتریان، به مقاله "کلینت ضخیم و نازک در 1C چیست و همچنین تفاوت های آنها" مراجعه کنید.

برنامه معمولی 1C (فرم های معمولی، رابط معمولی، نسخه 1C 8.2)

در 1C 8.2، فقط کار امکان پذیر است با فرم های معمولی، در حالت برنامه معمولی. تصویر زیر پایه را در حالت عملکرد "برنامه معمول 1C" (فرم های معمولی) نشان می دهد.

برنامه مدیریت شده 1C (فرم های مدیریت شده، رابط مدیریت شده، نسخه 1C 8.3)

در پلتفرم 1C 8.3، می‌توانیم هم با فرم‌های معمولی (در حالت سازگاری) و هم با فرم‌های مدیریت شده کار کنیم. و فرم های مدیریت شده دارای دو نوع نمایش هستند، استاندارد و تاکسی. نمونه ای از پیکربندی 1C 8.3 با فرم های استاندارد مدیریت شده در زیر نشان داده شده است و پس از آن رابط تاکسی نشان داده شده است.

تفاوت بین یک برنامه معمولی و یک برنامه مدیریت شده 1C چیست؟

همانطور که قبلاً فهمیدیم یک برنامه معمولی و یک برنامه مدیریت شده از جمله انواع راه اندازی یک برنامه 1C هستند. علاوه بر این، بسته به مقدار نوع پرتاب 1C ( برنامه منظم یا مدیریت شده، رابط خاص به طور پیش فرض بارگیری می شود ( فرم های منظم یا مدیریت شده، از این رو مترادف های زیادی برای این مفهوم وجود دارد. مایلیم توجه داشته باشیم که تفاوت ها در رابط ها بسیار قابل توجه است، رابط مدیریت شده کاملاً دوباره طراحی شده است. در اصل، این همه تفاوت هایی است که کاربران عادی برنامه 1C می بینند. همانطور که برای برنامه نویسان، رابط مدیریت شده نیاز به نوشتن کد اصلاح شده دارد، زیرا توسعه در حال حاضر در 1C 8.3 در حال انجام است، و نه در 1C 8.2، از این رو تمام عواقب ناشی از آن. کد همچنین باید به مشتری و سرور تقسیم شود، این با استفاده از دستورالعمل های مناسب در پیکربندی نشان داده شده است.

Klyuev V.V.

http://prof1c.kklab.ru

کار با سوئیچ

از شما می خواهم که همه کاربران سرویس سایت را در نظر بگیرید - من مطالب را در قسمت مبتدیان قرار می دهم !!!

8.2 فرم های مدیریت شده

هنگام مطالعه رفتار فرم های مدیریت شده، برنامه نویسان یا توسعه دهندگان رابط با این سوال روبرو می شوند - سوئیچ ها در فرم های مدیریت شده کجا هستند و چگونه آنها را به فرم اضافه می کنند. یک چیز جزئی، اما زمان بسیار ناخوشایندی برای چنین چیزهای کوچکی صرف می شود، اگرچه این زمان می تواند صرف توسعه و بهینه سازی الگوریتم شود تا طراحی فرم.

بنابراین، بیایید یک پیکربندی خالی ایجاد کنیم تا مشکل را درک کنیم، یا هر نوع معمولی را انتخاب کنیم.
به گروه حاوی دایرکتوری ها بروید و برای آزمایش یک دایرکتوری جدید اضافه کنید. می خواهم توجه داشته باشم که پیکربندی باید حالت راه اندازی اصلی - برنامه مدیریت شده را داشته باشد.

بنابراین، بیایید یک دایرکتوری جدید ایجاد کنیم و props "Props1" را با نوع "Boolean" اضافه کنیم.

حالا به تب Forms رفته و یک فرم جدید اضافه کنید.

بنابراین، فرم مدیریت شده ایجاد می شود، اکنون بیایید با فرم کار کنیم و همان جایی که سوئیچ قرار دارد را پیدا کنیم.
در اینجا فرم ما است، و بر روی آن ما قطعات خود را می بینیم، اما به شکل یک چک باکس

پس چه غلطی کردیم؟
بیایید ویژگی های پایه ها را بررسی کنیم تا ببینیم آیا تغییری برای نمای کنترل وجود دارد یا خیر.
و می بینیم که Switch Field اینجا نیست!(کجا اشتباه کردیم؟

ظاهراً ظاهر کنترل روی فرم به نوع داده بستگی دارد، اجازه دهید به خصوصیات فرم یعنی تب جزئیات برگردیم و خصوصیات ویژگی خود - یعنی نوع آن "Boolean" را به نوع "Number" تغییر دهیم.

حالا بیایید به ویژگی های کنترل برگردیم و بررسی کنیم که آیا View کنترل در ویژگی های آن اضافه شده است - - - و urra، نمای آن را می بینیم - فیلد Switch.

حالا به فرم نگاه کنید، چیزی که می بینیم:

ما می بینیم - 3 مقدار پیش فرض، 3 دکمه رادیویی، اما ما به دو مورد از آنها نیاز داریم، دوباره به ویژگی های props بروید و به ویژگی های "تعداد ستون ها" در آنجا نگاه کنید.

برای 2 - مجموعه تعداد ستون - 2.

این می تواند یک برنامه نویس خسته را کمی متوقف کند))، اما اکنون هم او و هم ما آن را می دانیم!

8.2 فرم های رایج

عصبی شدن با سوئیچ ها در اشکال معمول.
چنین لحظاتی وجود دارد، و آنها اتفاق می‌افتند) زمانی که شما باید یک فرم آماده را تغییر دهید، که در آن سوئیچ‌هایی وجود دارد، و باید سوییچ دیگری را به این فرم اضافه کنید. اینجاست که نوعی خسته‌کننده بودن به وجود می‌آید که زمان زیادی را صرف می‌کند و نه برای کد برنامه‌نویسی - بلکه اتلاف وقت برای نمایش این سوئیچ‌ها برای کاربر.

پس بیایید به یک مثال نگاه کنیم. چنین سندی برای تنظیم رسیدها در 1C SCP وجود دارد - قطعاً وجود دارد. زمانی لازم بود سوئیچ هایی به آن اضافه کنیم تا پست های کمی متفاوت برای حسابداری ترسیم شود. مشکل چیست، ضروری به نظر می رسد، پس لازم است، ما آن را انجام خواهیم داد. اما این فرم از قبل دارای 2 دکمه رادیویی است.

این شکلی است که در آن باید سوئیچ های بیشتری را وصل کنیم

در تب پیشرفته، می‌خواهیم دو دکمه رادیویی دیگر قرار دهیم. بنابراین اولین اقدام جسورانه اضافه کردن یک کنترل جدید به مکانی است که باید آن را وارد کنیم.

به نظر می رسد که همه چیز ساده است. ما یک ویژگی جدید با نوع - "Number" ایجاد می کنیم و 2 سوئیچ را وارد می کنیم که یکی از آنها می تواند داده ها را در ویژگی بنویسد و دیگری نمی تواند.

یک کنترل جدید اضافه کنید - سوئیچ، در جدول با تعداد و توضیحات سوئیچ ها، Switch2 را اضافه کنید، Switch1 را به عنوان اولین در گروه تنظیم کنید و ok را فشار دهید. کنترل های ایجاد شده را روی فرم قرار می دهیم. پیکربندی پایگاه داده (F7) را به روز کنید و برای رفع اشکال اجرا کنید.

هنگام اجرا (هنگام ایجاد یک سند جدید در حالت 1C: Enterprise)، می بینیم که هر چقدر هم که سعی کنیم روی Switch2 کلیک کنیم، هیچ اتفاقی نمی افتد. عناصر آنطور که باید کار نمی کنند. در اینجا یک ویژگی وجود دارد.
به پیکربندی بازگردید. مورد را در منوی فرم انتخاب کنید -> تنظیم ترتیب پیمایش ... (مهم است که فرم روی صفحه باز باشد)

برای اینکه سوئیچ های ما کار کنند، باید نظم خودکار را شکسته و با دستور دستی موافقت کنید. و در فرم قرار دهید تا سوئیچ های ما به ترتیب یکی پس از دیگری بروند.

خوب. پیکربندی را به روز کنید و اجرا کنید.
عالی. همه چیز کار کرد.

اختیاری - ویدیو (بدون صدا، بنابراین همه چیز واضح است)