AppSys()

[Manfred]

Moin,

die AppSys() wird ja automatisch ganz am Anfang eingebunden/geladen. Somit ist es klar, dass man sich darum nicht kümmern muß.

Was kann man eigentlich alles in eine eigene AppSys() ausgliedern? Alles, oder ist es ratsam nur das Notwendigste reinzupacken?

Jedes Programm hat doch sicherlich Parameter, die programmweit zu sehen sind. Ist es empfehlenswert die Erzeugung eines solchen Objektes schon direkt in die AppSys() hinein zu legen? Somit würde ich die Sicherheit haben, in jedem Programm die entsprechenden Einstellungen zu haben, ohne sie jedesmal in die entsprechende Main() zu setzen.

[notloesung]

Hallo Manfred,

ich persönlich packe in die AppSys() z.B.

Code: Alles auswählen

   SET EPOCH TO 2000
   SET CENTURY ON

oder PUBLIC Variablen wie z.B.

Code: Alles auswählen

gcUser := GetUserName( <APP> ), ;
gcFile := <File in dem Usereinstallungen gespeichert sind>

Gruß,
Notloesung

[Martin Altmann]

Nun gut,
dann wollen wir mal Manfred helfen, auf die nächste Forenstufe aufzusteigen
Bei mir in der AppSys werden die globalen Variabeln deklariert und die Systemweit gültigen Konstanten belegt (durchaus in Abhängigkeit vom Kunden, für den die Version ist).
Außerdem werden - wie auch in der Hilfe beschrieben - das Anwendungsfenster und die Menüleiste erzeugt und angezeigt sowie die Onlinehilfe initialisiert.

Viele Grüße,
Martin

[Tom]

Es gibt in der Doku einen Abschnitt "Aufgaben von AppSys()". Sie ist eine implizite INIT PROCEDURE, die vor der Main() ausgeführt wird. Man kann dort alles hineinpacken, das einmalig beim Programmstart erfolgen soll. Fenster muß man dort genaugenommen nicht erzeugen, auch wenn die Funktion ursprünglich mal dafür gedacht war.

[Manfred]

Hi Martin, hi Notloesung



ok, alles klar, dass wollte ich nur wissen. Ich war mir nur nicht im klaren darüber, in welcher Stufe, bzw. welchem Zustand sich das Programm VOR der Main() befindet und ob man das machen kann. Aber es scheint der Fall zu sein.

Danke

[Manfred]

Hi,

und da war nämlich auch schon der Haken. Die Appsys() wird wohl noch vor der dbesys.prg aufgerufen und somit ist nix mit öffnen von DB, was eigentlich bei mir der Fall für Parameter sein sollte.

Hat jemand einen Vorschlag?

[Martin Altmann]

Hallo Manfred,
nimm doch den Teil aus der DBESYS-Prozedur mit in die APPSYS-Prozedur und definiere Dir eine leere DBESYS-Prozedur...

Viele Grüße,
Martin

[Jan]

Wenn ich mich da mal einklinken darf: Wo liegt denn dann (heutzutage) der Unterschied zwischen der AppSysy() und der Main()? Einfach nur philosophischer Art?

Jan

[Manfred]

Hi Martin,

ok, das wäre eine Lösung, aber kann man sowas unter saubere Programmierung verbuchen? Dafür ist doch die Appsys nicht vorgesehen gewesen? Bei der dbesys weiß ich doch, dass alle Programme darauf zugreifen. Da brauche ich nichts mehr zu beachten. Bei mir ist es so, dass es 2 verschiedene Appsys gibt. die eine für den Hybridmodus und die andere für Programme, die im reinen GUImodus laufen sollen. Dann müßte ich ja jetzt, oder die gesamte Übergangszeit, beide Appsys verändern und hätte somit "redundante" Daten.

Hm, muß ich mir Gedanken zu machen

[Manfred]

Hi Jan,

in der AppSys werden Dinge gemacht, die für alle anderen Programm auch gelten und somit nicht immer wieder in die Main eingebunden werden müssen.

[Tom]

