Detta beror på några särdrag hos den globala kontextfunktionen ConnectExternalComponent() .

Ofta har programmerare problem med att ansluta externa komponenter (till exempel drivrutiner för kommersiell utrustning) när användare arbetar med 1C, ansluter till servern via en terminal.

I det här fallet ser användarna till exempel den här bilden:

När du arbetar från lokala datorer finns det inga problem med att ansluta externa komponenter.

Vad är detta kopplat till? Detta beror på att när användare arbetar via en terminalserver har de färre rättigheter än när de arbetar på en lokal dator.

Du kan enkelt verifiera detta om du loggar in på terminalservern under ett konto med administrativa rättigheter.

Anledningen till denna skillnad är att 1C inte kan registrera en extern komponent i registret när användaren arbetar i terminalen under normala rättigheter, eftersom en vanlig användare har inte behörighet att skriva till systemregistergrenen HKEY_CLASSES_ROOT.

Publikationer om ämnet att ansluta externa komponenter i terminalen erbjuder en mängd olika metoder för att lösa detta problem.

Till exempel dessa:

1. Starta 1C för första gången under administrativa rättigheter.

Det här alternativet fungerar inte alltid. Jag ska förklara varför nedan.

2. Ge vanliga terminalanvändare behörighet att skriva till systemregistergrenen HKEY_CLASSES_ROOT.

Otillräckligt avancerade användare bör inte göra detta, annars kan det uppstå problem.

3. Använd olika prylar, registrera VK på uppdrag av en användare med fullständiga rättigheter.

Det är inte bra heller.

Så vad är det bästa sättet att ta sig ur den här situationen?

Jag erbjuder min lösning på detta problem. Enligt min mening - enkel och vacker.

När jag undersökte det här problemet ställde jag mig frågan: varför försöker 1C ens registrera VK med en ny sökväg? Hon är trots allt redan registrerad i systemet.

Poängen visade sig vara att i typiska 1C-konfigurationer (till exempel "Trade Management") används följande syntax för den globala kontextmetoden Connect External Component():

ConnectExternalComponent("Directory.ConnectedEquipment.Layout.DriverATOLBarcodeScanner", "ATOLScanner");

Som du kan se är drivrutinen VC ansluten från layouten "ATOLBarcode Scanner Driver" i katalogen "Connected Equipment".

Vad händer då?

1C sparar komponenten i användarens temporära mapp, till exempel "C:\Documents and Settings\User\Local Settings\Temp\1032\v8_4_12.tmp"

och försöker registrera den i registergrenen HKEY_CLASSES_ROOT precis längs denna väg.

På terminalen har vanliga användare inte rättigheter att ändra denna registergren, så komponenten ansluter inte till dem.

Låt oss nu prata om hur man tar sig ur den här situationen.

Den globala kontextmetoden ConnectExternalComponent() har flera syntaxalternativ. Detta är vad vi kommer att använda.

Så, steg för steg:

1. Registrera den externa komponenten med hjälp av verktyget regsvr32.exe på terminalservern i mappen C:\WINDOWS\SYSTEM32 för ett 32-bitars operativsystem eller i mappen C:\WINDOWS\SYSWOW64 för ett 64-bitars operativsystem.

2. Använd ett av två ytterligare syntaxalternativ för metoden ConnectExternalComponent():

Alternativ 1:

ConnectExternalComponent("C:\WINDOWS\SysWOW64\Scaner1C.dll", "ATOLScanner", ExternalComponentType.COM);

DriverObject = New("AddIn.ATOLScanner.Scaner45");

Alternativ 2:

ProgID = "AddIn.Scaner45";

ConnectExternalComponent(ProgID);

DriverObject = New(ProgID);

Enligt min mening är alternativ nummer 2 att föredra.

Samtidigt försöker 1C inte omregistrera VK:n med en ny sökväg i registret och därmed är alla problem lösta.

Tja, det är allt. Lycka till i ditt arbete!

[du måste registrera dig för att se länken]

Fråga: Installera en extern komponent


Berätta för mig hur man installerar en extern komponent. När följande kod körs visas ett fel. Hitta NameDecl.dll i layouten

Försöker att SetExternalComponent("GeneralLayout.Layout");
Undantag EndTry ;

Fel: Installation av extern komponent misslyckades! ()
Svar:
ConnectExternalComponent("GeneralLayout.Layout", "NameDecl", ExternalComponentType.Native) returnerar FALSE.

