Maar aan de linkerkant hebben we een leeg veld. Subsysteemopdrachten kunnen ernaar worden uitgevoerd:

om dit te doen, moet u de opdrachtinterface van het subsysteem configureren:

Om ervoor te zorgen dat de opdrachten aan de linkerkant van de interface zichtbaar zijn, moet u de vakjes in het actiepaneel aanvinken:

Zoals u kunt zien, zijn er naast het commandopaneel "Maken" ook "Rapporten" en "Service". Tot nu toe zijn ze niet beschikbaar bij ons, omdat we geen rapporten hebben gemaakt. Laten we ze maken en opnemen in het subsysteem Prijsbepaling:

Daarna kunnen we deze rapporten en verwerking toevoegen aan de opdrachtinterface:

Daarna verschijnen deze opdrachten in het opdrachtenpaneel:

Om ervoor te zorgen dat de verwerkingsopdrachten beschikbaar zijn voor toevoeging aan het opdrachtenpaneel, is het noodzakelijk dat dit rapport ten eerste deel uitmaakt van dit subsysteem en ten tweede dat er rechten aan worden toegekend:

ten derde moet het rapport een lay-out hebben:

Om de dienst beschikbaar te maken, moet de verwerking ook rechten hebben, ten tweede moet deze verwerking ook in het bijbehorende subsysteem zijn opgenomen en ten derde moet deze een opdracht hebben.

Ik publiceer het tweede hoofdstuk van mijn boek "Development Basics in 1C: Taxi"

Hoofdstuk 2: Reguliere en beheerde 1C-applicatie

In dit hoofdstuk zullen we kijken naar wat een reguliere applicatie en een beheerde applicatie zijn en hoe ze van elkaar verschillen, maar laten we eerst eens kijken naar het concept van een "interface".

Wat is eigenlijk een "interface"? In feite is dit een gemeenschappelijke grens tussen twee op elkaar inwerkende systemen (vaak is een persoon één systeem). Neem bijvoorbeeld een auto. Heeft het een interface? Oh zeker. Maar wat is de gemeenschappelijke grens tussen een auto en een persoon? Ten eerste is het een werkplek, d.w.z. direct de bestuurdersstoel en bedieningselementen (stuur, gaspedaal, rempedaal, enz.). Ten tweede zijn dit de principes van de interactie tussen mens en auto, een soort reeks regels. Om bijvoorbeeld de auto te versnellen, moet u het gaspedaal indrukken, vertragen - het rempedaal, om naar rechts te draaien moet u het stuur naar rechts losdraaien, enz. Dankzij deze twee entiteiten kan een persoon een auto besturen. Neem één ding weg en rijden zal niet mogelijk zijn.

Zo is het ook in de softwarewereld. Eén systeem is een persoon - een operator, een gebruiker. En het tweede systeem is een applicatie die is gemaakt om een ​​bepaald type menselijke activiteit te automatiseren (we overwegen toegepaste programmering).

