Les principaux objets 1C utilisés lors de l'utilisation de formulaires gérés sont répertoriés ci-dessous. De brefs exemples de code sont donnés qui démontrent l'utilisation traditionnelle de ces objets lors de l'écriture de configurations 1C.

Ce formulaire

Utilisé dans le module de formulaire, dans les procédures&AtClient et &AtServer .

Vous permet d'accéder à la fois aux éléments et aux attributs du formulaire.

L'élément de formulaire est accessible via un objetÉléments et ressemble à ceci :

ThisForm.Items.VersionNumber.Header = "v."+ProgramVersion ;

L'accès à l'attribut qui existe sur le formulaire est le suivant :

ThisForm.AnnouncementText="Bonjour, camarades !" ;

Accès simplifié aux éléments et attributs de formulaire

Dans le module de formulaire, en principe, vous ne pouvez pas spécifier le mot-clé Ce formulaire . Vous pouvez accéder aux éléments et attributs du formulaire de manière simplifiée :

// Elément de formulaire

Elements.VersionNumber.Title = "v."+ProgramVersion ;

// Accessoires de formulaire

AnnouncementText="Bonjour, camarades !" ;

Caractéristiques d'obtention des détails du formulaire (important !)

Si le prop de formulaire est de type simple - Chaîne , Nombre , Date ... alors vous pouvez obtenir (définir) la valeur de l'attribut simplement par son nom :

Texte=NomProduit ; // Le nom du produit est un attribut de formulaire

Cependant, de cette manière, il est impossible d'obtenir les détails du type "complexe" -Tableau des valeurs, Arbre de valeurs . Lorsque vous essayez d'obtenir un attribut avec ce type par son nom, un objet du type sera renvoyéDataFormsCollection.

Pour obtenir la valeur d'un attribut de type "complexe", il faut utiliser la fonctionFormAttributeToValue():

CurrentTable=FormAttributeToValue("SelectedConstructionObjects");

Pour définir la valeur d'un attribut "complexe", vous pouvez utiliser la fonctionValeurVPropsForm(<Значение>, <ИмяРеквизита>) , les deux paramètres sont obligatoires.

Les fonctions FormAttributeToValue() Et ValueVFormProps()disponible uniquement sur le serveur.

Un objet

À proprement parler, cela mot-clé dans le formulaire ne l'est pas. Simplement, lorsqu'un formulaire est créé, par exemple, un élément de formulaire, 1C crée automatiquement un attribut sur le formulaire avec le nom Un objet . Grâce à cet attribut, les propriétés de l'objet courant, qui est en cours d'édition sur le formulaire, sont disponibles.

ou, une notation plus complète :

CetObjet

Contient l'objet lui-même. Conçu pour recevoir un objet dans un module d'objet ou un module de formulaire.

Utilisation : lecture seule.

Disponibilité : Serveur, client lourd, connexion externe.

À l'époque du gros client, il était facile d'appeler une procédure de module objet à partir d'un module de formulaire. Il suffisait de définir la procédure du module comme exportable et de l'appeler dans le formulaire module.


Les temps changent, la plateforme 1C s'optimise et s'améliore, le client lourd est oublié, offrez à chacun un client léger ou web. Les développeurs commencent à traduire les formulaires ordinaires en formulaires gérés, mais tout n'est pas si simple, certaines difficultés apparaissent en raison de la division de l'exécution du code du programme en deux contextes : serveur et client. Par conséquent, l'exemple de code ci-dessus ne fonctionnera pas dans un client léger.

Nouveaux types de données

De plus, à cause des formulaires gérés, de nouveaux types de données sont apparus. Il existe un formulaire :
Nous nous souvenons des types d'attributs et voyons quels types sont en débogage pour ces attributs :

Nouveaux types de données de formulaire

Nous concluons que pour afficher les données de l'objet lui-même, le type est utilisé DataFormsStructureDataFormsStructure, pour afficher l'arborescence des valeurs - DataFormsTree, pour la partie tabulaire - DataFormsCollection etc. Autrement dit, dans le module de formulaire sur le client, nous ne travaillons pas avec l'objet lui-même, mais avec sa représentation ! Par conséquent, les méthodes disponibles, par exemple, pour la partie tabulaire dans le module d'objet PAS DISPONIBLE dans le module de formulaire.

