STATIC Functions
Moderator: Moderatoren
STATIC Functions
Hallo zusammen,
STATIC Functions sind innerhalb einer Programmdatei sichtbar, soweit klar. Ich moechte eine recht grosse Programmdatei (> 6000 Zeilen) in mehrere kleine zerlegen und die STATIC Functions nun fuer mehrere Dateien sichtbar machen. Der Preprozessor sollte die zerlegte Dateien also zusammenfuehren und daraus ein .obj generieren.
Ist soetwas moeglich ?
Via INCLUDE wuerde gehen, dann funktioniert der automatische Build-Vorgang nicht mehr, da PBUILD Veraenderungen in den INCLUDES nicht der Programmdatei zuordnet, zumindest bei mir nicht.
Achim
STATIC Functions sind innerhalb einer Programmdatei sichtbar, soweit klar. Ich moechte eine recht grosse Programmdatei (> 6000 Zeilen) in mehrere kleine zerlegen und die STATIC Functions nun fuer mehrere Dateien sichtbar machen. Der Preprozessor sollte die zerlegte Dateien also zusammenfuehren und daraus ein .obj generieren.
Ist soetwas moeglich ?
Via INCLUDE wuerde gehen, dann funktioniert der automatische Build-Vorgang nicht mehr, da PBUILD Veraenderungen in den INCLUDES nicht der Programmdatei zuordnet, zumindest bei mir nicht.
Achim
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: STATIC Functions
Hallo, Achim.
Die Doku ist in dieser Hinsicht eindeutig: "Eine STATIC FUNCTION kann nur innerhalb der PRG-Datei aufgerufen werden, in der sie deklariert wurde." Bei einem kaskadierenden Aufruf ist das wiederum kein Problem: Eine andere PRG ruft eine Funktion auf, die eine STATIC FUNCTION innerhalb "ihres" PRG aufruft.
Was ich mich allerdings frage: Du schreibst, der Präprozessor würde die zerlegten Dateien "zusammenführen". Was genau muss ich mir darunter vorstellen?
Die Doku ist in dieser Hinsicht eindeutig: "Eine STATIC FUNCTION kann nur innerhalb der PRG-Datei aufgerufen werden, in der sie deklariert wurde." Bei einem kaskadierenden Aufruf ist das wiederum kein Problem: Eine andere PRG ruft eine Funktion auf, die eine STATIC FUNCTION innerhalb "ihres" PRG aufruft.
Was ich mich allerdings frage: Du schreibst, der Präprozessor würde die zerlegten Dateien "zusammenführen". Was genau muss ich mir darunter vorstellen?
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15689
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: STATIC Functions
Hi,
ich würde die STATIC Functions gegen eine normale Funktion auflösen.
Wer soll sonst noch durchblicken, welche der static functions jetzt genau hier verwendet wird ?
In einer PRG mag das gerade noch angehen, aber wenn du auch noch per include diese in mehrere mischst ...
ich würde die STATIC Functions gegen eine normale Funktion auflösen.
Wer soll sonst noch durchblicken, welche der static functions jetzt genau hier verwendet wird ?
In einer PRG mag das gerade noch angehen, aber wenn du auch noch per include diese in mehrere mischst ...
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: STATIC Functions
Hubert hat insofern recht, wenn es ohnehin nur darum geht, aus mehreren PRGs ein OBJ zu machen (weil hier auch so gut wie keine Ressourcen gespart würden durch STATIC FUNCTIONS). Anders verhielte es sich z.B. bei einem in DLLs aufgesplitteten Projekt.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15689
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: STATIC Functions
Hi,
obwohl ich mir bei den Resourcen nicht wirklich sicher bin ob man da was spart (n-fach in verschiedenen DLLs statt 1 mal im Hauptprogramm oder einer DLL) ging es mir nur um die Sicherheit beim Programmieren.
Mein Programmeditor z.B. springt aus einer aufgerufenen Funktion immer zum Quellcode, solange alle Quellcodes im gleichen Verzeichnis auf der Platte liegen (eventuell auch tiefere ?).
die Static functions unterstützt er nicht, dort kann ich zur Not mit suchen nach function xyz( suchen ... was VX kann weiß ich nicht, aber woher soll der wissen welche der static include functions jetzt die richtige ist. Da muss man ja kirre werden
Und wer es heute nicht glaubt, soll in 10 Jahren versuchen das nochmal zu verstehen
obwohl ich mir bei den Resourcen nicht wirklich sicher bin ob man da was spart (n-fach in verschiedenen DLLs statt 1 mal im Hauptprogramm oder einer DLL) ging es mir nur um die Sicherheit beim Programmieren.
Mein Programmeditor z.B. springt aus einer aufgerufenen Funktion immer zum Quellcode, solange alle Quellcodes im gleichen Verzeichnis auf der Platte liegen (eventuell auch tiefere ?).
die Static functions unterstützt er nicht, dort kann ich zur Not mit suchen nach function xyz( suchen ... was VX kann weiß ich nicht, aber woher soll der wissen welche der static include functions jetzt die richtige ist. Da muss man ja kirre werden
Und wer es heute nicht glaubt, soll in 10 Jahren versuchen das nochmal zu verstehen
Gruß
Hubert
Hubert
Re: STATIC Functions
Hallo zusammen,
>der Präprozessor würde die zerlegten Dateien "zusammenführen". Was genau muss ich mir darunter vorstellen
wenn ich z.B. eine .prg-Datei auf 2 Dateien aufteile und die 2. Datei per INCLUDE in der ersten Datei hinterlege werden die beiden Dateien durch den Preprozessor zu einer logischen Datei zusammengefasst und als ganzes an den Compiler uebergeben. Das funktioniert auch soweit.
PBUILD kennt aber diese Abhaengigkeiten nicht und compiliert erst neu, wenn Datei 1 editiert wurde.
Warum ich das machen moechte ? Ich verwende in allen Modulen meiner Applikation die selben Namen, ein Modul besteht bisher aus einer Datei. Einige Module sprengen aber mittlerweile den Rahmen. Wenn man Functionsnamen Applikationsweit deklariert muss man sich natuerlich Gedanken ueber entsprechende Namenskonventionen machen.
Achim
>der Präprozessor würde die zerlegten Dateien "zusammenführen". Was genau muss ich mir darunter vorstellen
wenn ich z.B. eine .prg-Datei auf 2 Dateien aufteile und die 2. Datei per INCLUDE in der ersten Datei hinterlege werden die beiden Dateien durch den Preprozessor zu einer logischen Datei zusammengefasst und als ganzes an den Compiler uebergeben. Das funktioniert auch soweit.
PBUILD kennt aber diese Abhaengigkeiten nicht und compiliert erst neu, wenn Datei 1 editiert wurde.
Warum ich das machen moechte ? Ich verwende in allen Modulen meiner Applikation die selben Namen, ein Modul besteht bisher aus einer Datei. Einige Module sprengen aber mittlerweile den Rahmen. Wenn man Functionsnamen Applikationsweit deklariert muss man sich natuerlich Gedanken ueber entsprechende Namenskonventionen machen.
Achim
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: STATIC Functions
Hallo, Achim.
Verstehe. Du hast also z.B. ein Modul "ADRESSEN.PRG". Darin gibt es Funktionen wie "LISTENDRUCK", "LOESCHEN" oder "NEUEINGABE" oder ähnliche, und weil es die z.B. auch in "ARTIKEL.PRG" gibt (nur mit anderer Funktionalität), sind sie STATIC, richtig?
Ich halte die Aufteilung per Include-Direktive für den falschen Weg. Ich mache das selbst nur, wenn ich weitgehend unveränderliche Quellcodes einbinden muss, z.B. die Wrapper-Routinen meines Reportgenerators. Da spielt es dann auch keine Rolle, dass PBUILD Änderungen an diesen Dateien nicht "erkennt", weil sie sich eben nicht ändern.
Wenn Du aber so verfahren willst, wäre m.E. wirklich nur eine Umbenennung (ADR_LISTENDRUCK, ADR_LOESCHEN) und eine Umwandlung in nichtstatische Funktionen möglich. Dann könntest Du aber auch gleich ohne Include arbeiten, womit Du auch das Problem des Pbuilders umgangen hättest.
Verstehe. Du hast also z.B. ein Modul "ADRESSEN.PRG". Darin gibt es Funktionen wie "LISTENDRUCK", "LOESCHEN" oder "NEUEINGABE" oder ähnliche, und weil es die z.B. auch in "ARTIKEL.PRG" gibt (nur mit anderer Funktionalität), sind sie STATIC, richtig?
Ich halte die Aufteilung per Include-Direktive für den falschen Weg. Ich mache das selbst nur, wenn ich weitgehend unveränderliche Quellcodes einbinden muss, z.B. die Wrapper-Routinen meines Reportgenerators. Da spielt es dann auch keine Rolle, dass PBUILD Änderungen an diesen Dateien nicht "erkennt", weil sie sich eben nicht ändern.
Wenn Du aber so verfahren willst, wäre m.E. wirklich nur eine Umbenennung (ADR_LISTENDRUCK, ADR_LOESCHEN) und eine Umwandlung in nichtstatische Funktionen möglich. Dann könntest Du aber auch gleich ohne Include arbeiten, womit Du auch das Problem des Pbuilders umgangen hättest.
Herzlich,
Tom
Tom
Re: STATIC Functions
Hallo Tom,
ja, genau so meine ich das.
Das mein Problem nicht sauber zu loesen ist, hatte ich fast befuerchtet. Ich werde zukuenftig wohl ueber entsprechende Namenskonventionen nachdenken muessen.
Achim
ja, genau so meine ich das.
Das mein Problem nicht sauber zu loesen ist, hatte ich fast befuerchtet. Ich werde zukuenftig wohl ueber entsprechende Namenskonventionen nachdenken muessen.
Achim
- brandelh
- Foren-Moderator
- Beiträge: 15689
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: STATIC Functions
Hi,
wie meldet eigentlich das Runtimesystem die Fehlerzeilen nach dem Include ?
Erkennt er das richtig ?
Dass der Compiler geänderte include Dateien nicht erkennt, könnte daran liegen, dass
die projectdatei falsch ist ! Hast du nach der Änderung PBUILD /G aufgerufen ?
Ich meine er stellt die INCLUDE Dateien auch in die Liste der abhängigen Dateien,
allerdings habe ich sowas noch nie probiert
wie meldet eigentlich das Runtimesystem die Fehlerzeilen nach dem Include ?
Erkennt er das richtig ?
Dass der Compiler geänderte include Dateien nicht erkennt, könnte daran liegen, dass
die projectdatei falsch ist ! Hast du nach der Änderung PBUILD /G aufgerufen ?
Ich meine er stellt die INCLUDE Dateien auch in die Liste der abhängigen Dateien,
allerdings habe ich sowas noch nie probiert
Gruß
Hubert
Hubert
- Rolf Ramacher
- Der Entwickler von "Deep Thought"
- Beiträge: 1930
- Registriert: Do, 09. Nov 2006 10:33
- Wohnort: Bergheim
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: STATIC Functions
Hallo Achim,
ich bin mir nicht sicher, ob ich dich jetzt richtig verstanden habe. Du hast einige prg's die du in verschiedene exe-Files benötigst?
Dies habe ich auch. Aber so gelöst. Ich habe diese prg's in ein spezielles Verzeichnis und in den diversenen xpj eingebunden
z,B.
ich bin mir nicht sicher, ob ich dich jetzt richtig verstanden habe. Du hast einige prg's die du in verschiedene exe-Files benötigst?
Dies habe ich auch. Aber so gelöst. Ich habe diese prg's in ein spezielles Verzeichnis und in den diversenen xpj eingebunden
z,B.
Code: Alles auswählen
[..\ArtikelInfo.EXE]
XBTBASE1.LIB
XBTBASE2.LIB
c:\32bit\sammel\APPSYS.PRG
c:\32bit\sammel\Dbesys.prg
- brandelh
- Foren-Moderator
- Beiträge: 15689
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: STATIC Functions
Hi,
nein er hat mehrere PRGs in eine EXE, die teilweise so groß sind, dass er diese in mehrere Teile zerlegen will.
nein er hat mehrere PRGs in eine EXE, die teilweise so groß sind, dass er diese in mehrere Teile zerlegen will.
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: STATIC Functions
Hallo, Rolf.
Genau das will Achim nicht machen, weil das mit den STATIC FUNCTIONs dann ganz sicher nicht mehr funzt.
@Achim: Übrigens funktioniert das bei mir genau so, wie Du es machen willst. Ich habe ein PRG, in dem die Hauptfunktionen sind (im Beispiel nur eine MAIN()) und ein zweites PRG mit einer STATIC FUNCTION, die aus dem ersten aufgerufen werden soll. Es gibt weder einen Compiler-, noch einen Linkerfehler - und das Programm läuft auch. Nur umgekehrt (STATIC im Haupt-PRG und andere Funktionen in den abhängigen) dürfte es nicht gehen, und auch Kreuzverweise müssten in der richtigen Anordnung vorliegen.
Genau das will Achim nicht machen, weil das mit den STATIC FUNCTIONs dann ganz sicher nicht mehr funzt.
@Achim: Übrigens funktioniert das bei mir genau so, wie Du es machen willst. Ich habe ein PRG, in dem die Hauptfunktionen sind (im Beispiel nur eine MAIN()) und ein zweites PRG mit einer STATIC FUNCTION, die aus dem ersten aufgerufen werden soll. Es gibt weder einen Compiler-, noch einen Linkerfehler - und das Programm läuft auch. Nur umgekehrt (STATIC im Haupt-PRG und andere Funktionen in den abhängigen) dürfte es nicht gehen, und auch Kreuzverweise müssten in der richtigen Anordnung vorliegen.
Herzlich,
Tom
Tom
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: STATIC Functions
Mit Code (benutzt allerdings eXpress++) - das hier geht bei mir:
GETTEST.PRG:
GETTES2.PRG:
GETTEST.PRG:
Code: Alles auswählen
#include "dcdialog.ch"
#include "appevent.ch"
#include "gettes2.prg"
#pragma library("\express17\lib\dclipx.lib")
function Appsys()
return NIL
procedure main()
local nWert1 := 10, nWert2 := 10
@ 10, 10 DCSAY _gettest(1) GET nWert1 picture "999.99"
@ 11, 10 DCSAY _gettest(2) GET nWert2 picture "999.99"
DCREAD GUI FIT
RETURN
Code: Alles auswählen
static function _gettest(n)
if n = 1
return "Name"
endif
return "Vorname"
Herzlich,
Tom
Tom
Re: STATIC Functions
Hallu zusammen,
@Hubert:
>wie meldet eigentlich das Runtimesystem die Fehlerzeilen nach dem Include ?
>Erkennt er das richtig ?
habe ich gerade probiert, es wird in der "INCLUDETEN" Datei die richtige Zeilennummer gemeldet.
die Includes werden von PBUILD zwar behandelt, sofern in der AUTO-Section sind werden aber alle Objects neu erzeugt, man muesste eine INCLUDE Datei einer bestimmten .prg-Data zuordnen koennen, diesbezueglich habe ich aber nichts gefunden.
@Tom
klar, funktionieren tut das einwandfrei, es bleibt aber das Problem mit PBUILD
Achim
@Hubert:
>wie meldet eigentlich das Runtimesystem die Fehlerzeilen nach dem Include ?
>Erkennt er das richtig ?
habe ich gerade probiert, es wird in der "INCLUDETEN" Datei die richtige Zeilennummer gemeldet.
die Includes werden von PBUILD zwar behandelt, sofern in der AUTO-Section sind werden aber alle Objects neu erzeugt, man muesste eine INCLUDE Datei einer bestimmten .prg-Data zuordnen koennen, diesbezueglich habe ich aber nichts gefunden.
@Tom
klar, funktionieren tut das einwandfrei, es bleibt aber das Problem mit PBUILD
Achim
Re: STATIC Functions
Hallo zusammen,
Mit folgender .xpj-Datei lassen sich grosse Dateien zerlegen und automatisch kompilieren. Es koennen auch Abhaengigkeiten zwischen einzelnen .ch Dateien und einer bestimmten .prg Datei definiert werden:
=================================================
[NKFV.xpj]
..\NKFV.exe
BU_DI.obj
// Zerlegte Programmdateien
// ----
[BU_DI.obj]
BU_DI.ch
BU_DI.prg
BU_DI_a.ch
BU_DI_b.ch
// Beginn der Programmsection
// ----
[..\NKFV.exe]
...
=================================================
Die Section [BU_DI.obj] handelt die Abhaengigkeiten fuer BU_DI.obj. Wird eine der 4 Dateien editiert erfolgt eine Neukompilierung der BU_DI.prg. In dieser sind die 3 anderen Dateien via INCLUDE integriert.
Einziger Schoenheitsfehler: Die includeten Programmdateien duerfen nicht .prg heissen sondern muessen .ch benannt werden. PRG-Dateien werden grundsaetzlich kompiliert und wuerden zu einem Fehler fuehren, da die aufgeteilten Dateien einzeln nicht compiliert werden koennen.
Achim
Mit folgender .xpj-Datei lassen sich grosse Dateien zerlegen und automatisch kompilieren. Es koennen auch Abhaengigkeiten zwischen einzelnen .ch Dateien und einer bestimmten .prg Datei definiert werden:
=================================================
[NKFV.xpj]
..\NKFV.exe
BU_DI.obj
// Zerlegte Programmdateien
// ----
[BU_DI.obj]
BU_DI.ch
BU_DI.prg
BU_DI_a.ch
BU_DI_b.ch
// Beginn der Programmsection
// ----
[..\NKFV.exe]
...
=================================================
Die Section [BU_DI.obj] handelt die Abhaengigkeiten fuer BU_DI.obj. Wird eine der 4 Dateien editiert erfolgt eine Neukompilierung der BU_DI.prg. In dieser sind die 3 anderen Dateien via INCLUDE integriert.
Einziger Schoenheitsfehler: Die includeten Programmdateien duerfen nicht .prg heissen sondern muessen .ch benannt werden. PRG-Dateien werden grundsaetzlich kompiliert und wuerden zu einem Fehler fuehren, da die aufgeteilten Dateien einzeln nicht compiliert werden koennen.
Achim
- brandelh
- Foren-Moderator
- Beiträge: 15689
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: STATIC Functions
Hi,
wie wäre es der Klarheit halber mit
.CH = nur die Headerdateien von Xbase++
.PRG = wie bisher
.P01 bis .P99 = Aufgeteilte Dateiteile von gleichnamiger PRG (99 sollten reichen oder ?)
#include "xxxx.P01"
#include "xxxx.P02"
...
so kann man die PRGs nicht mit den Teilen verwechseln. Dem INCLUDE ist die Extension bestimmt egal, der OBJ-Sektion bestimmt auch und kompiliert wird ja nur noch die aus allem Erzeugte PPO Datei (PRG+P??) ...
wie wäre es der Klarheit halber mit
.CH = nur die Headerdateien von Xbase++
.PRG = wie bisher
.P01 bis .P99 = Aufgeteilte Dateiteile von gleichnamiger PRG (99 sollten reichen oder ?)
#include "xxxx.P01"
#include "xxxx.P02"
...
so kann man die PRGs nicht mit den Teilen verwechseln. Dem INCLUDE ist die Extension bestimmt egal, der OBJ-Sektion bestimmt auch und kompiliert wird ja nur noch die aus allem Erzeugte PPO Datei (PRG+P??) ...
Gruß
Hubert
Hubert
Re: STATIC Functions
Hallo Hubert,
>Dem INCLUDE ist die Extension bestimmt egal, der OBJ-Sektion bestimmt ....
dem Include ja, PBUILD gibt aber eine Warnung aus:
nkfv.XPJ(32:0) Warning: Unknown suffix BU_DI_a.p01
xpp -q -w /b /dDEBUG @C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\12029398.tmp
Achim
>Dem INCLUDE ist die Extension bestimmt egal, der OBJ-Sektion bestimmt ....
dem Include ja, PBUILD gibt aber eine Warnung aus:
nkfv.XPJ(32:0) Warning: Unknown suffix BU_DI_a.p01
xpp -q -w /b /dDEBUG @C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\12029398.tmp
Achim
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Re: STATIC Functions
beim Suchen bin ich hier drauf gestossen. Nachdem ich in einem größeren Projekt mal eher so aus Neugier die Static Functions in "normale" Functions gewandelt habe, war festzustellen, das Programm wird von mal zu mal größer, je mehr ich umwandel. Also doch Ressourcenverbrauch, wenn man es genau nimmt.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- AUGE_OHR
- Marvin
- Beiträge: 12903
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 44 Mal
Re: STATIC Functions
warum verwendest du include Dateien "zum aufrufen" von PRG ?Statler hat geschrieben:[NKFV.xpj]
..\NKFV.exe
BU_DI.obj
// Zerlegte Programmdateien
// ----
[BU_DI.obj]
BU_DI.ch
BU_DI.prg
BU_DI_a.ch
BU_DI_b.ch
// Beginn der Programmsection
// ----
[..\NKFV.exe]
...
=================================================
Die Section [BU_DI.obj] handelt die Abhaengigkeiten fuer BU_DI.obj. Wird eine der 4 Dateien editiert erfolgt eine Neukompilierung der BU_DI.prg. In dieser sind die 3 anderen Dateien via INCLUDE integriert.
schreib doch, statt der CH, die PRG in dein XPJ und mache dann ein
Code: Alles auswählen
PBUILD xxx.XPJ -G
gruss by OHR
Jimmy
Jimmy
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Re: STATIC Functions
Jimmy,
ich glaube nicht, dass er noch hier liest. Sein letzter Besuch hier im Forum ist 1,5 Jahre her. Ich habe hier nur geantwortet auf Toms und Huberts Aussagen und weil ich keinen neuen Thread eröffnen wollte.
ich glaube nicht, dass er noch hier liest. Sein letzter Besuch hier im Forum ist 1,5 Jahre her. Ich habe hier nur geantwortet auf Toms und Huberts Aussagen und weil ich keinen neuen Thread eröffnen wollte.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!