New("AddIn.NameDecl.CNameDecl", Odefinierad) = (()): Skriv odefinierad (AddIn.NameDecl.NameDecl)


Fråga: Ansluta en extern komponent i 1s 8.3.6 och Win8
AfterConnecting = New Alert Description("AfterConnectingVK", ThisForm);
StartInstallingExternalComponents(,"C:\Controller\vk_rs232.dll");
StartConnectingExternalComponents(AfterConnecting,"C:\Controller\vk_rs232.dll","DLL_Scales");

och jag får felet att
"Installationen av en extern komponent misslyckades! En komponent för klientprogrammet du använder kan saknas!".
Och nu förstår jag inte:
1. Komponenten kanske inte är registrerad i registret - hur kan jag kontrollera den där?
2. Kanske fungerar inte dess "version" under Win8, även om jag har den 32-bitars.

Fel: Installation av extern komponent misslyckades! 3. Kanske är 1C i sig för ny, d.v.s. Följaktligen kan det inte fungera med denna dll?
4. Tja, det är trivialt - jag skriver något fel.
Och allt detta ledde mig till nästa problem. VneshComp är installerat, nu måste du ansluta det. Och här är båda alternativen

ConnectExternalComponent("C:\Controller\vk_rs232.dll","Vågen")

ConnectExternalComponent("GeneralLayout.Layout","Vågen")


de ger FALSK!!!
Fråga: Extern component.dll
God dag alla.
En sådan fråga.
En dll-komponent som fungerar utmärkt i 1C 7.7
1s 8.1 vill inte starta alls...
Jag försökte klistra in den i C:\Program Files\1cv81\bin\cache1c.dll
Jag försökte registrera mig med regsvr32 "C:\Program Files\1cv81\bin\cache1c.dll"

Registrerar utan problem.
När jag vill komma åt den får jag ett felmeddelande: Fel vid laddning av extern komponent! cache1c.dll Procedure ButtonExecutePress(Button) Försök att ladda extern komponent( "C:\Program Files\1cv81\bin\cache1c.dll"); Undantagsrapport(

Fel: Installation av extern komponent misslyckades!"Fel vid laddning av extern komponent!"
+ "cache1c.dll" ); Slutförsök; Försök // Hämta komponentobjektet.
// m = Ny ("cache1c.GTMcmd" ); m = New COMObject("cache1c.GTMcmd" ); Undantagsrapport(); Slutförsök; Slut på förfarandet Det är banalt till den grad omöjligt...
Du måste pausa mellan samtalen (millisekunder)...

Procedur ButtonExecutePress(Button) Försök // Hämta ett komponentobjekt.


m = New COMObject("cache1c.GTMcmd" ); Undantagsrapport(

"Det gick inte att skapa ett externt komponentobjekt"

); Slutförsök;
Det finns en makefil i NativeApi-projektet. Med dess hjälp bygger jag ett .so-bibliotek på Ununtu.
Men när "Connect External Component" 1c kraschar.
Likaså om jag bygger med "build.sh" (i roten av projektet).

I själva makefilen ändrar jag flaggan från m32 till m64, eftersom 1c och själva x64-systemet. (med parameter m32 ansluter den inte ändå)
Här är ett exempel på att anropa VK från 1C 8.3:
Anslutning klar = ConnectExternalComponent("/home/alexeyubuntux64-20 gb/Documents/VNCOMP83/example/NativeAPI/AddInNative.so", "AddInNative", ExternalComponentType.Native);
Det finns en artikel just om detta ämne.

Men så vitt jag ser har alla dessa punkter redan tagits i beaktande och korrigerats i VNCOMPS-exemplet.

Men i grund och botten är det en fråga om kompileringsparametrar. En MB 32-bitars extern komponent ansluts till en 32-bitars 1c normalt, men jag distribuerade den på Ubuntu x64 1c enterprise83 8.3.5-1486 amd64. Och jag vill haka på henne på VK.
Är det någon som har några idéer om hur man löser detta problem?)

Fel: Installation av extern komponent misslyckades! VNCOMPS-exemplet borde fungera, men byggparametrarna måste justeras, eller så är själva plattformen som jag testar felaktig.

Jag undrar, är det möjligt att skriva en extern komponent i Java?


