Brug af variable

Tager den med i &parm (hvis den altså ikke lige bruges til noget i den aktuelle situation).
En anden mulighed er at bruge Parametre-kartoteket eller TmpKontoSum. Sidstnævnte kan styres med sessionnr og dermed slettes efter brug.

Jeg forstår mulighed et og tre... men hvad er parameter-kartoteket?

Når jeg bruger &Parm, er den forresten så kun aktuel i min egen session?

&parm bruges til alt muligt - f.eks. til at overføre RecId mellem fakturering og udksrivning af faktura, og er en global variabel. Den "forsvinder" altså så snart du lukker ned, hvis ikke før. Hver bruger har sin egen &parm.
Parameterkartoteket kaldes med userid og navn. Det er en stor fordel, når systemet skal kunne huske din opsætning fra gang til gang. Det gælder f.eks. feltet "Udskriv" når man fakturerer. Har du en gang sat den til ja, så bliver den stående på Ja til næste gang du fakturerer.
Nu ved jeg ikke hvad du skal lave, men nogen gange er det en fordel med en gemt opsætning/variabel og andre gange skal den helst forsvinde. Gælder sidstnævnte, så brug &parm eller opret en ny global variabel. Det gøres i Macroen GlobaleVaribabler - pas på med navnet, og husk at skrive kommentarer til, så den er til at finde ved næste opdatering.

Jeg giver &parm en værdi i post-form på form1. Da jeg kommer over i form2 har &parm ingen værdi. Bruger jeg en forkert trigger i form1 eller er der andet galt?

Du kan ikke tage den med i &Parm, sådan uden videre. &Parm er en parameter som deles kan tildeles en værdi, dels en som indeholder oplysninger om den process der er kaldt. Når du f.eks. har et lokalmenupunkt i en form, kan du i Pre-Menu "føle" på hvad der står i &Parm; det vil så være det er står som parametre til processen der afvikles.

Hvis man kalder en proces uden om menu systemet, så ja, så kan man flytte noget med over i &Parm. F.eks. PROCESS #Proc_FrmRun 'Form=DebKart Parm=' + '1234566'. I init-triggeren på DebKart vil &Parm så indeholde værdien 1234566!

Så det kommer lidt an på hvordan du skifter fra den ene form til den anden. Du evt. prøve at beskrive det lidt nærmere.

Du kan også vælge at bruge en af de andre System-variable, f.eks. &MacroText, dog skal man være opmærksom på at den bruges mange steder, og sker der et kald af et eller andet mellem du gemmer og anvender i den nye form, kan din værdi være overskrevet.

Du kan også definere din egen globale variabel (dvs. en variabel som findes overalt uden at skulle defineres i den enkelte form eller kørsel). Den definerer du i macrobiblioteket GlobaleVariableUSR. Når du tildeler en variabel en værdi her, har den den indtil du 1) afslutter programmet 2) tildeler den en ny værdi. Variablen er "din egen", dvs. en anden bruger får ikke din værdi.

Husk at du skal genstarte C5 efter at have defineret variablen før du kan bruge den!

Jeg har nu prøvet det med min egen globale variabel.
Den fungerer godt nok i form1, men når jeg kommer over i form2, så eksisterer variablen ikke længere så jeg kan følge dens værdi i en debugging.
Jeg har startet c5 op på ny efter at have lavet den globale variabel.
Kan du se problemet?

Du er ikke kommet til at kalde den et navn, der allerede er i Form2 ?

Nope. Jeg forventede jo, at når jeg fortsatte min debugging fra form1 til form2, så kunne jeg stadig se den nye variabel. Desværre kan dens værdi ikke følges, så snart jeg kommer i form2. Har jeg defineret den forkert. Jeg har lagt den i GlobalevariableUSR og det ser ud på følgende måde: STR 30  &ProTimeBruger.
Skal jeg evt. loade GlobalevariableUSR i mine forms på en eller anden måde?

