Customizing the form

The form customization process is always about events handling. The Platform “publishes” the most important events making them accessible from the application source code. All published events are listed in the properties palette. It can be, for instance, form's opening or closing events, user pressing visual element events and so on. Developer needs to select the right event and implement the code needed to tune the form behaviour.

In the runtime the Platform automatically traces all events that were handled. After the event happens (for example, user presses the button) the Platform calls the handler that is bound to the event. In other words it executes the procedure you assigned to be the event handler.

To resolve our “default warehouse issue” we need to catch the document form before it was displayed, and then assign “Main” warehouse value to the Warehouse attribute of the doc.

When we create handler, the Platform offers three options:

• Create on client
• Create on client and a procedure on server:
  • no context
  • with context

Before we start implementing the handler we need to be able to tell the difference between those three.

Client/server interaction

1C:Enterprise application architecture implies that there are always 2 independent actors:

• Client:
  • who works with user interface (forms),
  • has no access to infobase (cannot read or edit any infobase data)
  • but can call server procedures,
• and Server:
  • who works with infobase (can read or edit any infobase data),
  • executes clients’ calls
  • and run background jobs.

Our Warehouse attribute has “CatalogRef.Warehouses” type. Reference - is a GUID (global unique identifier) that platform assigns automatically when you create a new object. To get its value we need to read the “Main” warehouse from the infobase. There is no way the 1C client can do that, so it has to ask the server. In other words we are going to need client event handler calling a procedure on the server. With or without context though?

“With context” means that during the server call client will pass the entire form to a server. It might be necessary, for instance, when you fill out the document form with attributes values (which happens on the client side, of course) and want the server to write the document into the infobase. Calling the server procedure with the context you make the entire form accessible to server, so it can directly read form attributes and write them to the infobase.

Call with context obviously takes more network bandwidth to pass the entire form from client to server, so you don’t want to use this kind of calls excessively. In our case all we need is reading a reference value of one catalog element and return it to the client, so the call without context seems to be good enough.

Here is a Video, showing the process of implementing the event handler we need.

This is the resulting code we’ve got:

&AtClient
Procedure OnOpen(Cancel)
	OnOpenAtServer(ThisForm.Object.Warehouse);
EndProcedure
&AtServerNoContext
Procedure OnOpenAtServer(Warehouse)
	// Insert handler contents.
	Warehouse = Catalogs.Warehouses.FindByDescription("Main");
EndProcedure

Few more words about events’ handling. Please note, that event handling involves two independent actions:

• Implementing of the handler procedure
• Subscribing this procedure for specific event

The point is that an event handler procedure and an event subscription are two different things. Implementing the procedure OnOpen() in form’s module does not make this procedure event handler. It will be called by the Platform only when you create a subscription, i.e. select this procedure in the Properties palette as a handler for this event.

So, this source code written in the form’s module

&AtClient
Procedure OnOpen(Cancel)
	OnOpenAtServer();
EndProcedure

will not be executed by the Platform when it opens a form unless you subscribe this procedure to the OnOpen event:

It also means that an event handler does not have to have any specific name. It’s just a procedure that can be named however you want. But it has to have an exact number of parameters specific for this event handler.

So, if you need an event handler for the form’s OnOpen event (which requires one parameter) the following procedures will do:

Procedure OnOpen(Cancel)
Procedure HandleOnOpenEvent(Skip)
Procedure kHKjhUyJHfg(mJGHkjL)

Reading and writing data using object technique

In this example, we read the catalog element using the object technique. Using it you can either read infobase objects into a 1C server memory or write them from 1C server memory to the infobase.

Let’s take a closer look to objects’ lifecycle in 1C:Enterprise:

Using this technique, you always manipulate with a single object. It means you can perform mass data operations only with a cycle. Note that mass reading with a cycle could be a bad idea because of “round-trip” effect that can drastically compromise your system performance. So if you need to read more than one object you want to use 1C queries (see below).

Another noteworthy feature of the object technique is that you always manipulate an object as a whole. In other words you cannot read a few attributes you need, you always read an entire objects from infobase and load it to the memory. In our case we needed the reference only, but we had to read the entire warehouse catalog object, made excessive readings and allocated more memory than we actually needed.

Is there any way to avoid this?

Lesson 1-3| Course description| Lesson 1-5