Fråga: Arbeta med en extern komponent med en 1C-server...

God eftermiddag,
Det finns en extern komponent skriven i C++, vars uppgift är att hämta information från en extern databas och returnera frågeresultatet i form av en värdetabell i 1C.
För att generera en värdetabell för det aktuella ögonblicket används IDispatch* pBackConnection-gränssnittet, mottaget som en parameter i Init()-funktionen. Därefter använder jag helt enkelt 1C-funktioner för att skapa en värdetabell, fylla den och returnera den till den andra parametern i CallAsFunc(...).
Problem började med övergången till 1C tunna klienter. På serversidan startar inte den externa komponenten riktigt. Du kan köra det på klientsidan, men det hela ser ut som kryckor och faller ur den allmänna "klient-server"-logiken i 1C. Till exempel förstår inte klienten vad en värdetabell är, problem med "globala" variabler, sessioner etc.
NativeAPI är ännu mer begränsad i detta avseende.
Att dansa med en tamburin ledde till att jag kunde starta en extern komponent under 1C-servern, MEN arbetet fortsätter tills ett försök görs att anropa Invoke på pBackConnection. 64-bitarsversionen av 8.2-servern försöker göra något tills den tar timeout, 32-bitarsversionen (VK är naturligtvis också 32-bitars) bara faller av direkt.
Följaktligen uppstår frågor: är detta tillfälligt eller går 1C-logiken ner på att avbryta detta arbetsschema? Om det är omöjligt att skapa interna 1C-strukturer (en värdetabell) på detta sätt, finns det i princip en beskrivning av vad en värdetabell är på systemnivå för att försöka skapa den i C++, fylla den och sedan helt enkelt lägga in den i 1C som en returparameter? Jag skulle åtminstone vilja få en riktning åt vilket håll jag ska gräva.

Tack.

Fel: Installation av extern komponent misslyckades!

Du skriver en sak och menar en annan.
I 1C-miljön är det inte omöjligt att deklarera variabler som kommer att vara synliga i olika sessioner nu, och det fanns ingen sådan möjlighet tidigare. En annan session är en fysiskt annorlunda process.
En session är en session som ansluter till en databas, dvs. användarsession. Eller lägger du något eget i detta koncept?

Inom en session var det möjligt, och det är nu möjligt, att deklarera variabler i sessionsmodulen som kommer att leva och vara synliga i sessionen från olika platser... faktiskt, det finns 4 av dem.
- Sessionsmodul;
- Regelbunden applikationsmodul;
- Hanterad applikationsmodul;
- Extern anslutningsmodul.

Jo, naturligtvis måste du komma ihåg sammanhanget. Serverkontexten är inte direkt tillgänglig på klientsidan och vice versa.

Faktum är att 1C-arkitekturen stipulerar att datautbytet kommer att gå till enligt följande:
- med hjälp av parametrar/returer av procedurer/funktioner;
- med hjälp av de så kallade sessionsparametrarna (kan inte vara objekt, men faktiskt synliga i paletten).

En tabell på formuläret... är den kopplad till någon objekttabell (t.ex. bearbetning)? eller inte. Om ja, så är den tillgänglig på servern (&OnServer) och redigera där....

Och ändå, ja, värdetabellen är inte tillgänglig i UV på klientsidan. Tja, det var vad 1C bestämde.

Kom igen! Det fungerar med Excel, det fungerar med FSO och en massa andra saker, men det fungerar inte här. Fånga felet och analysera....

Försök
...
dina handlingar
...
Undantag
str = ErrorDescription();
Slutförsök;

Med moderna hårdvarufunktioner är detta inte ett argument alls.

Bara din personliga åsikt. Har inget med verkligheten att göra. Inte på något sätt. Jag upprepar ännu en gång, 1C fungerar utmärkt med COM. Både med in-proc och out-proc.

Ange koden du använder för att ladda ner och kontakta VK.

Förresten, VK... i ditt fall, är det COM eller Native API?
Om COM, så registrerar du det som... via regsvr32... hur "löser" du då problemet med bitdjup?

Fråga: 1C8 och en extern komponent med typen Native


