Funktionsaufrufe
Funktionsaufrufe (Function Calls) können den folgenden Elementen zugeordnet werden.
- Kontextmenüs
- Links
Funktionsaufrufe führen Standard-Funktionen, oder eigene codierte Programmabläufe aus. Die Verwendung, bzw. die praktische Anwendung wird in Kontextmenüs und Funktionsaufrufe in Kontextmenüs beschrieben, da dort auch die eventuell zu übergebenen Parameter beschrieben werden.
Eigenschaften
Bereich | Eigenschaft | Wert |
|---|---|---|
Kommentar (Comment) | Beliebiger Kommentar zur Dokumentation. Der Kommentar wird nicht zum Client übertragen und dient nur zur Dokumentation von Besonderheiten, Hinweisen, etc. Bei Auslieferung/Weitergabe der Lösung wird der Kommentar eingeschlossen, so dass der Empfänger ihn im AppDesigner sieht. | |
Funktion | Typ (Type) | 0 = direkte Angabe VBA-Systax in VBA-Aufruf mit Verwendung der definierten Parameter 1 bis 6 (jeweils optional, aber ohne Lücken) 1 = Internet-Aufruf (URL steht in Attribut "FunktionAufrufParameter1" des Kontextmenü-Eintrages ) 2 = Aufruf Drilldown-Funktion („gbControlCenterDrilldown“, die Parameter werden automatisch generiert; das Drilldown-Element wird in den "ChildPart"-Attributen des Kontextmenü-Eintrags angegeben) 3 = Aufruf Drilldown-Funktion (siehe Type 2; Inplace im Control-Center) 4 = Aufruf Drag-Funktion Listen- und Diagramm-Elemente (die Parameter werden automatisch generiert und im Ziel-Element als Platzhalter „SenderField(n)“ zur Verfügung gestellt; Funktionen dieses Typs sind im Kontextmenü nicht sichtbar) 5 = Aufruf Drop-Funktion Listen- und Diagramm-Elemente (freie Definition eines VBA-Aufrufes analog „Type“ 0 mit Einbeziehung der Drag-Parameter „SenderField(n)“; Funktionen dieses Typs sind im Kontextmenü nicht sichtbar; alternativ auch ohne VBA-Aufruf: In diesem Fall wird das im jeweiligen Kontextmenü-Eintrag definierte "ExecuteMacro" ("Makro ausführen") beim Drop ausgeführt. Die Drag-/Drop-Parameter stehen im Makro automatisch als lokale Variablen "_SenderField1" bis "_SenderField6" zur Verfügung. Die Funktionsparameter 1 bis 6 werden im Makro nicht benötigt.) 6 = Neuer Datensatz
die Methode "GetTemplate" des aktiven Datenservice ausgeführt)
7 = Datensatz bearbeiten (Der Name des aufzurufenden Elementes wird in den "ChildPart"-Attributen des Kontextdes Kontext-Menü-Eintrags angegeben) Diese Funktion kann in folgenden Szenarien verwendet werden:
8 = Datensatz löschen (Aufruf im Daten-Edit-Element; mit Sicherheitsabfrage; die Schlüsselfelder stehen im Daten-Edit-Part über den „PrimaryKey1“- bis „PrimaryKey9“-Attribute zur Verfügung)
9 = Datensatz kopieren (Aufruf im Daten-Edit-Element (nur Datensatz-basierend); mit Abfrage des neuen Primärschlüssels; die Schlüsselfelder stehen im Daten-Edit-Element über den „PrimaryKey1“- bis „PrimaryKey9“-Attribute zur Verfügung) 13 = Datensatz speichern (Aufruf im Daten-Edit-Element)
15 = Aufruf der „Execute“-Methode des in der verwendeten Datenstruktur definierten Daten-Service
Format: Name:=Makroausdruck[;...] Beispiel: Art:=1;Typ:=[_TypFeld];Titel:=[Titel]&" (Test)" Hinweis: Server-seitig steht zum Zugreifen auf die Parameterliste die Methode Sagede.Core.Tools.GetParameter zur Verfügung.
Anmerkung: Länger laufende Verarbeitungsprozesse, wie z.B. Importe, sollten asynchron ausgeführt werden, um Zeitüberschreitungen (Timeouts) zu vermeiden. Client-seitig wird dann eine "Fortschrittsanzeige" (Animation) angezeigt. Dabei bezieht sich "asynchron" nur auf die Client-Server-Kommunikation. Der Handlungsfaden im Frontend läuft erst weiter, wenn die Operation beendet ist.
16 = Aufruf einer VBA-Methode als Applikations-Service (wird später entfallen); für die Belegerfassungen und die Buchungserfassung wird der typisierte "gsAppServiceCall" (Datenzugriff per Interop-Objekt) verwendet; für alle anderen Data-Edit-Dialoge wird der generische "gsAppServiceCallGeneric" (Datenzugriff per XML) verwendet.
17 = Starten eines Makros (Parameter werden im Kontextmenü hinterlegt)
19 = Lokalen .NET-DLL-Applikations-Service aufrufen (Aufruf einer Client-seitigen .NET-Methode als Applikations-Service)
Die Klasse muss von einer der in „Sagede.OfficeLine.Shared.ClientActions.dll“ definierten Basisklassen "AppLibraryExecuteBase" bzw. "ClientLibraryExecuteBase" erben und die "Execute"-Methode implementieren. "AppLibraryExecuteBase" bekommt ein volles Mandantenobjekt übergeben und kann daher ausschließlich im Access-Client verwendet werden. "ClientLibraryExecuteBase" bekommt ein Basis-Mandantenobjekt übergeben und kann im Access-Client und im neuen Client verwendet werden.
Der Rückgabewert enthält den anzuzeigenden Fehlertext. 20 = Makro ohne Datenbezug aufrufen (analog zu "Starten eines Makros" (Funktionsaufruf 17), allerdings erfolgt keine Überprüfung, ob ein Datensatz ausgewählt wurde; Einsatz nur für Makros, die nicht Daten-abhängig sind.) |
VBA-Aufruf (VbaCall) | VBA-Aufruf ohne Klammern und Parameter | |
Automatisch aktualisieren? (RefreshAutomatically) | Soll nach dem Aufruf der Funktion automatisch eine Aktualisierung des Elementes erfolgen, aus dem die Funktion aufgerufen wurde? Hinweis: Nur sinnvoll bei synchronen Aufrufen (z.B. Kontextmenüeintrag aus Auskunft mit VBA-Aufruf, der Daten der Auskunft ändert) |
Alle Funktionsaufrufe sind Funktionen des Standards, die in eigenen Metadaten verwendet werden können.
Der Typ „Lokalen .NET-DLL-Applikations-Service aufrufen“ bedingt einen clientseitigen DLL-Aufruf und könnte damit nur vorübergehend zur Verfügung stehen. Sage ist sich bewusst, dass bestimmte Funktionen (z.B. das Öffnen einer Kassenschublade) clientseitige Aufrufe benötigen. Ansonsten verwendet auch Sage selbst Typen mit clientseitigen Aufruf, so dass bei einem Wegfall alternative Funktionsaufrufe, oder z.B. Metadateneigenschaften in Elementen zur Verfügung stehen werden.