Ich nutze beide (AppSys und DbeSys) nicht, sie sind also leer; bei mir geschieht alles in der Main() bzw. in von dort aufgerufenen Funktionen. Ich mache allerdings auch ausschließlich GUI.

[Manfred]

Hi Tom,

aber was hat GUI mit DBE Treibern zu tun? Ich denke in der dbesys wird der Treiber zusammengebaut, den man für die DBE benötigt? Wenn Du alles immer in der Main machst, dann hast Du entweder nur 1 Programm, alles doppelt gemoppelt, oder ich verstehe Dein System nicht.

[Tom]

Hallo, Manfred.

Ich baue die DBE selbst zusammen, wir nutzen DBFNTX plain oder mit der ADS. Die dafür nötigen Funktionen liegen in einer DLL, die wir statisch an alle Produkte linken.

[Manfred]

ach so,

ja soweit bin ich noch nicht. Da fehlt mir noch das Wissen zu, wie man DLL selber baut.

Wobei ich dazu auch noch eine Frage hätte, die aber, in einem anderen, neuen Thread, zu gegebener Zeit stellen werde.

[Jan]

Manfred,

in der AppSys werden Dinge gemacht, die für alle anderen Programm auch gelten und somit nicht immer wieder in die Main eingebunden werden müssen.

??? Muß ich das jetzt verstehen? Pro (GUI-)Programm gibt es doch genau 1 AppSys() und ebenfalls genau 1 Main(). Daher auch meine Frage, ob es noch irgendeinen Sinn gibt für diese beiden Progs.

Ich muß gestehen daß ich nach dem, was ich jetzt hier gelesen habe, der Vorgehensweise von Tom den Vorzug gebe. Warum wichtige Dinge zersplittern und unübersichtlich machen?

Jan

[Manfred]

Jan,

das siehst Du m.E. falsch. in der Projektdatei gibst Du z.B. Deine Zusatzbibliotheken an und auch eine evtl. Appsys, oder dbesys, oder was auch immer. Die ist dann 1x vorhanden und wird von allen anderen Programmen benutzt. Die Main, die gehört zum eigentlichen programm selbst und ist dann nur 1x je Programm vorhanden. Wenn Du nichts angibtst, dann werden die Standard Appsys und dbesys geladen.

[Martin Altmann]

Nur zum Verständnis:
Man kann in seinen Sourcen irgendwo eine Prozedur APPSYS definieren. Ist dies so, wird keine APPSYS.PRG hinzugefügt.
Fehlt in den Sourcen eine Prozedur APPSYS, so wird durch den Compiler/Linker automatisch die definierte APPSYS.PRG kompiliert und hinzugelinkt.
Wenn man nun - wie Manfred das meint - sich eine Datei APPSYS.PRG erzeugt, so kann man diese ja in alle XPJ-Dateien mit angeben und hat sie somit für alle Programme gleich.
Man kann es aber auch so machen wie Tom (oder ich) und sich in seinen Sourcen eine Prodzedur APPSYS definieren - und dies eben bei jedem Programm gesondert.

Viele Grüße,
Martin

[Manfred]

ok, so geht das halt auch. Ich möchte halt eine Datei, in er alle Parameter gesetzt werden, die für das entsprechende Paket benötigt werden. Die einzelnen Programme laden dann einzeln die einmaligen Proceduren. Bei einem anderen Projekt würde dann eine andere Appsys herhalten müssen. Aber egal, die Öffnung von DB klappt so nicht, also werde ich so weitermachen wie bisher, bzw. nur Dinge dort reinpacken, die keine DB benötigen.

Wie gesagt, die Sache mit den DLL werde ich nochmals ansprechen, ausser jemand hat schon Lust dazu etwas zu schreiben in der Wissensbasis.

[Jan]

Das Problem ist nur: Wenn man keine eigene AppSys() beifügt, dann läuft das immer über das schicke DOS-Fenster. Was zumindest ich nicht haben möchte.

Das ist für mich auch ein Qualitätsmerkmal. Geht erstmal das DOS-Fenster auf dann hat der Kunde das Gefühl, ein aufgebohrtes 16-Bit-Programm vor sich zu haben. Und ich will ja nicht, das der Kunde schlecht von mir denkt