God eftermiddag.
Jag har en BP 3.0.50.12-konfiguration och en önskan att implementera vägning från Vesy-Soft-företaget som använder UniServerAuto i den.
Utvecklarna kompilerade komponenten i Native för Windows 32 och 64 och arkiverade den med maifest-filen. Det finns också ett exempel för 1C på hur vikt kan beräknas. I den, med hjälp av en layout med binära data, indikeras detta arkiv, som jag förstår det. I exemplet är allt bra: komponenten är installerad, ansluten, sedan upprättas anslutningen och vikten avläses.
Men så fort du börjar överföra den till 1C läses inte vikten av. Allt verkar vara enkelt skrivet, men jag förstår inte var raken är.
Den som har lite tid - hjälp, ta en titt med ett öga, kanske är lösningen på ytan, men jag går någonstans på fel plats och gör fel sak. Jag har aldrig behövt arbeta med Native Technology förut...

Och i bilagan finns min bearbetningstext

Fel: Installation av extern komponent misslyckades!

Tja, jag har nyheter...
Jag började bara steg för steg se vid vilken tidpunkt det skulle börja misslyckas. För att göra detta skapade jag en tom databas och bearbetade den med kommandot. I analogi med leverantörens exempel överförde jag layouten till en ny konfiguration - den fungerar andra gången. Dessa. första gången nej, men andra gången ja. Detta föranledde tanken att det i vår bearbetning fortfarande skulle vara nödvändigt att separera anslutningen av komponenten och objektet enligt olika procedurer.
Sedan överförde jag det till min databas med anslutningen av layouten - det fungerar. Puh, det är bra.... Men jag skulle vilja utan att göra ändringar i konfigurationen, så låt oss gå vidare

Jag försöker lägga till layouten i bearbetningen. Dess storlek ökar omedelbart från 10kb till 3mb och en betydande nedgång i driften märks - det är inte lämpligt. Jag börjar gräva mot att ansluta komponenter via dll. Dessa. i stort sett samma som där jag började. Men det finns ett "MEN": när jag sökte efter dll-namnet i användarens mapp, märkte jag att denna dll finns där (som jag förstår det) de dlls som är registrerade i 1C läggs ihop:
C:\Users\USER\AppData\Roaming\1C\1cv8\ExtCompT
Följaktligen finns det inget behov av att använda hela sökvägen till dll-filen, du kan helt enkelt ange dess namn:
ConnectExternalComponent("Add1CUniServerAuto32.dll", "UniServerAuto", ExternalComponentType.Native);

Jag försöker... den svär vid registrering, men ger vägningsresultatet. Det visar sig att dll-filen redan är registrerad och det betyder att du bara behöver ansluta den. Jag tar bort den och allt fungerar.
För att sammanfatta det:
1. Vid vägningsbearbetning innefattade proceduren When Opening anslutning av en extern komponent och en anslutning till ett objekt.
2. Sökväg till dll-filen Jag skrev inte den, jag angav bara dess namn.

Nu sitter jag och funderar, när installerades dll i 1C? Vid tidpunkten för mjukvaruinstallation? Knappast... Vid tidpunkten för lanseringen av utvecklarkonfigurationen för denna dll, var installeras den när formuläret öppnas? Jag vet inte, men det verkar nära mig... Vad tycker du?
Och för det andra, på en ny plats, när det finns ett behov av att installera samma terminal, vad behöver göras för att allt ska fungera? Ska jag installera programvaran fullständigt, köra leverantörens konfiguration för att kontrollera operationen och sedan (i teorin) ska min bearbetning fungera? Något är på något sätt komplicerat... Eller ska jag installera extern komponent en gång i min bearbetning efter att jag har installerat programvaran?

Jag skulle vilja höra dina tankar om detta...

Fråga: Flytta en del av koden till en extern komponent


Många artiklar om att skydda bearbetning beskriver att en del av koden överförs till en extern komponent, men det är inte klart hur exakt programmeraren agerar i sådana fall.
Alla som har gjort detta eller stött på liknande avgöranden, förklara själva principen med ett enkelt exempel. Det verkar som att allt är klart med att ansluta externa komponenter.

// Exempel på att fylla i värdetabellen TK.Clear(); Request = Ny begäran;
Query.Text = "VÄLJ |

Fel: Installation av extern komponent misslyckades! Nomenclature.Link HUR Nomenclature |FROM | Directory.Nomenclature AS Nomenclature"; Request Result = Request.Execute(); Selection = Request Result.Select(); While Selection.Next() Cycle Page = TK.Add(); Fill inPropertyValues(Page, Selection); EndCycle;

