Xbase++ Programm auf Server - Ermitteln Prozess [ERLEDIGT]
Moderator: Moderatoren
- Wolfgang_B
- Rekursionen-Architekt
- Beiträge: 484
- Registriert: Do, 14. Jun 2007 18:22
- Wohnort: 94065 Waldkirchen
- Hat sich bedankt: 14 Mal
- Danksagung erhalten: 5 Mal
Xbase++ Programm auf Server - Ermitteln Prozess [ERLEDIGT]
Hallo Kollegen,
ich habe ein Xbase++ Programm auf einem WIN-Server installiert. Auf diesen greifen jetzt verschiedene Clients zu. Da ich auf diesen Server nur per Fernwartung zugreifen kann, möchte ich vor einer Änderung von Tabellen sicherstellen, daß keine Instanz des Programms mehr auf einem Client läuft. Hat jemand eine Ahnung, wie ich feststellen kann, daß nur noch meine Fernwartungsinstanz läuft, bzw. wie ich die anderen Instanzen zwangsweise beenden kann.
Gruß
Wolfgang
ich habe ein Xbase++ Programm auf einem WIN-Server installiert. Auf diesen greifen jetzt verschiedene Clients zu. Da ich auf diesen Server nur per Fernwartung zugreifen kann, möchte ich vor einer Änderung von Tabellen sicherstellen, daß keine Instanz des Programms mehr auf einem Client läuft. Hat jemand eine Ahnung, wie ich feststellen kann, daß nur noch meine Fernwartungsinstanz läuft, bzw. wie ich die anderen Instanzen zwangsweise beenden kann.
Gruß
Wolfgang
Zuletzt geändert von Wolfgang_B am Mo, 06. Mai 2013 9:26, insgesamt 1-mal geändert.
Beste Grüße
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
- Manfred
- Foren-Administrator
- Beiträge: 21186
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Ich lege für die Programme eine eindeutige temp Datei an (schreibgeschützt und stets offen). Anhand derer kann ich sehen, wer wann und wo geöffnet hat. Weiterhin prüft in dem Fall das Programm ob es eine weitere Temp Datei "ähnlichen Namens" existiert (lege ich manuell an wenn benötigt.) und beendet dann nach einem Zeitintervall sich selbst. Sicherlich nur eine einfache Lösung, aber....
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!!
- Wolfgang_B
- Rekursionen-Architekt
- Beiträge: 484
- Registriert: Do, 14. Jun 2007 18:22
- Wohnort: 94065 Waldkirchen
- Hat sich bedankt: 14 Mal
- Danksagung erhalten: 5 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Hallo Manfred, guter Tipp. ich schreibe ja sowieso jedes Login und Logout in eine Protokolltabelle. Da kann ich ja sehen, wer sich noch nicht ausgeloggt hat. Problem ist nur, wenn das Programm irgendwo abgestürzt ist, dann hab ich natürlich kein Logout. Das wäre meine nächste Frage. Ich kann mit Laufzeitfehlern nicht umgehen. Wie fange ich einen Laufzeitfehler in der Weise ab, daß zumindest noch ein Eintrag in meine Logtabelle geschrieben wird?
Hast Du noch einen Vorschlag, wie man noch laufende Instanzen auf irgendeinem Client von der Ferne abschießen kann?
Gruß Wolfgang
Hast Du noch einen Vorschlag, wie man noch laufende Instanzen auf irgendeinem Client von der Ferne abschießen kann?
Gruß Wolfgang
Beste Grüße
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Wolfgang,
Du kannst das in die errorsys schreiben. Problem: Bei einem xppfatal läuft die nicht durch. Und wenn Du nicht aufpasst, dann macht die errorsys mehr Probleme als Dir lieb ist. Aber ich habe selber schon mal sowas gemacht, indem ich die errorsys in eine dbf geschrieben habe. Das funktioniert gut.
Der Weg von Manfred zum abschießen ist, daß das Programm regelmäßig nachsieht, ob die externe Datei existiert. Gibts die, schließt sich das geordnet. Den Intervall kann man sich dann selber einstellen. man könnte das auch erweitern, das man eine zweite Datei mit einem Text anlegt. Und der wird dann angezeigt ("Bitte zu 13:00 Uhr das Programm beenden"). Wer das dann nicht macht, bei dem greift die 1. Datei mit der rigorosen Methode.
Jan
Du kannst das in die errorsys schreiben. Problem: Bei einem xppfatal läuft die nicht durch. Und wenn Du nicht aufpasst, dann macht die errorsys mehr Probleme als Dir lieb ist. Aber ich habe selber schon mal sowas gemacht, indem ich die errorsys in eine dbf geschrieben habe. Das funktioniert gut.
Der Weg von Manfred zum abschießen ist, daß das Programm regelmäßig nachsieht, ob die externe Datei existiert. Gibts die, schließt sich das geordnet. Den Intervall kann man sich dann selber einstellen. man könnte das auch erweitern, das man eine zweite Datei mit einem Text anlegt. Und der wird dann angezeigt ("Bitte zu 13:00 Uhr das Programm beenden"). Wer das dann nicht macht, bei dem greift die 1. Datei mit der rigorosen Methode.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9358
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Hallo, Wolfgang.
Wie auch immer. Du kannst die ERRORSYS.PRG manipulieren bzw. anpassen, also in ihr auch Code hinterlegen, der die Logtabelle aktualisiert - vorausgesetzt, das Problem, das gerade aufgetreten ist, betrifft sie nicht direkt (etwa falsche Pfadeinstellungen, Rechtefehler o.ä.).
Ansonsten gibt es ein einfache Mittel, um solche Logtabellen halbwegs aktuell zu halten: Indem sie beispielsweise (in einem gesonderten Thread) offengehalten und auch gesperrt werden; mindestens das Record-Locking geht kurz nach einem Absturz verloren. Etwas eleganter ist es, die Logdatei (wiederum in einem Thread) etwa halbminütlich zu aktualisieren. Jemand, von dem eine Aktualisierung fehlt, ist sehr wahrscheinlich auch nicht mehr im Programm. Ergänzt um die Pflege der Logs in der Fehlerbehandlungsroutine hat man bereits ein recht verlässliches System, das nur bei Abschüssen via Taskmanager oder fatalen Fehlern nicht mehr ganz gültige Daten liefern würde.
Ein Laufzeitfehler, der (noch) dazu führt, dass das Fehlersystem aufgerufen wird, bedeutet letztlich, dass die Software eigentlich noch läuft. Theoretisch kann man Laufzeitfehler bis zu einem gewissen Grad auch völllig ignorieren, aber man hätte dann eine nicht sehr verlässliche Software.Wie fange ich einen Laufzeitfehler in der Weise ab, daß zumindest noch ein Eintrag in meine Logtabelle geschrieben wird?
Wie auch immer. Du kannst die ERRORSYS.PRG manipulieren bzw. anpassen, also in ihr auch Code hinterlegen, der die Logtabelle aktualisiert - vorausgesetzt, das Problem, das gerade aufgetreten ist, betrifft sie nicht direkt (etwa falsche Pfadeinstellungen, Rechtefehler o.ä.).
Ansonsten gibt es ein einfache Mittel, um solche Logtabellen halbwegs aktuell zu halten: Indem sie beispielsweise (in einem gesonderten Thread) offengehalten und auch gesperrt werden; mindestens das Record-Locking geht kurz nach einem Absturz verloren. Etwas eleganter ist es, die Logdatei (wiederum in einem Thread) etwa halbminütlich zu aktualisieren. Jemand, von dem eine Aktualisierung fehlt, ist sehr wahrscheinlich auch nicht mehr im Programm. Ergänzt um die Pflege der Logs in der Fehlerbehandlungsroutine hat man bereits ein recht verlässliches System, das nur bei Abschüssen via Taskmanager oder fatalen Fehlern nicht mehr ganz gültige Daten liefern würde.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Hi,
ich habe teilweise in meinen Programmen einen eigenen Thread (XbpCRT mit offenen Dateien), der in regelmäßigen Zeitabständen nach einer Datei sucht.
Bei denen die nur ab und zu die Dateien öffnen, erfolgt die Prüfung auf if Admin_Sperre_Aktiv() vor dem Öffnen der Dateien ( also vor Suchdialog, Daten laden oder nach speichern ).
Falls diese gefunden wird, erfolgt entweder ein Hinweis, dass z.B. in 10 Minuten das Programm beendet wird (also sie sollen speichern) oder wenn möglich (keine Dateien offen ...) nur ein kurzer Hinweis und das Programm wird gleich geschlossen. Kommt auf die Dringlichkeit an
Außerdem ist in der Main eine Prüfung auf diese Datei damit die EXE nicht neu gestartet werden kann.
Wenn es nur auf einem Server läuft, musst du halt wissen, ob du einfach abschalten kannst (bzw. die Anwendung sich selbst beenden läßt) oder die Anwender warnen musst.
ich habe teilweise in meinen Programmen einen eigenen Thread (XbpCRT mit offenen Dateien), der in regelmäßigen Zeitabständen nach einer Datei sucht.
Bei denen die nur ab und zu die Dateien öffnen, erfolgt die Prüfung auf if Admin_Sperre_Aktiv() vor dem Öffnen der Dateien ( also vor Suchdialog, Daten laden oder nach speichern ).
Falls diese gefunden wird, erfolgt entweder ein Hinweis, dass z.B. in 10 Minuten das Programm beendet wird (also sie sollen speichern) oder wenn möglich (keine Dateien offen ...) nur ein kurzer Hinweis und das Programm wird gleich geschlossen. Kommt auf die Dringlichkeit an
Außerdem ist in der Main eine Prüfung auf diese Datei damit die EXE nicht neu gestartet werden kann.
Code: Alles auswählen
PROCEDURE Main ( uTest )
... hier muss das Datenverzeichnis ermittelt werden !
#ifndef DEBUG
if ! IsAdminSperre(.t.) // dies ist ein XbpCRT Programm !
SetTimerEvent( 6000 , {|| IsAdminSperre() } ) // jede Minute testen 60sec * 100 da 1/100
endif
#endif
...
if Admin_Sperre_Aktiv() // dies ist ein GUI Programm, das Dateien nur kurz öffnet
InfoBox("Wegen Systemwartung muß das Programm beendet werden."+CRLF+CRLF+"Bei Fragen bitte an ... wenden.")
AppQuit(.t.)
endif
...
*------------------------------------------------------------- Admin_Sperre_Aktiv() -----------------
function Admin_Sperre_Aktiv()
if ! file(DatenVerzeichnis()+"\XYZ_STOP.*") // XYZ ist für jedes Programm anders.
memowrit(DatenVerzeichnis()+"\XYZ_STOP.NEIN",;
"Wenn diese Datei auf XYZ_STOP.JA umbenannt wird, stopt das Programm !")
endif
return file(DatenVerzeichnis()+"\XYZ_STOP.JA")
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozess
auf dem Server (welche Version?) kannst du doch in der "Verwaltung" unter "freigegebene Ordner" und "geöffnete" Datei "sehen" was los ist.wasi01 hat geschrieben:Hat jemand eine Ahnung, wie ich feststellen kann, daß nur noch meine Fernwartungsinstanz läuft, bzw. wie ich die anderen Instanzen zwangsweise beenden kann.
du kannst, mit entsprechenden Rechten, den Zugriff "terminieren" ... wie die Daten dann aussehen ist eine andere Sache ( deine Application )
wenn du was mit den Clients "vom Server" aus machen willst müsstest du Zugriff auf die Clients haben. da fällt mir nur WMI ein.
bei solchen "externen" Eingriffen muss deine Application darauf reagieren wenn du z.b. mit WM_QUIT arbeitest.
du musst also deine Application so "präparieren" das sie auf "irgendwas reagiert".
in einem Thread könnte man jede Minute versuchen eine DBF im share Mode zu öffnen und gleich wieder schliessen.
Wenn du "die" DBF mit "original" DBU EXCLUSIVE öffnest können die Clients die nicht mehr öffnen ...
gruss by OHR
Jimmy
Jimmy
- Wolfgang_B
- Rekursionen-Architekt
- Beiträge: 484
- Registriert: Do, 14. Jun 2007 18:22
- Wohnort: 94065 Waldkirchen
- Hat sich bedankt: 14 Mal
- Danksagung erhalten: 5 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozess
der Vorschlag von Hubert ist glaub ich für mich am einfachsten. So ein Statement kann man einfach vor eine Suche hängen und einen entsprechenden Hinweis anzeigen. Mit Threats muß ich mich erst mal intensiver berfassen.
Das Problem ist aber eher das, daß ich nachts ein Programmupdate machen will, aber irgend ein Client hat das Programm noch laufen, sodaß ich die Programmdatei nicht überschreiben kann. Eine Möglichkeit wäre natürlich, auf jedem Client z.B. Teamviewer zu installieren, dann käme man ja an die Clients dran. Ist aber nicht überall zu verargumentieren ...
Noch eine Frage zur ERRORSYS.PRG. Wenn ich die ins Programm mit einbinde, wird die bei jedem Laufzeitfehler aufgerufen oder muß ich da noch was drumrum programmieren?
Aber schon mal Danke für Eure Kommentare!!
Gruß Wolfgang
Das Problem ist aber eher das, daß ich nachts ein Programmupdate machen will, aber irgend ein Client hat das Programm noch laufen, sodaß ich die Programmdatei nicht überschreiben kann. Eine Möglichkeit wäre natürlich, auf jedem Client z.B. Teamviewer zu installieren, dann käme man ja an die Clients dran. Ist aber nicht überall zu verargumentieren ...
Noch eine Frage zur ERRORSYS.PRG. Wenn ich die ins Programm mit einbinde, wird die bei jedem Laufzeitfehler aufgerufen oder muß ich da noch was drumrum programmieren?
Aber schon mal Danke für Eure Kommentare!!
Gruß Wolfgang
Beste Grüße
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Ich habe das so gelöst, dass ich immer mehrere Exe habe: Programm1.exe,Programm2.exe,Programm3.exe.wasi01 hat geschrieben:...Das Problem ist aber eher das, daß ich nachts ein Programmupdate machen will, aber irgend ein Client hat das Programm noch laufen, sodaß ich die Programmdatei nicht überschreiben kann...
Die Anwender starten dann immer ein Programm.exe, welches die einzige Aufgabe hat zu prüfen, welches der Programm1.exe, Programm2.exe, etc. das neueste Datum hat. Dieses wird dann durch Programm.exe gestartet.
So kann ich jederzeit die Exe -auch im laufenden Betrieb- austauschen.
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Hallo Wolfgang,
wenn Du die errorsys einbindest, wird immer die genommen statt der Standardversion. Der Quellcode der Standardversion liegt ebenfalls in Deiner Installation. Nimm die, kopiere sie in Dein Entwicklungsverzeichnis, und modifiziere sie. Dann hast Du einen guten Start.
Jan
wenn Du die errorsys einbindest, wird immer die genommen statt der Standardversion. Der Quellcode der Standardversion liegt ebenfalls in Deiner Installation. Nimm die, kopiere sie in Dein Entwicklungsverzeichnis, und modifiziere sie. Dann hast Du einen guten Start.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozess
einfache Anleitung zur Integration:
Die Vorgabe PRG zu den anderen PRG Dateien kopieren
...\XPPW32\source\SYS\ErrorSys.prg
Die Projektdatei anpassen:
PBUILD /G aufrufen um die Abhängigkeiten aufzulösen.
Die Vorgabe PRG zu den anderen PRG Dateien kopieren
...\XPPW32\source\SYS\ErrorSys.prg
Die Projektdatei anpassen:
Code: Alles auswählen
[xxx.EXE]
... am Besten am Ende anhängen
ERRORSYS.PRG
Gruß
Hubert
Hubert
- Wolfgang_B
- Rekursionen-Architekt
- Beiträge: 484
- Registriert: Do, 14. Jun 2007 18:22
- Wohnort: 94065 Waldkirchen
- Hat sich bedankt: 14 Mal
- Danksagung erhalten: 5 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Danke für die Tipps, muß ich jetzt der Reihe nach mal ausprobieren.
Viele Grüße
Wolfgang
Viele Grüße
Wolfgang
Beste Grüße
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Angenommen du willst, dass die Software automatisch um 21:00 beendet wird und es ist eine GUI Anwendung (mit einem Thread), dann wäre das der einfachste Weg:
In der Eventloop():
So könnte man ein Wartungsfenster freihalten.
In der Eventloop():
Code: Alles auswählen
nEvent := xbe_None
DO WHILE nEvent <> xbeP_Close // Ereignis xbeP_Close ab
nEvent := AppEvent( @mp1, @mp2, @oXbp )
if seconds() > 75600 .or. < seconds() < 18000 // Ende um 21 * 3600 + 00 * 60 , kein Start vor 5 * 3600
quit()
endif
oXbp:handleEvent( nEvent, mp1, mp2 )
ENDDO
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozess
klar kann man das "so" manchen und "Hard-coden" , aber warum nicht den 4th Parameter von AppEvent() nutzen ?brandelh hat geschrieben:In der Eventloop():Code: Alles auswählen
nEvent := AppEvent( @mp1, @mp2, @oXbp ) if seconds() > 75600 .or. < seconds() < 18000 // Ende um 21 * 3600 + 00 * 60 , kein Start vor 5 * 3600
gerade wenn ein User "nichts tut" benötigst du ein "Timeout" damit deine Application was macht sonst wird die Abfrage nie erreicht.
auf das gemeinsame "Daten" Verzeichniss haben die Clients "auf dem Server" ja Zugriff.
Wenn ich also "auf dem Server" arbeite kann ich die "SERVICE.DBF" Exclusiv öffnen
und damit den Client "mitteilen" das die beim "timeout" die Anwendung verlassen sollen.
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Mit dem 4. Parameter hast du natürlich recht, ohne wird sonst die Funktion AppEvent() bei "Ruhe" nicht beendet und somit das Programm am Leben gelassen ...
Gruß
Hubert
Hubert
- Wolfgang_B
- Rekursionen-Architekt
- Beiträge: 484
- Registriert: Do, 14. Jun 2007 18:22
- Wohnort: 94065 Waldkirchen
- Hat sich bedankt: 14 Mal
- Danksagung erhalten: 5 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Hallo,
ich hab mit dem 4. Parameter mal experimentiert. Mit mäßigem Erfolg. Mal beendet sich das Programm, mal nicht ... Mir ist nicht ganz klar geworden, wie ich nach der Zeit <TimeOut> * 0.01 lt. Handbauch das Programm beenden kann. Wenn noch ein Fenster z.B. für eine Eingabe offen ist, ist doch eine zweite Eventschleife aktiv?! Wahrscheinlich habe ich auch die Eventschleife noch nicht verstanden.
Bitte nicht lachen
Gruß Wolfgang
ich hab mit dem 4. Parameter mal experimentiert. Mit mäßigem Erfolg. Mal beendet sich das Programm, mal nicht ... Mir ist nicht ganz klar geworden, wie ich nach der Zeit <TimeOut> * 0.01 lt. Handbauch das Programm beenden kann. Wenn noch ein Fenster z.B. für eine Eingabe offen ist, ist doch eine zweite Eventschleife aktiv?! Wahrscheinlich habe ich auch die Eventschleife noch nicht verstanden.
Bitte nicht lachen
Code: Alles auswählen
DO WHILE .T.
nEvent := AppEvent( @mp1, @mp2, @oXbp, 1000 )
IF nEvent = 0
AppQuit()
ENDIF
oXbp:handleEvent( nEvent, mp1, mp2 )
ENDDO
Zuletzt geändert von Jan am Fr, 08. Feb 2013 14:20, insgesamt 1-mal geändert.
Grund: Code formatiert anzeigen lassen
Grund: Code formatiert anzeigen lassen
Beste Grüße
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozess
wasi01 hat geschrieben:ich hab mit dem 4. Parameter mal experimentiert...
du musst also, wenn du den 4th Parameter verwendest, als erstes denWird für <nTimeOut> ein Wert größer als 0 angegeben, gibt die Funktion spätestens nach Ablauf dieses Zeitintervalls einen Ereigniscode zurück. Falls innerhalb dieser Zeitspanne kein Ereignis eingetreten ist, wird xbe_None zurückgegeben und alle per Referenz übergebenen Parameter haben den Wert NIL.
Code: Alles auswählen
DO WHILE !lExit
nEvent := AppEvent( @mp1, @mp2, @oXbp, nTimeout)
DO CASE
CASE nEvent = xbe_None
// Aktion bei "kein Ereigniss"
CASE nEvent = xbeP_Quit
...
gruss by OHR
Jimmy
Jimmy
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2121
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 72 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Geile Idee! =D>UliTs hat geschrieben:Ich habe das so gelöst, dass ich immer mehrere Exe habe: Programm1.exe,Programm2.exe,Programm3.exe.
Die Anwender starten dann immer ein Programm.exe, welches die einzige Aufgabe hat zu prüfen, welches der Programm1.exe, Programm2.exe, etc. das neueste Datum hat. Dieses wird dann durch Programm.exe gestartet.
So kann ich jederzeit die Exe -auch im laufenden Betrieb- austauschen.Uli
Bleibt nur noch das Problem der DLL-Updates.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozess
Du kannst zusätzlich ein oder mehrere Unterverzeichnisse anlegen, in denen die Exe mit zugehörigen DLLs liegen.Werner_Bayern hat geschrieben:Bleibt nur noch das Problem der DLL-Updates.
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2121
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 72 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozes [ERLEDIG
Danke.
Im Hinblick auf PDR 6289 hab ich mich für die lokale Version entschieden. Programm wird wie bisher vom Netzlaufwerk gestartet, schaut, ob es lokal läuft, wenn nicht, kopiert es sich selbst und alle DLLs lokal und startet sich von dort. Damit ist die Update-Problematik auch erschlagen, weil die App auf dem Netzlaufwerk nie wirklich in Benutzung sein und der PDR mit den XPPFATAL-Abstürzen nicht mehr auftreten dürfte.
Im Hinblick auf PDR 6289 hab ich mich für die lokale Version entschieden. Programm wird wie bisher vom Netzlaufwerk gestartet, schaut, ob es lokal läuft, wenn nicht, kopiert es sich selbst und alle DLLs lokal und startet sich von dort. Damit ist die Update-Problematik auch erschlagen, weil die App auf dem Netzlaufwerk nie wirklich in Benutzung sein und der PDR mit den XPPFATAL-Abstürzen nicht mehr auftreten dürfte.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozes [ERLEDIG
DLL-Update ... hatten wir schon
1. aktuelle DLL umbenennen, das geht auch bei offenen und da jedes laufende Programm über den (unveränderten) handle zugreift, geht das.
2. neue DLL installieren
3. beim nächsten Programmstart wird die neue gestartet.
1. aktuelle DLL umbenennen, das geht auch bei offenen und da jedes laufende Programm über den (unveränderten) handle zugreift, geht das.
2. neue DLL installieren
3. beim nächsten Programmstart wird die neue gestartet.
Gruß
Hubert
Hubert
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2121
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 72 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozes [ERLEDIG
Danke Hubert, das war mir neu.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozes [ERLEDIG
Ich habe vor Jahren einen "Internetupdate" für eines meiner Programme geschrieben, da muss man das so machen
Gruß
Hubert
Hubert
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2121
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 72 Mal
Re: Xbase++ Programm auf Server - Ermitteln Prozes [ERLEDIG
Hätte es gerade probiert, aber eine DLL, die auf einem 2008er Server in Benutzung ist, lässt sich nicht umbennen.
Die Aktion kann nicht abgeschlossen werden, da die Datei in einem anderen Programm geöffnet ist.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9358
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Xbase++ Programm auf Server - Ermitteln Prozes [ERLEDIG
Nicht ganz ungefährlich ist diese Vorgehensweise auch, wenn DLLs dynamisch geladen und/oder wieder entladen werden, oder wenn DLLs einander aufrufen, was bei komplexen Tools wie Reportgeneratoren, aber auch Zusatzprodukten wie eXpress++ der Fall sein kann. Aus diesem Grund werden bei uns die Namen aller ausführbaren Dateien in dieser Updatevariante mit einem vorangestellten Unterstrich "_" versehen. Beim Programmstart - bevor also irgendwas über die Standards hinaus geladen wird - prüfen wir, ob solche Dateien vorliegen, benennen dann um (alte Versionen bekommen "$" als Präfix), löschen im Erfolgsfall die alten Dateien und starten das Programm neu. Windows macht das mit seinen eigenen Updates übrigens ganz ähnlich.
Herzlich,
Tom
Tom