Zo moeten we de magazijnboekhouding zelfstandig voeren: om de goederenontvangst in het magazijn uit te voeren, dit product af te schrijven en de saldi te bewaken. Wat zal de gemeenschappelijke grens zijn tussen de applicatie, ongeacht hoe en waar deze is geschreven, en de gebruiker? Ten eerste zijn dit de organen voor het invoeren van informatie - anders, hoe kunt u naar het programma overbrengen dat 5 stuks van een product in het magazijn zijn aangekomen. In ons geval is dit een computertoetsenbord en een computermuis. Ten tweede is het een systeem van interactie tussen een computer en een persoon. Het kan bijvoorbeeld een opdrachtregelinterface zijn: u gebruikt het toetsenbord om verschillende tekstreeksen (commando's) in te voeren en deze te gebruiken om de nodige acties uit te voeren (registratie van de aankomst van goederen, verbruik van goederen, enz.). Zo'n interface ziet er ongeveer zo uit: zie fig. 1.2.1.

Rijst. 1.2.1 Voorbeeld van opdrachtregel

Deze afbeelding toont de opdrachtregel van het Windows-besturingssysteem, met behulp hiervan kunt u bijna alle bewerkingen uitvoeren die u in Verkenner doet: bestanden kopiëren, bestanden verwijderen, mappen maken, enz.

Dit type interface is al lang archaïsch en is vervangen door een grafische gebruikersinterface (eng. grafische gebruikersinterface GUI). In deze interface vindt de interactie tussen de gebruiker en de applicatie plaats via verschillende grafische elementen die op het display worden getekend (knoppen, pictogrammen, schakelaars, enz.). In de grafische interface heeft de operator willekeurige toegang via de bedieningselementen tot alle grafische elementen. In ons geval, wanneer we magazijnboekhouding automatiseren, kan de interactie er als volgt uitzien: de operator klikt op de knop "Aankomst", het productselectieformulier wordt geopend, waar de operator het gewenste product uit de lijst selecteert en de hoeveelheid invoert. Als u een uitgave moet doen, klikt de operator op de knop "Verbruik", het selectieformulier wordt ook geopend, waar de operator ook het gewenste product selecteert en de hoeveelheid invoert. Wanneer het nodig is om de saldi op elkaar af te stemmen, klikt de operator op de knop "Balansen" en toont het programma de saldi van de goederen in het magazijn. Met behulp van deze grafische interface kunt u dus vrij goed de goederen in het magazijn volgen.

Laten we eindigen met het theoretische gedeelte en direct naar het onderwerp van dit hoofdstuk gaan. Namelijk naar de soorten applicatie-interfaces van het 1C-programma, die allemaal grafische gebruikersinterfaces zijn. Het 1C: Enterprise 8-programma heeft twee algemene typen grafische applicatie-interfaces. Dit zijn de normale toepassingsmodus en de toepassingsmodus onder Beheerde formulieren (of Beheerde toepassing).

Platformen van editie 8.0 en 8.1. werkte alleen in de normale modus, hogere platformversies (8.2, 8.3, etc.) kunnen zowel in de normale applicatiemodus als in de beheerde applicatiemodus werken.

Normale applicatiemodus

Bijna alle moderne configuraties draaien al in de beheerde modus, maar er zijn nog steeds organisaties die legacy-configuraties gebruiken die in de reguliere toepassingsmodus draaien. Daarom moet u weten hoe een typische toepassing werkt. Dit wordt uitgebreid besproken in mijn boek (hoofdstukken 3 en 4). We zullen hier alleen de meest algemene punten aanstippen.

De normale toepassingsmodus gebruikt de interface en formulieren die werden gebruikt in platforms 8.0 en 8.1. Voorheen werd deze modus op geen enkele manier genoemd, maar nu wordt het "normale toepassingsmodus" genoemd en de formulieren die in deze modus worden gebruikt, worden "normale formulieren" genoemd.

Laten we eens kijken hoe deze modus eruitziet. Velen zullen het bekend voorkomen, maar sommigen, vooral degenen die geen werk hebben gevonden onder de 8.0- en 8.1-platforms, zullen het voor het eerst zien.

Na het laden van het programma ziet de gebruiker een interface met bovenaan een menu (zie Fig. 1.2.2).

Fig 1.2.2 Interfaceweergave van een reguliere applicatie

Door te navigeren door de menu-items kan de gebruiker verschillende formulieren openen. Dit zijn in principe vormen van lijsten met naslagwerken en documenten (zie figuur 1.2.3), maar er kunnen ook rapporten, verwerkingen, rekeningschema's, enz. zijn.

Afb. 1.2.3. Vorm van de lijst met documenten

Vanuit het lijstformulier kan de gebruiker het formulier van een document of naslagwerk openen (zie Fig. 1.2.4).

Rijst. 1.2.4. Documentformulier

De ontwikkelaar kan automatisch gegenereerde formulieren gebruiken of deze zelfstandig ontwerpen.

De ontwikkelaar moet de gebruikelijke formulieren met de muis maken: plaats de benodigde elementen (knop, veld, tabel) op het formulier, verplaats ze naar een geschikte plaats en bepaal de grootte (zie Fig. 1.2.5).

Afb. 1.2.5. Regelmatige vormen construeren

Heel vaak moest bij het ontwikkelen van complexe vormen rekening worden gehouden met de interactie van vormelementen met elkaar. Hiervoor werden bindingen opgericht. Soms raakten ze in de war en kreeg de vorm een ​​niet erg mooi uiterlijk. We zullen niet te diep ingaan op dit mechanisme en de gevolgen van misbruik, aangezien het bij gecontroleerde vormen zijn relevantie heeft verloren.

Tot slot wil ik opmerken dat, in tegenstelling tot een beheerde applicatie, een gewone applicatie alleen kan werken onder een "thick client". Over het algemeen is dit het belangrijkste, meest kardinale verschil tussen conventionele en gecontroleerde vormen. Omdat de beheerde applicatiemodus speciaal is ontworpen om onder een "thin client" te draaien.

Beheerde applicatiemodus

Dus wat is de eigenaardigheid en het fundamentele verschil tussen de beheerde applicatiemodus en de gebruikelijke? Het belangrijkste verschil is het gebruik van een beheerde opdrachtinterface en beheerde formulieren. Laten we elk van deze entiteiten afzonderlijk analyseren. Wat is een beheerde opdrachtinterface? Om deze vraag te kunnen beantwoorden, is het nodig weer diep in het verleden te duiken.

Laten we eens kijken in zijn eenvoudigste vorm hoe de ontwikkeling van de configuratie werd uitgevoerd in een reguliere applicatie. Eerst ontwierpen we de bedrijfslogica: documenten, mappen, rapporten, verwerking en hun interactie met elkaar. Vervolgens hebben we de rollen ingesteld, een gebruiker met de rol "Leverancier" had bijvoorbeeld toegang tot het document "Goederenontvangst", maar niet tot het document "Goederenverbruik". En omgekeerd had een gebruiker met de rol "Verkoper" toegang tot het document "Goederenverbruik", maar niet tot het document "Goederenontvangst". De volgende stap was het ontwikkelen van interfaces voor elk type gebruiker. Degenen die de ontwikkeling onder een reguliere applicatie hebben geoefend, herinneren zich dat er een configuratie-object was als "Interface", waarin het mogelijk was om elk menu te configureren zoals het menu in figuur 1.2.2. En in ons geval moest de ontwikkelaar hard werken om twee interfaces te maken: één voor de leverancier en de andere voor de verkoper. Want als hij één gemeenschappelijke interface zou ontwikkelen waarin je zowel het document "Goederenontvangst" als het document "Goederenverbruik" kunt openen, zou het niet helemaal correct zijn als de leverancier, bij het openen van de lijst met documenten "Goederenverbruik", een berichtensysteem heeft ontvangen dat hij daar niet het recht toe heeft. Om dit te vermijden was het nodig om twee interfaces te creëren en voor elke gebruiker te specificeren onder welke interface hij zou moeten werken.

In de beheerde applicatiemodus is alles veel eenvoudiger. We zullen de beheerde opdrachtinterface in het volgende deel in meer detail onderzoeken. In dit deel zullen we het in de meest algemene termen opsplitsen. In het geval van de taxi-interface ziet de interface voor beheerde opdrachten er als volgt uit:

Rijst. 1.2.6. Gecontroleerde commando-interface

Bij het ontwikkelen van een beheerde applicatie zal de programmeur een iets andere weg inslaan. Voordat we de bedrijfslogica ontwikkelen, moeten we de subsystemen definiëren die onze objecten zullen bevatten (in een gewone toepassing bestaan ​​ze ook, maar ze zijn meer van declaratieve aard). Zo wordt het document "Aankomst goederen" opgenomen in het subsysteem "Bevoorrading" en het document "Verbruik goederen" in het subsysteem "Verkoop". Tegelijkertijd kunnen sommige objecten zich tegelijkertijd in verschillende subsystemen bevinden: de map "Producten" wordt opgenomen in het subsysteem "Verkoop", en in het subsysteem "Inkoop" en in het subsysteem "Marketing". In dit geval hoeft de ontwikkelaar geen "Interface" -object te maken, het systeem zal automatisch het gewenste interfacetype bouwen op basis van de instellingen van gebruikersrechten en functionele opties.

Als een gebruiker een rol heeft die geen rechten heeft om het subsysteem te bekijken, bijvoorbeeld "Supply", dan zal hij bij het starten van de 1C-applicatie dit menu-item gewoon niet zien. Ook zal hij geen document in de menulijst zien, waar hij op zijn minst niet het recht op heeft.

In figuur 1.2.6 heb je de gebruikersinterface met volledige rechten gezien, en de interface van de verkoper ziet er bijvoorbeeld als volgt uit:

Rijst. 1.2.7. Beperkte gebruikersinterface

Een ander verschil met de gebruikelijke interface is dat de gebruiker het uiterlijk van zijn interface onafhankelijk kan bepalen met behulp van navigatie-instellingen, acties, secties, enz. Vanuit de interface in figuur 1.2.7 kunnen we bijvoorbeeld de items "Magazijn" uit de functies verwijderen van de huidige sectie (bovenste menu) en "Product". Het zal er als volgt uitzien:

Rijst. 1.2.8. Gebruikersinterface met uitgeklede functies van de huidige sectie

In de volgende hoofdstukken van dit deel gaan we dieper in op het aanpassen van de gebruikersinterface, en in het volgende deel van deze cursus bestuderen we de relatie tussen rollen en het uiterlijk van de interface. Laten we in de tussentijd voor onszelf de belangrijkste verschillen opmerken tussen de beheerde opdrachtinterface en de gebruikelijke.

• Het type beheerde opdrachtinterface wordt automatisch geconfigureerd met behulp van de platformmechanismen, afhankelijk van de instellingen van gebruikersrechten en functionele opties.
• De gebruiker kan het uiterlijk van de interface naar believen aanpassen.

Laten we nu eens kijken naar wat beheerde formulieren zijn.

Leer programmeren in 1C met mijn boek "Programmeren in 1C in 11 stappen"

1. Geen ingewikkelde technische termen.
2. Meer dan 700 pagina's praktisch materiaal.
3. Elke taak gaat vergezeld van een afbeelding (screenshot).
4. Het verzamelen van taken voor huiswerk.
5. Het boek is geschreven in duidelijke en eenvoudige taal - voor een beginner.
6. Het boek wordt in pdf-formaat per e-mail verzonden. Kan op elk apparaat worden geopend!

Als deze les je heeft geholpen om een ​​probleem op te lossen, je het leuk vond of nuttig bleek te zijn, dan kun je mijn project steunen door een bedrag over te maken:

u kunt handmatig betalen:

Yandex.Geld - 410012882996301
Webgeld - R955262494655

Sluit je aan bij mijn groepen.

We weten allemaal dat 1C veel verschillende versies van het 1C-platform had, we zullen nu geïnteresseerd zijn in enkele van de nieuwste versies op het moment van schrijven, dit zijn versies 1C 8.2 en 1C 8.3. Als je in beide versies zou moeten werken, dan heb je hoogstwaarschijnlijk merkte verschillen op in de interfaces van deze versies, voor gebruikers verschillen ze alleen extern. In wezen de keuze reguliere of beheerde applicatie vertelt het systeem welke formulieren moeten worden weergegeven om uit te voeren, conventioneel of beheerd en welke client van de applicatie standaard zal worden gebruikt, dik of dun. Zie voor meer informatie over clients het artikel 'Wat is een dikke en een dunne client in 1C, en hun verschillen'.

Normale 1C-applicatie (normale vormen, normale interface, versie 1C 8.2)

In 1C 8.2 is alleen werken mogelijk met reguliere formulieren, in de normale applicatiemodus... De onderstaande afbeelding toont de basis in de bedrijfsmodus "normale 1C-toepassing" (normale vormen).

Beheerde 1C-applicatie (beheerde formulieren, beheerde interface, versie 1C 8.3)

Op het 1C 8.3-platform kunnen we zowel met reguliere formulieren (in compatibiliteitsmodus) als met beheerde formulieren werken. En beheerde formulieren hebben twee weergavetypen, standaard en taxi... Hieronder ziet u een voorbeeld van een 1C 8.3-configuratie met standaard beheerde formulieren, gevolgd door de "Taxi"-interface.

Wat is het verschil tussen een reguliere en beheerde 1C-applicatie?

Zoals we al hebben ontdekt een gewone applicatie en een beheerde applicatie zijn dit soort manieren om een ​​1C-programma te starten... Bovendien, afhankelijk van de waarde van het 1C-starttype ( reguliere of beheerde applicatie), wordt standaard een specifieke interface geladen ( reguliere of beheerde formulieren), vandaar dat er zoveel synoniemen zijn voor dit concept. We willen opmerken dat de verschillen in de interfaces behoorlijk groot zijn, de beheerde interface is volledig opnieuw ontworpen. In principe zijn dit alle verschillen die gewone gebruikers van het 1C-programma zien. Wat programmeurs betreft, de beheerde interface vereist het schrijven van aangepaste code, omdat de ontwikkeling al aan de gang is in 1C 8.3 en niet in 1C 8.2, met alle gevolgen van dien. De code moet ook worden onderverdeeld in client en server, dit wordt aangegeven met behulp van de juiste richtlijnen in de configurator.

Na drie dagen geleide vormen te hebben geoefend, werd ik verliefd op ze. Het is niet nodig om de velden met de muis op het formulier te plaatsen, om last te krijgen van bindingen. Alles is eenvoudig en in een paar klikken gedaan.

Ik vond het zelfs jammer dat 1C de gebruikelijke formulieren niet volledig heeft verlaten vanwege het feit dat ze in desktopmodus worden gebruikt. Het zou immers mogelijk zijn om nauwkeurige pixelpositionering in UV mogelijk te maken en de gebruikelijke vormen zouden na verloop van tijd uitsterven. En dus moet je krachten verdrijven op de kennis van de oude functionaliteit.

En dus is UV natuurlijk veel sneller dan normaal, want werken volgens een drieledig schema tussen de client en de server.

Bovendien is de UV-functionaliteit zelf veel rijker en breder dan die van de gebruikelijke - niet verrassend, er is veel tijd verstreken en er zijn veel interface-bevindingen in verwerkt.

Bijvoorbeeld het weergeven van een dynamische tabel met groeperingen, of het direct in een dynamische lijst trekken van objectattributen. Of zelfs een keuzerondje, niet in de vorm van stippen, maar in de vorm van tuimelschakelaars.

In de praktijk zijn ze niet zo eng in gebruik als het in eerste instantie leek, ik was er snel aan gewend. Ooit programmeerde ik genoeg algemene modules die alleen op de server werkten, en kreeg ik te maken met veranderlijke waardeconversies om ze door te geven aan de server, dus voor zover ik weet waren er beheerde formulieren beschikbaar.

Modaliteiten, gebeurtenissen en interfacevergrendelingen

Ik hoorde dat er in 8.3 een daling was in modale functies zoalsVraag, Een waarschuwing, OpenFormModal... Het was mij niet duidelijk waarom dit werd gedaan.

Stel je mijn verbazing voor toen, in een van de voorbeelden, de leraar ervoor zorgde dat een formulier werd geopend met de parameter "Vergrendel de hele interface", d.w.z. is in wezen modaal.

Ik was er zeker van dat de modaliteit werd verlaten.

Het begrip kwam niet meteen.

Modale vensters zijn niet verlaten in 1C. Er zijn nieuwe functies om een ​​waarschuwing weer te geven, een vraag te stellen, een modaal dialoogvenster voor bestandsselectie te openen.

De nuance is dat na het aanroepen van deze modale vensters, de besturing niet bevriest, zoals voorheen, in afwachting van het sluiten van het formulier, maar doorgaat. Het formulier geeft een melding dat het is gesloten en u moet deze melding afhandelen.

Die. het 1C-platform maakte het rudimentair van het bevriezen van code-uitvoering af en schakelde over naar volledig gebeurtenisgestuurd formulierbeheer.

Dit heeft natuurlijk niets te maken met browsers die moeite hebben om modals weer te geven. Dit is waanvoorstelling en vooroordeel - vergeet het als een slechte droom. Alles is logisch. Nu de uitvoering volledig gebeurtenisgestuurd en asynchroon is, zijn we erin geslaagd om van synchrone uitvoering af te komen.

Mini-constructors verschenen in 1C - refactoring. Dit maakt het gemakkelijker om waarschuwingshandlers te schrijven voor asynchrone werking in plaats van ze handmatig te moeten schrijven.

De configuratie heeft de mogelijkheid om alle synchrone oproepen uit te schakelen (ze veroorzaken een fout), als resultaat zal deze volledig asynchroon zijn en voldoen aan de nieuwste vereisten voor het organiseren van het evenementmodel.

Nieuwe interfacefuncties

Menu

Als beheerde vormen een volkomen logische en juiste ontwikkelingsrichting lijken, dan is de ontwikkelingsrichting van het menusysteem voor mij onbegrijpelijk gebleven.
Ongetwijfeld is het menu, waar slechts één niveau wordt weergegeven, dan moet u het volgende subniveau invoeren, en dus voordat u het gewenste item kiest, is het al moreel verouderd en werd het vervangen door een menukaart, waar verschillende menu-items worden ingezet onmiddelijk. Dit werd standaard gedaan voordat de nieuwe menu-interfaces in 8.2 werden uitgebracht.

Ooit, in 8.1, heb ik een menusysteem gemaakt in de vorm van een hiërarchische directory aan de linkerkant, waar de zichtbaarheid van elk item werd bepaald door de toegangsrechten van de gebruiker voor wie het menu werd weergegeven.

Ik begrijp dat 1C het verkeerd vond dat het Interface-toepassingsobject niet wordt gebruikt, en heeft besloten er een nieuw, geavanceerd alternatief voor uit te brengen.

Het bleek op de een of andere manier lastig, naar mijn mening. Nogmaals, alles is gekoppeld aan aanpasbare rollen, wat ik nooit leuk vond - het beste rollensysteem is geschreven op het niveau van programmacode, het bewijs hiervan is het systeem van extra gebruikersrechten, waarmee je flexibel en zonder onnodige problemen toegang kunt instellen rechten in typische configuraties.

Over het algemeen zijn er nieuwe manieren om het menu te organiseren, naar mijn mening zijn ze niet erg succesvol, maar er is geen alternatief en ze worden gebruikt in standaard.

Ik vroeg de leraar: "Ik begrijp de beheerde formulieren, maar waarom moest je interfaces ontwikkelen, waarom was het onmogelijk om het klassieke menu enigszins aan te passen"?

Hij antwoordde mij dat het 1C-systeem zich ontwikkelt in de richting van het verhogen van het comfort en de snelheid van de gebruiker. Naar mijn mening is zo'n enorme verandering in het menusysteem het echter niet waard.

Doorgangsvolgorde

Trouwens, de volgorde van het verplaatsen is belangrijk voor het productieve werk van gebruikers - velen hebben al een bepaalde volgorde van het doorkruisen van velden op de machine onthouden. Dus alleen de bypass-opdracht in 8.2 werd verlaten. Het volgt strikt de volgorde waarin de elementen worden geplaatst. Gelukkig is er de mogelijkheid om programmatisch de uitgang van het veld te onderscheppen en de focus naar een ander veld te verplaatsen, anders zou het erg slecht zijn met de aangegeven prestaties.

Werkruimte en geneste formulieren

Er is maar één werkgebied. Daarom moet je formulieren van bijna alle gebruikers erin duwen en hun zichtbaarheid met rechten bepalen. Dit alles moet leiden tot chaos in grote configuraties.

Het zou veel gemakkelijker zijn om het te maken met programmacode of het mechanisme van geneste formulieren te gebruiken.

Wat is nog steeds niet geïmplementeerd in 8.2-8.3

Ik heb nooit geneste vormen te zien gekregen. Helaas zijn ze dat niet, hoewel ze in de oudheid werden gebruikt Toegang.

Er is geen slepen en neerzetten over het klembord. Die. je moet het met de muis slepen, je kunt niet aangeven - ik sleep het hier weg en plaats het hier, zonder het blik met de muis te scheuren, helaas. Hoewel software van derden hier misschien te hulp kan komen, tk. slepen en neerzetten is een systeemding in ramen.

Functionele opties en zichtbaarheid van elementen

Vroeger RLS zijn gemaakt om gebruikers alleen individuele tabelrecords te tonen.

De verdere ontwikkeling van zichtbaarheid waren functionele opties en instellingen voor het weergeven van velden per rol. Alles bij elkaar vormt dit een soort diverse dierentuin, er is geen algemene harmonie en samenhang.

Naar mijn bescheiden mening is de zichtbaarheid van de velden nog steeds gemakkelijker programmatisch te beheren dan declaratief, vinkjes plaatsen en een complex mechanisme van functionele opties maken.

Dat heb ik te zijner tijd bewezen RLS per wijziging is inferieur aan programmatische schrijfcontrole op object-/abonnementsmoduleniveau. Evenzo vermoed ik dat elke functionele optie inferieur is aan de gebruikelijke algoritmische beschrijving van controle over de zichtbaarheid van elementen - zowel wat betreft gebruiksgemak als de veelzijdigheid van de aanpak.

De gebruiker van de configurator moet veel nadenken over hoe de zichtbaarheid te regelen - door rollen of door functionele opties. Nadat hij ooit een universeel algoritme had geschreven om de zichtbaarheid van velden te bepalen, kon hij het altijd toepassen zonder een van deze platformkrukken.

Het oordeel - functionele opties en zichtbaarheid door rollen - is niet effectief, maar je moet ze weten, omdat ze worden gebruikt in typische configuraties.

8.2-interface en taxi-interface

Interface 8.2 en taxi-interface zijn compatibel, d.w.z. nieuwe objecten verschenen niet. De configuratie kan werken in 8.2 of Taxi, het is mogelijk om de gebruiker tussen deze interfaces te laten schakelen.

Het belangrijkste verschil is de locatie van de objecten in het hoofdmenu. In 8.2 namen ze veel ruimte in aan de linker- en bovenkant, waardoor er voor de gebruiker weinig ruimte over was voor het werkgebied in de rechter benedenhoek. In de Taxi-interface wordt het menu automatisch verborgen en blijft het in de vorm van een klein menu aan de linkerkant, waardoor bijna het volledige scherm aan het werkgebied wordt toegewezen.

Het is niet duidelijk waarom het nodig was om zo'n ingewikkeld pad te gaan, als uiteindelijk het basismenusysteem in 8.1 nog zuiniger was in het gebruik van de schermruimte?

Ook zijn in Taxi de principes van het weergeven van vensters veranderd, waardoor de code van formulieren voor 8.2 op sommige plaatsen onhandig is. Maar in deze richting heb ik het verschil nog niet gerealiseerd, hoewel de leraar probeerde de basisprincipes van Taxi te vertellen. Ik zal het in de praktijk proberen uit te zoeken, al vind ik al deze interfaceverbeteringen overbodig en in de praktijk onnodig voor gebruikers van zakelijke applicaties.

Trouwens, in 8.2 kun je het palet niet veranderen, het is als een visitekaartje van het 1C-platform. Evenzo leert het menu-organisatiesysteem in de vorm van 8.2 of Taxi gebruikers een bepaalde standaard. De praktijk leert echter dat de gebruiker vrijwel direct wordt omgeschoold in het nieuwe menusysteem. Het is veel moeilijker om de vaardigheden van het werken met documenten en rapporten te veranderen.

Daarom is al deze ruis en controverse rond het menusysteem mij niet erg duidelijk - dit is niet het belangrijkste punt in het 1C-platform, laten we het op het geweten overlaten van de platformarchitecten en de leiders die hen wijzen op de ontwikkelingsrichting .

onontwikkelde ideologie

De leraar merkte terecht op, hoewel het begrijpelijk is en dus, dat de platformontwikkelaars waar nodig geen nieuwe entiteiten creëerden.

Subsystemen worden bijvoorbeeld zowel gebruikt voor het opdelen van configuratieobjecten in blokken als voor het organiseren van functionele menu's (een nieuw alternatief voor het gebruikelijke applicatiemenu). Hoewel het logisch zou zijn om een ​​apart applicatie-object te maken, dat "Functiemenu" zou heten.

U moet ook lege rollen (interfacerollen) organiseren, die alleen nodig zijn om aan te geven welke objecten in een of andere vorm worden weergegeven. Hoewel het logisch zou zijn om het applicatie-object "Interface" in deze richting te ontwikkelen.

Twijfels over effectiviteit

Sommige 1C-benaderingen van: bruikbaarheid zijn in twijfel.

Zo is er in de cursussen veel aandacht besteed aan de afdrukbare vorm van het document dat in een apart subformulier van het document wordt getoond en wanneer het document wordt gewijzigd zodat het wordt gewist. Dit heeft niet veel zin, soms moet u meerdere exemplaren afdrukken - bijvoorbeeld voor en na het bewerken. Het is onmogelijk om in een paar documenten en verschillende gedrukte formulieren verward te raken met oefenen, dus de verspreiding van energie in deze richting leek me dubieus.

Ook is het in het platform bijvoorbeeld onmogelijk om een ​​invoerveld in een cel van een dynamische lijst te maken als de bron niet de basistabel is. Niet omdat het technisch moeilijk is, maar om redenen bruikbaarheid.

Opties voor het opslaan van instellingen

Formulierinstellingen worden rechtstreeks in de basis opgeslagen en niet in de sessie. Ze gaan niet verloren bij abnormale beëindiging. Daarom is er een nieuw mechanisme verschenen om met deze instellingen te werken, waar u ook uw gegevens kunt opslaan. AlternatiefSaveValue/Waarde herstellen.

Nu kunnen alle opgeslagen instellingen, indien nodig, programmatisch worden opgesomd, wat betekent dat ze kunnen worden verwijderd naar een andere gebruiker, naar een bestand, enz.

Overige vragen

Wat zijn beheerde formulieren?

In beheerde formulieren wordt code uitgevoerd op de client en op de server.

Een client betekent een zwakke machine, het kan zelfs een gewone browser zijn.

En de server staat in directe en snelle verbinding met de database.

De klant kan niet met de database werken, hij kan kleine wiskundige bewerkingen uitvoeren en de elementen van zijn formulieren manipuleren. Als u iets uit de database moet halen of daar gegevens naartoe moet sturen, wendt de client zich tot de server.

Dit is hoe beheerde formulieren werken. Met de juiste vaardigheid is constante toegang tot de server niet moeilijk.

Zo'n organisatie is efficiënter dan verbinding maken met de server via remote access, daarnaast kan er direct via de browser gewerkt worden, d.w.z. op elk platform - Windows, Linux, Android, Mac OS.

Opmerkingen over 1C in bulk

Hier zijn de aantekeningen die ik voor mezelf heb geschreven, ze bevatten waardevolle kennis:

1. In het 1C-startvenster worden geen infobases geregistreerd, maar toegangspunten. Die. één basis kan meerdere keren aanwezig zijn, maar is geregistreerd voor verschillende gebruikers en verschillende werktools - browser, thin / thick client, beheerderslogin.
2. Er is een sleutel verschenen voor de beheerder die rolcontrole uitschakelt. U kunt op deze manier alleen inloggen op de Enterprise als er beheerdersrechten voor de configuratie beschikbaar zijn.
3. Algemene details - verwar ze niet met algemene details in 1C7, in 82 worden ze gebruikt om toegang in de interface te delen.
4. Ik gebruikte vaak de minimale lijsthoogte op het formulier om de onnodige schuifbalk van het formulier te verwijderen.
5. Het is niet de moeite waard om afbeeldingen op te slaan in een naslagwerkattribuut, dit leidt tot een daling van de prestaties van naslagwerken, u moet het informatieregister gebruiken.
6. In serverprocedures moet u bij het doorgeven van parameters VALUE gebruiken, zodat de parameter niet wordt teruggegeven aan de server.
7. Nieuwe functiesPagina begint met en Pagina eindigt met, mogelijk andere, vanaf platform 8.3.6.
8. In 1c 8.2 verscheen een bevoorrechte modus, d.w.z. u kunt toegangscontrole op rolniveau uitschakelen in codesecties.
9. De elementen van de formulierlijst, de tabel met waarden en de boom met waarden verschillen doordat de lijst op de server en op de client dezelfde presentatie heeft en er speciale objecten worden gemaakt voor de tabel en de boom en moeten worden getransformeerd op de server.
10. Ik was blij dat de leraar graag objecten in het enkelvoud benoemt en modules met een onderstrepingsteken benoemt, zodat deze modules eerst op volgorde komen in de contextuele hint.

Over het leven en rond 1C

De leraar verklaarde:

1. Ontwikkeling moet worden gedaan vanuit de interface.
   Mijn mening : De verklaring is dubieus, omdat kennis en ervaring met het gebruik van de platformarchitectuur stelt u in staat om rechtstreeks van de toepassingsobjecten te gaan en de interface later te bouwen.
2. De beheerder vult geen gegevens in, kijkt alleen naar de rapportages. En het regelt niet de invoer van gegevens in 1C, maar de telefoon en via de secretaresse. Daarom heeft de manager een browser nodig en zijn de invoervelden alleen nodig voor het filteren van gegevens.
   Mijn mening : Ja, het lijkt waar te zijn.
3. Bekritiseerde BSP (Bibliotheek van standaard subsystemen). In die zin dat het onmogelijk en zeer moeilijk is om er de nodige modules uit te selecteren.
   Mijn mening : Omdat zelfs de BSP kan niet in modules worden verdeeld, dan kan de UPP niet worden verdeeld in UT, ZUP, BP, productiemodules. En hier is niet het platform de schuldige, maar de verkeerde methode om standaard te schrijven - modulariteit wordt niet gerespecteerd. Hetzelfde Navision hij heeft lange tijd de mogelijkheid om eerst de boekhoudafdeling aan de klant te verkopen, en dan kan hij indien nodig extra handel, productie en salaris inkopen, zonder de code te herschrijven en over te stappen naar een nieuw programma.
4. Typische kenmerken zijn erg complex geworden en moeilijk te veranderen. Nogmaals, niet vanwege de complexiteit van het platform, maar vanwege de verkeerde organisatie van de standaard. Tegelijkertijd gaat het belangrijkste principe verloren - snel en economisch onderhoud en revisie van typische configuraties, indien nodig.
5. De mogelijkheid om een ​​bestelling te plaatsen werd gedemonstreerd, wanneer het item aan de linkerkant in de werkruimte staat en de lijst met bestellingen aan de rechterkant. Tegenover het artikel kunt u het aantal plaatsen, het vervolgens naar de lijst met bestellingen slepen en een bestelling plaatsen. Voordeel - de tabel met bestellingen wordt niet geblokkeerd voor het maken van een nieuwe bestelling.
   Mijn mening : Het voordeel is gekunsteld - niettemin zijn gebruikers meer gewend om het geselecteerde product in de tabelsectie te zien, u kunt deze bestelling opslaan als een concept of de bestelling kopiëren vanuit de sjabloon. Over het algemeen zijn de documenten niet voor niets uitgevonden.
6. Het verschil uitgelegd tussen de secties "Hoofd", "Belangrijk", "Ga naar", "Zie ook".
   Mijn mening : Persoonlijk begreep ik het vaag, wat betekent dat de meesten deze nuances die inherent zijn aan het platform niet zullen begrijpen bruikbaarheid in een taxi. Daarom zullen de interfaces er hetzelfde uitzien als voorheen, zoals zowel gebruikers als programmeurs in 1C gewend zijn.
7. In een cel van een tabelveld op een formulier waarvan de bron een willekeurige zoekopdracht is, kunt u geen gegevens invoeren, zoals in een invoerveld. Dit is in het belang van bruikbaarheid om de gebruiker te concentreren op het invoeren van gegevens in een apart venster.
   Mijn mening : Ik heb een voorbeeld gegeven met invoer in de tabelsecties, waar een dergelijk veld beschikbaar is, is de betekenis van het verbod mij niet duidelijk.
8. Echtscheidingen ontstaan ​​door het vergelijken van een echtgenoot met andere mensen. Minder vergelijkingen, sterker huwelijk.
9. Het is gemakkelijker om vreemde talen te leren als je er meerdere tegelijk studeert, het knipperen en de obsessie met één moedertaal wordt verwijderd.
10. Vreemde talen zijn niet te leren, als je een vreemd woord aan een woord in je moedertaal bindt, moet je aan een afbeelding binden. De ketting van een vreemd woord - een afbeelding is korter dan een ketting van een vreemd woord - een inheems woord - een afbeelding. In het laatste geval zal het niet werken om in een vreemde taal te denken.

Conclusie

Ik betuig mijn dank aan de leraar.

Het bijwonen van deze cursus heeft me verlost van mijn vooroordeel over beheerde formulieren, ik begreep duidelijk de nuances van modaliteit, de verschillen tussen de 8.2- en Taxi-interfaces.

Nu schrik ik niet af van gecontroleerde vormen, maar integendeel, ze trekken me aan om ze te herkennen.

Ik hoop dat u die dit artikel leest ook beheerde formulieren zult waarderen.

Wanneer een gebruiker 1C in Enterprise-modus binnengaat om te beginnen met werken, ziet hij allereerst de programma-interface.

In de programmering, onder het woord koppel kan verschillende betekenissen hebben. We bedoelen nu "gebruikersinterface".

De gebruikersinterface bestaat uit alle vensters, menu's, knoppen, enzovoort, waarmee de gebruiker rechtstreeks in het programma werkt.

Het interface-ontwerp is het gebruikte lettertype, de kleur, de achtergrondafbeelding en andere decoratieve elementen. Het ontwerp heeft geen invloed op de samenstelling van de interface.

In het 1C-platform zijn twee verschillende gebruikersinterfacemechanismen geïmplementeerd, die in verschillende worden gebruikt. De dikke 1C-client heeft zijn eigen interface, de dunne (en webclient) zijn eigen.

Laten we het vandaag hebben over de 1C-gebruikersinterface.

1C-interface

De 1C dikke clientinterface ziet er als volgt uit.

Het bevat:

• Hoofdmenu
• Panelen.

De desktop die in sommige configuraties (boekhouding, salaris) wordt gebruikt, maakt geen deel uit van de 1C-interface, het is de verwerking die afzonderlijk door de programmeur wordt gedaan en die in 1C op volledig scherm wordt geopend op het moment dat het programma wordt geopend.

In de configurator bevindt de 1C-interface zich in de tak Algemeen / Interfaces.

De programmeur maakt een 1C-interface met een specifieke naam en geeft bij het maken van een gebruiker de standaard 1C-interface van deze gebruiker aan.

In de eigenschappen van de 1C-interface is er een selectievakje "Switchable". Als de 1C-interface niet omschakelbaar is (het selectievakje is niet aangevinkt), kunnen alle gebruikers deze zien, zelfs als er een andere 1C-interface aan is toegewezen. In dit geval ziet de gebruiker beide interfaces samengevoegd tot één.

Wanneer u een 1C-interface toevoegt, ziet u een lijst met panelen. Standaard is er altijd een paneel, dit bevat het hoofdmenu van het programma.

Als u meer panelen toevoegt, worden deze weergegeven als panelen (met knoppen).

Wanneer u een geheel nieuwe 1C-interface toevoegt, wordt een constructor geopend, die helpt bij het ontwerpen van een menu door de vakjes op de benodigde objecten aan te vinken.

Bij het bewerken van een bestaand menu worden items één voor één toegevoegd, want wanneer de constructor opnieuw wordt aangeroepen, wordt het menu helemaal opnieuw gemaakt.

Wanneer u het bovenste menu-item toevoegt, kunt u in de eigenschappen een van de typische menu's selecteren - Bestand, Bewerkingen, Service, Windows, Help.

Nadat u een knop of menu-item hebt toegevoegd, moet u de uit te voeren actie selecteren. De actie kan van twee soorten zijn.

Als u wilt dat het 1C-object wordt geopend door erop te klikken - een directory, document of rapport - moet u op de knop met drie puntjes klikken en het gewenste object selecteren, evenals de gewenste vorm (mogelijke actie van het object).

Als u wilt dat een willekeurig commando wordt uitgevoerd als gevolg van het indrukken, drukt u op het vergrootglas. De functie is te vinden in. Na het selecteren van een module wordt er een handlerfunctie in aangemaakt, de module staat open voor bewerking.

Gecontroleerde commando-interface 1C

In de nieuwe versie van 1C 8.2 zijn nieuwe typen clients verschenen -.

De 1C thin client-interface ziet er als volgt uit.

De 1C-webclientinterface ziet er als volgt uit.

In het ideale geval zijn ze hetzelfde en, zoals je kunt zien, zijn ze heel anders dan de 1C-interface van de dikke client.

Het bestaat nu niet alleen uit menu's en panelen, maar ook uit:
1) Lijst met boekhoudsecties
2) Navigatie in de geselecteerde sectie
3) Opdrachten voor uitvoering in de huidige sectie
4) Formulieren voor het uitvoeren van de huidige bewerking.

Voor de vorming van de 1C-interface van de beheerde client worden geen "interfaces" meer gebruikt, deze is complex gevormd op basis van de vele instellingen die in de configuratie zijn gemaakt.

Feit is dat de 1C-interface nu voor alle gebruikers hetzelfde is en tegelijkertijd dynamisch, afhankelijk van de set gebruikersrechten en opdrachten die hij kan uitvoeren.
Je kunt ook zeggen dat het op basis is gevormd, daarom wordt het ook wel de 1C-opdrachtinterface genoemd.

Subsystemen 1C

De basis van de beheerde commando-interface van 1C is de lijst met boekhoudsecties. Bijvoorbeeld - geld en goederen, twee secties van de boekhouding.

In de configuratie is het object 1C Subsystem verantwoordelijk voor de boekhoudsecties, die zich in de tak Algemeen / 1C Subsystems bevinden.

Nadat u een 1C-subsysteem hebt gemaakt, in de benodigde naslagwerken en documenten, op het tabblad 1C-subsystemen in de objectconstructor, kunt u deze in dit 1C-subsysteem opnemen. Dit betekent dat ze tot dit onderdeel van de boekhouding behoren. Objecten kunnen worden opgenomen in verschillende 1C-subsystemen.