Jan

[brandelh]

Hallo,

ich denke man sollte sich erst mal Fragen warum gibt es diese Funktionen ?

Ohne DBESYS und APPSYS könnte ein Clipperprogrammierer nicht einfach mit der MAIN() loslegen, sondern müsste zuerst ein Fenster und dann DBEs einbinden. Das kann aber keiner wenn er neu kommt bzw. der alte Clipper Code hat es nicht drin.

Beide werden also erstmal nur gebraucht, um Clippercompatibel zu werden. Bei einem reinen GUI Programm muss deshalb auch die function AppSys() definiert werden, da sonst automatisch das hybrid-fenster angezeigt wird.

Aber der Code der beiden pre functions kann nicht debugged werden !
Es ist auch nicht richtig, dass diese für jedes Programm gelten, sondern nur für die, die in der Projektdatei genau darauf Bezug nehmen (also neu definieren).

In den meisten meiner Programme wird die AppSys() leer definiert um das CRT Fenster abzuschalten. Die DBEsys() ist meist ok für mich, also lass ich die in Ruhe. Bei einigen Programmen habe ich aber auch beide ersetzt und mach alles in der MAIN. Der Vorteil hier ist, dass der Debugger genutzt werden kann.
Ab und zu habe ich das Basisfenster um Variablen erweitert und das in einer abgeänderten AppSys (nur der GUI Teil mit Erweiterungen) erledigt, da es dort einfacher war, als nachträglich die Eingenschaften anzuhängen.

Das Fenster in der AppSys() zu generieren verschlankt die MAIN(), aber man kann den Debugger nicht nutzen !
Wie schon öfters geschrieben, ich habe mein Grundgerüst von der MDIDEMO.PRG abgeleitet, dort wurde das so gemacht...
(xppw32\source\samples\apps\mdidemo\mdidemo.prg ...

Wenn man GUI Programme schreibt, kann man verschiedene Vorgehensweisen nutzen, ohne dass eine davon falsch wäre.

[Manfred]

Hi Hubert,

was heisst man kann den Debugger nicht nutzen? Mit entsprechenden Parameter fängt der direkt ganz am Anfang an.

[brandelh]

Hi Hubert,

was heisst man kann den Debugger nicht nutzen? Mit entsprechenden Parameter fängt der direkt ganz am Anfang an.

Mag sein, dass die neueren mehr können oder ich einen Parameter übersehen habe

[Manfred]

Hi Hubert,

/i ist der Parameter.

[Gerd König]

Hallo Manfred,

ich habe sowohl die AppSys als auch die DbeSys überschrieben.

Meine DbeSys lädt entweder DBFNTX oder ADSDBE

In der AppSys ist das Mappen der Netzlaufwerke und das Erzeugen eines Mutex-Wertes für die Applikation realisiert.

Ich hatte eine Zeit lang beide ...Sys leer und alles in der Main-Prozedur untergebracht. Da wir aber mehrere Applikationen mit derselben Datenbasis haben, habe ich Die Gemeinsamkeiten aller Main-Prozeduren wieder herausgezogen in in den beiden Prozeduren untergebracht. Als Alternative hätte ich auch eine eigene INIT PROCEDURE schreiben können.

Jede dieser Programmierungsvarianten ist dabei auf keinen Fall unschön oder gar falsch. Es liegt dabei im Ermessen des Programmierers, an welchen Stellen des Programms was geschehen soll. Letztendlich zählt das Ergebnis...

Viele Grüße
Gerd

[Rolf Ramacher]

Hi Manfred,

also ich habe in meiner appsys nur die SET-Befehle drin, die ich immer benötige.

Zur Info auch für Jan. Ich mache dies deshalb bei mir so, weil ich in einer xpj-Datei mehrere exe-Files erzeuge. dann muß ich nur bei der Definition
der exe-datei die appsys.prg mit angeben. Das gleich mache ich mit der dbesys.prg

einmal erzeugt und nur einbinden. Denn sonst machst du die Definition
in jeder main().