Combattre de nouveaux types

Les développeurs de la plate-forme 1C ont fourni deux fonctions :

1. PropsFormVValue- convertit l'attribut de formulaire spécifié en un objet de type application.
2. FormulaireDonnéesVersValeur- convertit les données du formulaire en un objet de type application.

L'appel de ces fonctions n'est disponible que sur le serveur. Revenons à notre tâche et écrivons le code du client léger dans le module de formulaire dans l'événement SurCréerSurServeur, qui appellera la fonction depuis le module de l'objet :
&Sur le serveur


AskObject1 = FormAttributeToValue("Objet");
AskObject1.OutputMessage(Object.Attribute1);




FinProcédure

Cela fonctionne à la fois avec l'aide d'une fonction et avec l'aide d'un autre O_o. Écrivons le code de conversion DataFormsTree dans un objet de type application :
&Sur le serveur
Procédure sur CreationOnServer (échec, traitement standard)

ValueTree1 = FormAttributeToValue("Attribute1");
ValueTree2 = FormDataToValue(ThisForm.Attribute1, Type("ValueTree"));

FinProcédure

ValueTree1 et ValueTree2 ont le même type - ValueTree. Quelle est donc la différence entre ces fonctions ???

FormulaireDonnéesVersValeur - fonction mondial contexte. Convertit le type d'objet pris en charge par le formulaire en type d'objet de base de données : DataFormsStructure --> DirectoryObject.Directory1.

PropsFormVValue - fonction du module de formulaire, c'est-à-dire qu'il est appelé sur le serveur dans le contexte du formulaire (&AtServer). Si vous essayez d'appeler cette fonction en dehors du contexte du formulaire, la plateforme lèvera une exception :
&Surserveursanscontexte
ProcedureTypeConversion()

// Ce code est invalide, le contexte du formulaire n'est pas disponible, il y aura une erreur !
AskObject2 = FormDataToValue(Object, Type("CatalogObject.Catalog1"));
AskObject2.OutputMessage(Object.Attribute1);

FinProcédure

C'est toutes les différences.

Le traitement affiche tous les détails de l'objet sélectionné, vous permet de les modifier, ainsi que de comparer deux objets du même type. Prend en charge toutes les configurations, la norme est installée automatiquement.

Version actuelle : pour les formulaires réguliers 1.09, pour les formulaires gérés 1.12.

Traitement du téléchargement (pour 1C 8.2, 1C 8.3 (formulaires réguliers), fichier epf, 47 Ko)

Télécharger le traitement (pour 1C 8.2, 1C 8.3 (formulaires gérés), fichier epf, 22 Ko)

Dernière version pour 1C 8.1 : 1.05

Traitement du téléchargement (pour 1C 8.1, fichier epf, 48 Ko)

Que faire si le traitement ne s'ouvre pas

Le traitement est très utile, par exemple, dans de tels cas :

besoin de comprendre une base inconnue