Kan du använda det här exemplet för att förklara vilken del av koden som vanligtvis tas ut? Det skulle vara logiskt att ta bort delen med begäran, men hur kan vi komma åt databasen från den externa komponenten, förbi plattformen? Det är ingen idé att ta fram texten. Eller ta ut själva bildandet av den tabellformade delen. Dela din erfarenhet med alla som har stött på detta.


Och att ordet "Inkompatibelt" alltid betyder ordet "dåligt"? Ja, det verkar för mig att om jag kallade min stil "1C: Den sämsta programmeringen på denna skriptmotor som finns i naturen (översatt till litterärt språk)!" och då kommer det nog finnas folk som vill kolla in den här besten. Och det ser ut som en klassiker: "Jag har inte läst Pasternak, men jag håller inte med honom!"

Fråga: Extern komponent i Delphi Jag kan inte ansluta r 1C
Sammanställt ett exempelprojekt av en extern komponent
Fick DLL.

Registrerade det i systemet (Regsvr32 testvk.dll)
Nu måste du använda den i 1C. För att göra detta skrev jag extern bearbetning och i den:
&OnClient
Procedur Kommando1 (Kommando)
path="C:\1\VK Template\TestVK\DLL\testvk.dll";
OB = New ("Addln.TestVK"); Fråga: Externa komponenter för 1:or


Hej. Jag skriver en komponent för 1c7.7 i c#, jag ansluter den till 1c, allt är bra, men när jag vill anropa metoder eller egenskaper för 1c står det "fältet för det aggregerade objektet hittades inte", genom felsökaren fick jag reda på att metoderna för ILanguageExtender-gränssnittet inte anropas, efter att ha implementerat gränssnittet IInitDone kallas igen konstruktorklasskomponenter, enligt teorin om att skriva externa komponenter 1C, bör VK implementera minst två gränssnitt - IInitDone och ILanguageExtender, Jag implementerar dem, men jag kan inte förstå vad problemet är kanske någon har några idéer???

Fel: Installation av extern komponent misslyckades!Ämnet stängt, problemet löst.

Fråga: v7: Extern komponent för 1C7 i C#


Var kan jag titta på ett enkelt exempel för att skapa komponenter för 1C7 i C# som börjar med Visual studio 2010?

Fel: Installation av extern komponent misslyckades!

Titt
Skapa snabbt externa komponenter i C#. Exempel på användning av Global Context, IAsyncEvent, IExtWndsSupport, WinForms och WPF

Ofta har programmerare problem med att ansluta externa komponenter (till exempel drivrutiner för kommersiell utrustning) när användare arbetar med 1C, ansluter till servern via en terminal.

Detta beror på vissa särdrag hos den globala kontextfunktionen ConnectExternalComponent().

I det här fallet ser användarna till exempel bilden som presenteras i tillkännagivandet av artikeln.

När du arbetar från lokala datorer finns det inga problem med att ansluta externa komponenter.

Vad är detta kopplat till? Detta beror på att när användare arbetar via en terminalserver har de färre rättigheter än när de arbetar på en lokal dator.

Du kan enkelt verifiera detta om du loggar in på terminalservern under ett konto med administrativa rättigheter.

Anledningen till denna skillnad är att 1C inte kan registrera en extern komponent i registret när användaren arbetar i terminalen under normala rättigheter, eftersom en vanlig användare har inte behörighet att skriva till systemregistergrenen HKEY_CLASSES_ROOT.

Publikationer om ämnet att ansluta externa komponenter i terminalen erbjuder en mängd olika metoder för att lösa detta problem.

Till exempel dessa:

1. Starta 1C för första gången under administrativa rättigheter.

Det här alternativet fungerar inte alltid. Jag ska förklara varför nedan.

2. Ge vanliga terminalanvändare behörighet att skriva till systemregistergrenen HKEY_CLASSES_ROOT.

Otillräckligt avancerade användare bör inte göra detta, annars kan det uppstå problem.

3. Använd olika prylar, registrera VK på uppdrag av en användare med fullständiga rättigheter.

Det är inte bra heller.

Så vad är det bästa sättet att ta sig ur den här situationen?

Jag erbjuder min lösning på detta problem. Enligt min mening är den enkel och vacker, inte tidigare erbjuden på Lancer.