Jeg havde placeret &ProTimeBruger på mit skærmbillede, men har nu lavet en anden variabel (&Bruger), som er på skærmbilledet. Jeg overfører så værdien fra &ProTimeBruger til &Bruger og så virker det. Måske kan den globale variabel ikke tåle at ligge på skærmbilledet!?

Jeg bliver svar skyldig - men det er faktisk ret lærerigt, det her, og skal lige testes af en gang.

Nej, jeg ved det heller ikke lige.
Men det virker, så snart jeg undlader at lægge den globale variabel på skærmbilledet. Så det er vel bare at gøre det, på den måde så.
Tak for hjælpen begge. Lukker nu dette spørgsmål.

Fandt årsagen (nu jeg er i gang). Feltet er default på en form sat til Nej til globalt, så det er den opsætning, der ødelægger det "globale".

Kanon... det kan jeg godt se, så blev vi så kloge.

Du skal passe på med at sammenblande begreber. Når du arbejder med en variabel, kan du ikke blot oprette et felt i en form og kalde den det samme, det svarer til at oprette en ny lokal variabel, som så overstyrer den globale. Så løsningen er som du skriver, at kalde feltet noget andet og så tildele værdien til feltet via post-load triggeren.

Jeg skrev en gang i Arilds dage følgende indlæg på technet.
Jeg tror måske det kan hjælpe. Bær over med mig, det er desværre på engelsk.

Nogen foreslog en fremgangsmåde med at stoppe records ned i tabellen proccall (altså i databasen), og bruge dette til parameteroverførsel mellem to programelementer.


"
Use EXTERN

There is an easier approach than stuffing records in the proccall table before calling the DB change process. This approach requires cleaning up the proccall table when the script is done.

If you just introduce a VIRTUAL record using some arbitrary table (of course this could be the Proccall table as well) with a field big enough to hold your parameter and append it to your process call with the USING clause, then you can EXTERN it in your query.

Example:

XAL - Script
=====================================================
INTRODUCE TmpFrmVirtual RENAME PARMPASSING
SET PARMPASSING.Txt1 = 'Your parameterstring goes here'
PROCESS #Proc_DBChange 'MODE=TEMP FILE=DMO PROC=20 ARGS=\"Query=TestQuery PARM=1\"' USING PARMPASSING
=====================================================



QUERY TestQuery
=====================================================
INIT-TRIGGER:
EXTERN TmpFrmVirtual RENAME PARMPASSED
PRINT PARMPASSED.Txt1
PAUSE
.
.
.

=====================================================

The TmpFrmVirtual record is never inserted in the table it is only held in RAM, so that's why I refer to it as being VIRTUAL. It has two advantages:

Clean-up is automatic (RAM is deallocated when the script is finished)
You can actually transfer MORE parameters if needed without delimiting them with ; in a string. Just use different fields.

As the INTRODUCE command just allocates RAM, you can use this for passing parametes BY REFERENCE. So actually if you wanted to indicate to the calling script if the call to the query was successfull or not, you could just change another field in the table that you EXTERN in the query.

Like this:

XAL - Script
=====================================================
INTRODUCE TmpFrmVirtual RENAME PARMPASSING
SET PARMPASSING.Txt1 = 'Your parameterstring goes here'
PROCESS #Proc_DBChange 'MODE=TEMP FILE=DMO PROC=20 ARGS=\"Query=TestQuery PARM=1\"' USING PARMPASSING

{ The int1 field in PARMPASSING will indicate a value transferred from the qtx}
IF PARMPASSING.Int1 THEN
    PRINT "Things went well"
ELSE
    PRINT "Things went wrong"
ENDIF
PAUSE
=====================================================



QUERY
=====================================================
INIT-TRIGGER:
EXTERN TmpFrmVirtual RENAME PARMPASSED
PRINT PARMPASSED.Txt1
PAUSE
.
.
.
STOP-TRIGGER:
EXTERN TmpFrmVirtual RENAME PARMPASSED
SET PARMPASSED.Int1 = 0 { Unsuccesfull }
=====================================================
"

Slut

Lidt underligt at du får en hjælp som du selv skriver virker (efter lidt roden) og så afviser alle svar og tager pointene tilbage ...!