la version de configuration a été mise à jour et un nouveau champ a été ajouté au document (masqué, mais le formulaire ne l'a pas). En même temps, pour les nouveaux documents, il est défini lors de leur création, mais naturellement ils ont oublié les anciens. Ce qui pour l'utilisateur se traduit par le fait que deux documents totalement identiques donnent des affichages différents 🙁

c'est juste que le contenu du champ ne rentre pas dans la place qui lui est allouée sur le formulaire, mais il faut le voir en entier (les sections de tableau en souffrent particulièrement - les développeurs aiment beaucoup limiter la largeur des colonnes et, en ajout, l'empêchant d'être modifié)

vous devez vous rendre sur les informations associées (par exemple, ouvrir le CCD spécifié sur la facture), mais ils ont oublié de rendre ce champ disponible (c'est-à-dire ni le bouton avec des points ni la loupe ni F4) (et il arrive aussi que à la place du champ de saisie ils font un champ de sélection, une inscription ou un champ généralement absent sur le formulaire 🙁)

comparer deux objets du même type

Les traits distinctifs sont

la possibilité de se connecter à des configurations standard comme formulaire imprimé(c'est-à-dire en mode utilisateur pur, aucun configurateur nécessaire)

la possibilité d'enregistrer un objet en mode "échange de données - téléchargement" - c'est-à-dire "tel quel"

Installation (interface normale)

Ouvrez le traitement, suivez les instructions à l'écran. (C'est-à-dire, cliquez sur le bouton "Installer" dans le coin supérieur droit et confirmez l'installation dans la fenêtre suivante.

Installation (interface "gérée")

Attention : Cette option d'installation ne fonctionne que dans les configurations 1C typiques.

1. Allez dans la section "Administration" et là - " Rapports supplémentaires et le traitement."

2. Cliquez sur le bouton "Ajouter" et sélectionnez le fichier dannye-objecta-upr.epf

3. Dans la fenêtre des paramètres de traitement, vérifiez que :

Publication : Utilisé

Les cases sont cochées : utiliser pour le formulaire de liste, utiliser les objets pour le formulaire

4. Confirmez l'installation en cliquant sur OK

Utilisation du traitement

A partir de la fiche document, élément de référence. ou formulaire de liste

Interface normale - cliquez sur le bouton "Imprimer ..."

Interface "Gérée" - cliquez sur le bouton de remplissage

Sélectionnez "Données d'objet" dans le menu - le formulaire de traitement s'ouvrira

Pour afficher les détails (par exemple, le document contient l'attribut "Accord", il n'est pas disponible pour modification et vous devez ouvrir la fiche de cet accord).

Comment obtenir des accessoires à partir de la valeur de référence sur le client

Dans le formulaire de traitement, cliquez sur la valeur de l'attribut.

Pour modifier un attribut, cochez la case à côté de la valeur. Après cela, la valeur peut être modifiée.

Pour enregistrer les modifications, appuyez sur le bouton de l'option souhaitée pour enregistrer l'enregistrement en mode "échange de données - téléchargement", enregistrement normal. affichage (uniquement pour les documents).

Si vous avez besoin d'écrire certains des détails modifiés et d'en écrire quelques-uns, décochez les cases à côté de ce que vous devez écrire.

Il y a des "données d'attribut" dans le traitement - c'est la même chose que vous ouvririez une valeur par référence (par exemple, une carte de contrepartie) et appelleriez à nouveau le traitement dedans.

Vous pouvez comparer des objets :

Sélection de 2 objets à traiter

2. En appelant le traitement d'un objet, puis (sans fermer la fenêtre) d'un autre. Il vous sera demandé de faire une comparaison.

3. (Uniquement interface "gérée"). Sélectionnez 2 objets dans la liste à la fois (pour ce faire, maintenez la touche Ctrl enfoncée) et appelez le traitement - les objets seront comparés.

Captures d'écran (interface normale)

Captures d'écran (interface "gérée")

Exemples d'utilisation du traitement pour analyser des situations problématiques.

Changements dans la version 1.12 (17/10/2017)

• Pour la variante avec formulaires gérés, un bogue a été corrigé (l'attribut dans la section tabulaire n'était pas mis à jour si l'objet lui-même avait un attribut d'en-tête avec le même nom)

Modifications de la version 1.10 (01/06/2017)

• Pour la variante avec formulaires gérés, le travail a été corrigé dans certaines configurations typiques (Comptabilité, UNF)

Modifications de la version 1.09 (07/07/2015)

• Ajout de l'affichage des champs "Parent", "Propriétaire"
• Pour la version sous l'interface gérée, le travail sans fenêtres modales est fourni.

Modifications de la version 1.08 (04/03/2014)

Pour la version pour l'interface normale, amélioration de la compatibilité lors du travail en configuration "Manufacturing Enterprise Management" (UPP) 1.3.

Modifications de la version 1.07 (04/03/2013)

Il existe une version de traitement pour les formulaires "gérés" (la fonction d'installation et de mise à jour automatique n'existe que dans la version pour les formulaires normaux)

Correction d'un bug (les autorisations ont été définies dans la distribution de traitement)

Modifications de la version 1.06 (13/05/2012)

Affichage du champ Version de l'objet

Correction d'un bug (il était impossible de définir des droits de lecture seule dans le traitement)

Modifications de la version 1.05 (05/04/2011)

Correction d'un bug (lorsque l'on travaillait sous 8.2, l'enregistrement des documents n'était pas disponible en mode publication)

Modifications de la version 1.04 (13/04/2011)

Bug corrigé (lorsque l'on travaillait sous 8.2, un double-clic de la souris n'ouvrait pas les détails)

Le traitement peut maintenant passer à l'affichage des attributs de type de référence.

C'est-à-dire: disons que vous avez ouvert la vue des détails du document "Ventes de biens, services". DANS ce document il existe un attribut "Contractor" de type "DirectoryLink.Contractors". En cliquant sur cet attribut avec le bouton droit de la souris, vous recevrez menu contextuel, qui contient les éléments "Données d'attribut" et "Données d'attribut dans une nouvelle fenêtre". En sélectionnant l'un d'entre eux, vous pouvez afficher les détails de la contrepartie correspondante.

Changements dans la version 1.03 (15/10/2010)

Ajout de la possibilité de définir des utilisateurs et leurs droits d'accès au traitement.

Modifications de la version 1.02 (21/08/2010)

Les configurations sont prises en charge dans lesquelles le répertoire traitement externe appelés "formulaires d'impression supplémentaires".

Changements dans la version 1.01 (28.01.2010)

Correction d'un bug qui se produisait lorsque l'Objet1 était vide et que l'Objet2 était sélectionné (merci à rasswet de l'avoir montré) ;

La case à cocher "détails" fonctionne immédiatement, vous n'avez pas besoin de cliquer sur "Afficher" ;

La colonne "Type de valeur" a été renommée en "Type de valeur possible" et affiche le type de valeur défini pour cet attribut dans le configurateur. Pour les attributs qui ont un type composite, le type de valeur de cet attribut dans l'objet affiché est également affiché.

Si vous avez connecté le traitement à votre configuration, alors pour le mettre à jour :

téléchargez le traitement, ouvrez-le en tant qu'externe, il vous dira sur quoi et comment cliquer (le bouton "Installer", sélectionnez "Mettre à jour le traitement dans la base de données", cliquez sur le bouton "Exécuter")

Détails du formulaire

Un ensemble d'attributs de formulaire décrit le contenu des données affichées, modifiées ou stockées dans le formulaire. Dans le même temps, les détails du formulaire en eux-mêmes ne permettent pas d'afficher et de modifier les données. Pour l'affichage et l'édition, des éléments de formulaire (voir la section "Eléments de formulaire" de ce chapitre) associés à des attributs de formulaire sont utilisés. La totalité de tous les attributs de formulaire sera appelée données de formulaire.

Important! Il faut se rappeler que, contrairement aux formulaires conventionnels, toutes les données formulaire géré doit être décrit sous forme de détails. Il n'est pas permis d'utiliser des variables de module de formulaire comme sources de données pour les éléments de formulaire.

Il est possible d'attribuer Attribut de formulaire principal, c'est-à-dire un accessoire qui définira la fonctionnalité standard du formulaire (extension de formulaire). Rappelons que le formulaire ne peut avoir qu'un seul attribut principal.

Extension de formulaire- Ce propriétés supplémentaires, les méthodes et les paramètres de formulaire de l'objet ManagedForm qui sont spécifiques à l'objet qui est l'élément principal du formulaire.

Dans le processus de développement d'un formulaire, vous pouvez définir explicitement la possibilité d'afficher et de modifier des attributs de formulaire spécifiques, dans le contexte des rôles, à l'aide des propriétés Afficher et Modifier (pour plus de détails, consultez la section "Paramètres de formulaire basés sur les rôles" de le chapitre "Éditeurs"). De plus, la disponibilité de tel ou tel attribut dans le formulaire lui-même peut être configurée à l'aide d'options fonctionnelles (pour plus d'informations sur les options fonctionnelles, voir le chapitre « Gestion de l'interface de configuration »).

Propriété d'attribut de formulaire Données enregistrées est une indication que la modification interactive d'un accessoire entraînera une tentative de verrouillage des données de formulaire pour l'édition, ainsi que mise en place automatique signe de modification de formulaire.

Types de données disponibles dans un formulaire géré

Un formulaire géré diffère également d'un formulaire ordinaire par les types de données avec lesquels il fonctionne. Si un formulaire standard fonctionne avec la plupart des types fournis par 1C:Enterprise (y compris les types DirectoryObject, DocumentObject, etc.), les catégories de types suivantes peuvent être distinguées dans un formulaire géré :

• les types qui sont directement utilisés dans le formulaire sont les types qui existent du côté du client léger et Web (par exemple, Number, ReferenceReference.Products, GraphicScheme, SpreadsheetDocument) ;

• les types qui seront convertis en types de données spéciaux sont des types de données de formulaire géré. Ces types sont affichés dans la liste des attributs de formulaire entre parenthèses, par exemple (CatalogObject.Products) ;

• liste dynamique (pour plus de détails, voir la section "Liste dynamique" de ce chapitre).

Conversion d'objets d'application en données de formulaire

Certains types d'applications (comme le DirectoryObject, etc.) n'existent pas du côté des clients légers et Web (pour plus de détails, voir le chapitre Concept d'application managée). Par conséquent, pour la représentation sous forme de tels types d'application, la plate-forme a introduit des types de données spéciaux conçus pour fonctionner dans des formulaires gérés. Cette fonctionnalité d'une application gérée nécessite la conversion d'objets d'application en données de formulaire (et vice versa).

Les types de données suivants sont utilisés :

• FormDataStructure - contient un ensemble de propriétés d'un type arbitraire. Les propriétés peuvent être d'autres structures, des collections ou des structures avec des collections. Ce type est représenté, par exemple, sous la forme DirectoryObject.

• Le DataFormCollection est une liste de valeurs typées, semblable à un tableau. Un élément d'une collection est accessible par index ou par identifiant. L'accès par ID peut ne pas être disponible dans certains cas. Cela est dû au type d'objet d'application représenté par cette collection. L'identifiant peut être n'importe quel nombre entier. Ce type est représenté, par exemple, sous la forme partie tabulaire.

• FormDataStructureWithCollection est un objet représenté à la fois comme une structure et une collection. Il peut être traité comme n'importe laquelle de ces entités. Ce type est représenté, par exemple, sous la forme d'un ensemble d'enregistrements.

• FormDataTree – un objet conçu pour stocker des données hiérarchiques.

Un objet d'application est représenté par un ou plusieurs éléments de données de formulaire. En général, la hiérarchie et la composition des données de formulaire dépendent de la complexité et de la relation des objets d'application du formulaire géré.

Par exemple, un document contenant une section tabulaire sera représenté par un objet de type FormDataStructure (le document lui-même), auquel un objet de type FormDataCollection (la section tabulaire du document) est subordonné.

Important! Lors de la conception d'une configuration, il est important de se rappeler que les objets d'application ne sont disponibles que sur le serveur, tandis que les objets de données de formulaire peuvent être utilisés à la fois sur le serveur et sur le client.

Transmission de données entre les côtés client et serveur d'un formulaire géré

En fait, on peut dire que les données du formulaire sont une représentation unifiée des données des différents objets applicatifs avec lesquels le formulaire fonctionne de la même manière et qui sont présents à la fois sur le serveur et sur le client. C'est-à-dire que le formulaire contient une certaine "projection" des données des objets d'application sous la forme de ses propres types de données et convertit entre eux si nécessaire. Cependant, si le développeur de la configuration met en œuvre son propre algorithme de traitement des données, il doit alors effectuer lui-même la conversion des données (des types spécialisés vers les types d'application et vice versa).

Lors de l'édition des attributs du formulaire dans un éditeur spécialisé (pour plus de détails, voir la section "Attributs du formulaire" du chapitre "Editeurs"), il est possible d'influencer le transfert de données entre le client et le serveur lors de l'exploitation du formulaire. Pour ce faire, utilisez la colonne de l'éditeur d'attributs. Utilisez toujours. L'effet de cette propriété diffère pour trois types d'attributs :

• Pour un attribut subordonné à une liste dynamique (colonne liste dynamique):
  • propriété activée - l'attribut est toujours lu à partir de la base de données et inclus dans les données du formulaire ;
  • la propriété est désactivée - l'attribut est lu à partir de la base de données et inclus dans les données du formulaire uniquement lorsqu'il y en a un visible dans ce moment l'élément de formulaire associé à l'attribut ou à son attribut subordonné.

• Pour les accessoires subordonnés à la collection de mouvements :
  • la propriété est activée - les mouvements de documents sont lus à partir de la base de données et seront présents dans les données du formulaire ;
  • La propriété est désactivée - les mouvements de document ne seront pas lus à partir de la base de données et ne seront pas inclus dans les données du formulaire (s'il n'y a pas d'élément de formulaire faisant référence aux mouvements de document).

• Autres détails du formulaire :
  • propriété activée - l'attribut sera présent dans les données du formulaire, qu'il y ait ou non au moins un élément de formulaire associé à l'attribut ou à son attribut subordonné ;
  • La propriété est désactivée - l'attribut sera présent dans les données du formulaire uniquement s'il existe un élément de formulaire associé à l'attribut ou à son attribut subordonné. Contrairement aux accessoires de liste dynamique, la visibilité de l'élément associé à l'accessoire n'a pas d'importance ici.

Note. Il convient de rappeler que la propriété définie sur l'attribut parent affecte tous les attributs subordonnés. Par exemple, si la propriété Utiliser toujours est désactivée pour la partie tabulaire du document, le système considère que cette propriété est également désactivée pour tous les attributs subordonnés (malgré l'état réel de la propriété).

Méthodes de conversion des données d'objet d'application en données de formulaire

Pour convertir des objets d'application en données de formulaire et vice versa, il existe un ensemble de méthodes globales :

• ValueInFormData(),
• FormDataToValue(),
• CopyFormData().

Important! Les méthodes qui fonctionnent avec des objets d'application ne sont disponibles que dans les procédures serveur. La méthode de copie des valeurs entre les données du formulaire est disponible sur le serveur et sur le client, car elle ne nécessite pas d'objets d'application en tant que paramètres.

Lors de la conversion de données de formulaire en un objet d'application, la compatibilité doit être prise en compte.

• ValueToFormData() – convertit un objet de type application en données de formulaire ;
• FormDataToValue() – convertit les données du formulaire en un objet de type application ;
• CopyFormData() – copie les données de formulaire qui ont une structure compatible. Renvoie True si la copie a réussi, ou False si la structure des objets est incompatible.

Note. Lors de l'exécution d'actions standard (ouverture d'un formulaire, exécution de la commande standard Enregistrer, etc.) d'un formulaire avec l'attribut principal, la conversion est effectuée automatiquement.

Donnons un exemple d'utilisation de la transformation de données dans vos propres algorithmes.

&OnServerCreateProcedureOnServer(échec, traitement standard)

ObjectProduct = Directories.Products.FindBy Name("Cafetière").GetObject(); ValueVFormData(ObjectItem, Object);

FinProcédure

&OnClient Procedure Write()

WriteOnServer();

FinProcédure

Procédure &AtServer WriteAtServer()

ObjectItem = FormDataToValue(Object, Type("CatalogObject.Products")); ObjetItem.Write();

FinProcédure

L'objet ManagedForm dispose également de méthodes disponibles sur le serveur :

• ValueVFormAttribute() – convertit un objet de type d'application en l'attribut de formulaire spécifié.
• FormAttributeToValue() – convertit l'attribut de données de formulaire en un objet de type application.

L'utilisation de ces méthodes est généralement plus pratique, car elles disposent, par exemple, d'informations sur le type de l'attribut de formulaire. De plus, la méthode FormAttributeToValue() définit la correspondance entre les données du formulaire et l'objet, qui est utilisé lors de la génération des messages. Vous pouvez en savoir plus à ce sujet dans le chapitre "Options du service de navigation".

Donnons un exemple d'utilisation de ces méthodes.

Procédure &AtServer RecalculateAtServer()

// Convertit l'objet d'attribut en objet d'application. Document = FormAttributeToValue("Objet"); // Effectue un recalcul selon la méthode définie dans le module de document. Document.Recalculer(); // Reconvertit l'objet d'application en props. ValueVFormAttribute(Document, "Objet");

FinProcédure

Interface logicielle

FormDataTree (FormDataTree)

• FindById (FindById)
• GetItems (GetItems)

Description:

Conçu pour modéliser un arbre dans des données de formulaire gérées.

Cet objet peut être sérialisé vers/depuis XDTO. Le type XDTO correspondant à un objet donné est défini dans l'espace de noms. Nom du type XDTO :

GetItems (GetItems)

Syntaxe:

GetItems()

Valeur de retour :

Tapez : FormDataTreeItemsCollection.

Description:

Obtient une collection d'éléments d'arborescence de niveau supérieur.

Disponibilité : client, serveur, client léger, client web.

FindById (FindById)

Syntaxe:

TrouverParID(<Идентификатор>)

Option :

<Идентификатор>(requis)

Tapez : Nombre. ID d'élément d'arborescence.

Valeur de retour :

Tapez : FormDataTreeElement.

Description:

Obtient un élément de la collection par ID.

Disponibilité : client, serveur, client léger, client web.

FormDataTreeItem (FormDataTreeItem)

Propriétés:

<Имя свойства> (<Имя свойства>)

• GetID (GetId)
• ObtenirParent (GetParent)
• GetItems (GetItems)
• Propriété

Description:

L'élément de l'arborescence des données du formulaire.

FormDataTreeItemCollection (FormDataTreeItemCollection)

Éléments de collection : DataFormElementTree

Pour un objet, il est possible de parcourir la collection à l'aide de l'opérateur Pour chaque ... De ... Boucle. Le parcours sélectionne les éléments de la collection. Il est possible d'accéder à un élément d'une collection à l'aide de l'opérateur [...]. L'index de l'élément est passé en argument.

• Insérer
• Ajouter
• Index (IndexOf)
• Compter
• Clair
• Obtenir)
• Se déplacer
• Supprimer

Description:

Collection d'éléments d'arbre.

Disponibilité : client, serveur, client léger, client web.

Voir également:

• DataFormItemTree, méthode GetItems
• FormDataTree, méthode GetItems

Caractéristiques du travail avec un arbre de valeurs

Mise à jour de l'arborescence

Il ya un problème automne plates-formes lors de la mise à jour de l'arborescence.

Si un nœud a été développé dans l'arborescence et qu'un nœud subordonné a été sélectionné, alors lors de la mise à jour de l'arborescence avec la fonction ValueInDataForms la plate-forme tombe en panne.

Solution : avant la mise à jour, vous devez effacer l'arborescence.

Par exemple:

&OnServer Procedure ClearTree(elements) Pour chaque élément d'éléments Loop ClearTree(element.GetElements()); FinCycle ; elements.Clear(); FinProcédure

Procédure &AtServer FillConceptTree() dConcepts = cProperties.BuildConceptTree(OnDate, Meta.CurrentIB()); ClearTree(Concept Tree.GetItems()); ValueVFormData(dConcepts, ConceptTree); FinProcédure

&À la procédure client OnDateOnChange(Element) FillConceptTree(); FinProcédure

Imprimer (Ctrl+P)

Pour convertir des objets d'application en données de formulaire et vice versa, il existe un ensemble de méthodes globales :

• ValueInFormData(),
• FormDataToValue(),
• CopyFormData().

Les méthodes qui fonctionnent avec des objets d'application ne sont disponibles que dans les procédures serveur. La méthode de copie des valeurs entre les données du formulaire est disponible sur le serveur et sur le client, car elle ne nécessite pas d'objets d'application en tant que paramètres.

Lors de la conversion de données de formulaire en un objet d'application, la compatibilité doit être prise en compte.

• ValueInDataForms() - Convertit un objet de type application en données de formulaire.
• FormulaireDonnéesVersValeur() - convertit les données du formulaire en un objet de type application.
• CopyDataForms() - copie les données de formulaire qui ont une structure compatible. Renvoie True si la copie a réussi, ou False si la structure des objets est incompatible.

Lors de la conversion de données de formulaire en objets d'application et vice versa, la mise en cache d'objet est utilisée, mais la pertinence de la version de l'objet dans le cache est vérifiée.

NOTE. Lors de l'exécution d'actions standard (ouverture d'un formulaire, exécution de la commande standard Ecrire, etc.) dans un formulaire avec l'attribut principal, la transformation est effectuée automatiquement.

Donnons un exemple d'utilisation de la transformation de données dans vos propres algorithmes.

&Sur le serveur
Procédure sur CreationOnServer (échec, traitement standard)
ObjectProduct = Goods.FindByName("Cafetière").GetObject(); ValueVFormData(ObjectItem, Object);
FinProcédure
&ChezClient
Procédure Write()
WriteOnServer();
FinProcédure
&Sur le serveur
Procédure WriteOnServer()
ObjectItem = FormDataToValue(Object,Type("CatalogObject.Products"));
ObjetItem.Write();
FinProcédure

De plus, l'objet ClientApplicationForm possède des méthodes disponibles sur le serveur :

• ValeurVPropsForm() - convertit un objet de type d'application en l'attribut de formulaire spécifié.
• PropsFormVValue() - convertit l'attribut de données de formulaire en un objet de type application.

L'utilisation de ces méthodes est généralement plus pratique, car elles disposent, par exemple, d'informations sur le type de l'attribut de formulaire. De plus, la méthode FormAttributeToValue() définit la correspondance entre les données du formulaire et l'objet, qui est utilisé lors de la génération des messages.

Il convient également de rappeler que lors de la conversion d'objets de type ValueTable ou ValueTree en données de formulaire (à la fois en utilisant la méthode ValueToFormData() et en utilisant la méthode ValueToFormAttribute()), la caractéristique suivante doit être prise en compte : l'objet converti doit contenir tous les colonnes qui existent dans les formulaires de données.

ATTENTION! Les colonnes d'attributs qui ne sont pas associées aux données ne participent pas à la conversion de valeur entre les données de formulaire et les objets base d'informations et retour. Les colonnes absentes des données d'objet sont effacées lors de la conversion en données de formulaire.

Lorsqu'un objet est passé dans les données de formulaire par le framework, ou lorsque des méthodes sont appelées ValueInDataForms(), ValueVPropsForm(), seules les données d'objet sont transférées. L'état interne de l'objet n'est pas transféré aux données du formulaire. Par exemple, la valeur d'une nouvelle référence définie sur un objet par la méthode SetReferenceNew(), seront perdus lors du processus de conversion de l'objet en données de formulaire et vice versa.

Comme premier paramètre des méthodes PropsFormVValue() Et FormulaireDonnéesVersValeur() seuls les attributs de formulaire des types suivants peuvent être utilisés :

• DataFormStructure,
• Collection de formulaires de données,
• DataFormStructureWithCollection,
• FormDataTree.

Donnons un exemple d'utilisation de ces méthodes.

&Sur le serveur
Procédure RecalculerSurServeur()
// Convertit l'objet d'attribut en objet d'application. Document = FormAttributeToValue("Objet");
// Effectue un recalcul selon la méthode définie dans le module de document. Document.Recalculer();
// Reconvertit l'objet d'application en props. ValueVFormAttribute(Document, "Objet");
FinProcédure