När jag undersökte det här problemet ställde jag mig frågan: varför försöker 1C ens registrera VK med en ny sökväg? Hon är trots allt redan registrerad i systemet.

Poängen visade sig vara att i typiska 1C-konfigurationer (till exempel "Trade Management") används följande syntax för den globala kontextmetoden ConnectExternalComponent():

ConnectExternalComponent("Directory.ConnectedEquipment.Layout.DriverATOLBarcodeScanner", "ATOLScanner");

Som du kan se är drivrutinen VC ansluten från layouten "ATOLBarcode Scanner Driver" i katalogen "Connected Equipment".

Vad händer då?

1C sparar komponenten i användarens temporära mapp, till exempel "C:\Documents and Settings\User\Local Settings\Temp\1032\v8_4_12.tmp"

och försöker registrera den i registernyckeln HKEY_CLASSES_ROOT längs denna väg.

På terminalen har vanliga användare inte rättigheter att ändra denna registergren, så komponenten ansluter inte till dem.

Låt oss nu prata om hur man tar sig ur den här situationen.

Global kontextmetod ConnectExternalComponent() har flera syntaxalternativ. Detta är vad vi kommer att använda.

Så, steg för steg:

1. Registrera den externa komponenten med hjälp av verktyget regsvr32.exe på terminalservern i mappen C:\WINDOWS\SYSTEM32 för ett 32-bitars operativsystem eller i mappen C:\WINDOWS\SYSWOW64 för ett 64-bitars operativsystem.

2. Använd ett av två ytterligare syntaxalternativ för metoden ConnectExternalComponent():

Alternativ 1:

ConnectExternalComponent("C:\WINDOWS\SysWOW64\Scaner1C.dll", "ATOLScanner", ExternalComponentType.COM);

DriverObject = New("AddIn.ATOLScanner.Scaner45");

Alternativ 2:

ProgID = "AddIn.Scaner45";

ConnectExternalComponent(ProgID);

DriverObject = New(ProgID);

Enligt min mening är alternativ nummer 2 att föredra.

Samtidigt försöker 1C inte omregistrera VK:n med en ny sökväg i registret och därmed är alla problem lösta.

Tja, det är allt. Lycka till i ditt arbete!

/
Utveckling av användargränssnitt

Installation av externa komponenter och plattformsförlängningar

1.1. Installation av externa komponenter och plattformsförlängningar ska vara interaktiva. Användaren måste fatta sitt eget beslut om installation. Installationsdialogrutan ska ange vad komponenten (tillägget) behövs till och vad som inte fungerar om den inte är installerad.

Till exempel är det felaktigt att använda konstruktioner som

Om du inte ansluter den externa komponenten (...) Installera sedan den externa komponenten (...)

Det är korrekt att uttryckligen ställa en fråga till användaren:

För att fortsätta arbeta måste du installera en extern komponent. En extern komponent gör att du kan arbeta med rapportering. För att installera komponenten, klicka på "Installera". När installationen är klar klickar du på Fortsätt.

  • Användaren använde kommandot "Skicka rapport".
  • Denna konfiguration kräver att någon extern komponent installeras.
  • Konfigurationen kontrollerar om komponenten är installerad.
  • Om komponenten inte är installerad, visar användaren information att för att skicka en rapport måste komponenten vara installerad och en knapp som gör att komponenten installeras.
  • Användaren trycker på knappen, installationen utförs.
  • Efter installationen klickar användaren på knappen "Fortsätt skicka rapport".
  • Programmet fortsätter att skicka rapporten.

Detta scenario säkerställer att komponenter (tillägg) installeras utan problem på alla webbläsare som stöds, inklusive webbläsaren FireFox.

2. Applikationslösningen måste tillhandahålla verktyg för användaren att installera externa komponenter och tillägg när som helst under drift. Således kan de installeras inte bara under lösningen av någon uppgift, utan också i form av en separat åtgärd (från något administrativt läge).

När den används i konfiguration Standardbibliotek för delsystem för att installera ett tillägg för att arbeta med filer, använd det allmänna kommandot InstallExtension Arbeta med filer, som rekommenderas att placeras i användarens formulär för personliga inställningar (se allmänt formulär _DemoMySettings i demokonfiguration). I samma form rekommenderas det att placera kommandon för att installera externa komponenter som användaren kan behöva under sitt arbete.