j-man-devel Mailing List for j-man: Java based SRCP client
Status: Beta
Brought to you by:
andre_schenk
Menu
▾
▴
j-man-devel — Developers and interested users
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(24) |
Jun
(8) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
|
From: André S. <an...@me...> - 2014-09-27 08:54:03
|
Hi Knut, > after changing of SRCP-server's ip-address J-Man starts with the > following error message: > "Es konnte keine Verbindung.... Bitte überprüfen Sie bei den > Einstellungen den angegebenen > Host-Rechner und die angegebene Prot-Nummer." > After closing the message box program ends. There is no chance to > correct the settings. > I didn't found any information or a possibility to change ip-address > outside of J-Man i.e. ini-file, registry or else. look for a file ".jmanrc" in your home directory. I should fix that for the next version. Best regards, André |
|
From: André S. <an...@me...> - 2010-11-13 22:17:13
|
Hallo Andreas, > Das 1. was in dem zip-Paket offenbar fehlt ist schonmal der build.xml > - hab > ich im > http://sourceforge.net/mailarchive/forum.php?forum_name=j-man-svn > dann > gefunden. Ich vermute, Du vermißt das build.xml, weil es im README erwähnt wird. Eigentlich braucht man es aber nicht, wenn man j-man starten will, sondern nur, wenn man es neu bauen will. Dann reicht aber das build.xml allein nicht aus, sondern dann brauchst Du natürlich auch den Sourcecode. Am besten, Du checkst ihn Dir wie auf http://sourceforge.net/projects/j-man/develop beschrieben aus. Ansonsten startest Du das Programm mit ./j-man. Tschüß André |
|
From: Andreas G. <and...@we...> - 2010-11-13 21:15:21
|
Hallo, zusammen! Bin endlich mal wieder dran, an DDL weiterzubasteln: SRCPD build hat wohl geklappt & läuft aus einem SuSE 8.2, jetzt wollte ich an den Client j-man. Das 1. was in dem zip-Paket offenbar fehlt ist schonmal der build.xml - hab ich im http://sourceforge.net/mailarchive/forum.php?forum_name=j-man-svn dann gefunden. ant läuft - aber nicht sehr weit: Bis Buildfile: build.xml checkOS: configure-cpp: [taskdef] Could not load definitions from resource cpptasks.tasks. It could not be found. [typedef] Could not load definitions from resource cpptasks.types. It could not be found. init: BUILD FAILED <UserHOME_geloescht!>/j-man-1.4.0/build.xml:21: <UserHOME_geloescht!>/j-man-1.4.0/catalogs not found. Offenbar fehlt auch der ganze Verzeichnisbaum unter build? Kann das sein oder hab ich was übersehen? Danke schonmal! Andi |
|
From: André S. <an...@me...> - 2009-02-13 14:21:42
|
Hallo Michael, > Ja wie es aussieht, speichert er nur Werte die nicht den Defaultwerten > entsprechen. Das ist doch nett. Wenn ich mal die Zentrale und damit die Busnummer wechseln möchte, dann muß ich nicht erst bei allen Loks die Busnummer ändern. > Ich habe als Defaultwert den Wert genommen, den er aus den > Properties einliest. Das hat wie ich inzwischen gemerkt habe aber auch den > unschönen Seiteneffekt, dass er wenn du in den Properties du den Bus > änderst, er auch dementsprechend diese Änderung für die Loks mit dem > gleichen Bus nachzieht. Dazu habe ich in GenericLoc eine Kleinigkeit geändert, so daß nur bei der Initialisierung die globale Busnummer als Default genommen wird, danach nicht mehr. Es gibt noch andere Stellen im Code, an denen die globale Busnummer benutzt wird. Wenn es an der Stelle um eine Lok geht, dann muß das wohl noch angepaßt werden. Tschüß André |
|
From: Michael <mic...@gm...> - 2009-02-12 12:28:26
|
Hallo, > die JTabel sieht richtig schick aus! Danke. > > [...] Auch wird die Busnummer nun für jede Lok separat > gespeichert und > > kann auch im Edit Formular eingegeben werden. > > Nach einem flüchtigen Blick in die .default.jman habe ich > zwar die UUID entdeckt, nicht aber die Busnummer. Ja wie es aussieht, speichert er nur Werte die nicht den Defaultwerten entsprechen. Ich habe als Defaultwert den Wert genommen, den er aus den Properties einliest. Das hat wie ich inzwischen gemerkt habe aber auch den unschönen Seiteneffekt, dass er wenn du in den Properties du den Bus änderst, er auch dementsprechend diese Änderung für die Loks mit dem gleichen Bus nachzieht. Ich denke das hängt mit den JavaBeans und wie er die Lokdaten speichert und wieder einliest zusammen. Ich habe mich dazu allerdings noch zu wenig mit JavaBeans auseinander gesetzt. Lässt sich aber bestimmt noch ne Lösung finden. Gruß Michael |
|
From: André S. <an...@me...> - 2009-02-11 19:16:15
|
Hallo Michael, die JTabel sieht richtig schick aus! > [...] Auch wird die Busnummer nun für jede Lok > separat gespeichert und kann auch im Edit Formular eingegeben werden. Nach einem flüchtigen Blick in die .default.jman habe ich zwar die UUID entdeckt, nicht aber die Busnummer. > Die auffälligste Änderung ist, das ich die Liste im MainForm durch eine > JTabel ersetzt habe. Diese bietet nun die Möglichkeit wesentlich mehr > Informationen darzustellen. Die einzelnen Spalten sind über ein Popupmenü > der Kopfzeile aus- und einblendbar. Cool! Tschüß André |
|
From: Michael <mic...@gm...> - 2009-02-10 17:40:31
|
Hallo, ich habe meine neuesten Änderungen hochgeladen. Zum einen habe ich als neue ID für Loks eine UUID hinzugefügt. Zum einen brauche ich die für die CRCF Erweiterungen, zum anderen hoffe ich dadurch irgendwann mal die bisherige interne ID ablösen zu können. Auch wird die Busnummer nun für jede Lok separat gespeichert und kann auch im Edit Formular eingegeben werden. Was noch nicht funktioniert ist eine Lok mit gleichem Protokoll und gleicher Adresse auf verschiedenen Bussen, da hier weiterhin noch die interne Id verwendet wird. Für den Goliath Controller bedeutet das, das hier jetzt eine zufällige UUID bei jedem Neustart des Controllers generiert wird und als Bus der aus den Preferences genommen wird, also keinen Unterschied zu bisher. Die wechselnde UUID ist denke ich hinnehmbar, da er eh in keiner Liste geführt wird. Die auffälligste Änderung ist, das ich die Liste im MainForm durch eine JTabel ersetzt habe. Diese bietet nun die Möglichkeit wesentlich mehr Informationen darzustellen. Die einzelnen Spalten sind über ein Popupmenü der Kopfzeile aus- und einblendbar. Was die Darstellung (Breite, per Voreinstellung ausgeblendete Spalten, abspeichern der Darstellung in den Preferences) angeht, so gibt es da denke ich noch Optimierungspotential. In der MainForm.java habe ich in den Zeilen 1283/1284 noch zwei Befehle auskommentiert, die die Darstellung und Sortierung der Tabelle beeinflussen. Diese erfordern allerdings Java 6, ich weiß nicht ob es sich lohnt, deswegen auf Java 6 zu bestehen. Von daher habe ich die Zeilen mal auskommentiert. Meine weiteren Veränderungen bezüglich CRCF werde ich dann in einem extra Branch hoch laden, da diese dann auch die jeweils neueste Version von jsrcpc brauchen. Wenn diese also jemand testen will, muss er auch die aktuellen jsrcpc Dateien runterladen. Bei Anmerkungen oder Kritik, nur zu, ansonsten viele Grüße Michael |
|
From: André S. <an...@me...> - 2009-02-03 17:41:04
|
Hallo Michael, > Meine Intention war, j-man nun um Server und Client Funktionen zu > erweitern, > so dass sich verschiedene Instanzen der Software von einer als Server > arbeitenden j-man Instanz mit Lokstammdaten versorgen lassen. Dabei ist > mir > aufgefallen, dass die Lokliste in j-man ja nur einen Bus unterstützt. Bzw. > diese Einschränkung ist hauptsächlich auf GUI Ebene. Besteht Interesse > dieses zu ändern? Ich würde mich auch anbieten, mich darum zu kümmern. Ich habe Dich gerade als Developer für das j-man-Projekt eingetragen. Viel Spaß! Tschüß André |
|
From: Michael <mic...@gm...> - 2009-02-03 17:22:24
|
Hallo, ich habe ja in drmb unter Message-ID: <Xns...@ne...> einen Thread gestartet zur Übertragung vom Lokstammdaten von einem CRCF Server, vielleicht LOCODB (Loco DataBase) genannt zu anderen Fahrreglern. Dementsprechend habe ich auch die Bibliothek jsrcpc um die Basis-Fähigkeiten erweitert GM und auch CRCF Messages zu versenden. Dabei bin ich dem von Guido schon in spdrs60 angewendeten Vorschlag gefolgt mit dem Syntax CRCF <actor> <actor_id> <method> <attribute> [<attribute_value>]. Als Methoden habe ich GET, LIST, SET und INFO implementiert. Die erweitere Version findet sich dort bereits im CVS. Meine Intention war, j-man nun um Server und Client Funktionen zu erweitern, so dass sich verschiedene Instanzen der Software von einer als Server arbeitenden j-man Instanz mit Lokstammdaten versorgen lassen. Dabei ist mir aufgefallen, dass die Lokliste in j-man ja nur einen Bus unterstützt. Bzw. diese Einschränkung ist hauptsächlich auf GUI Ebene. Besteht Interesse dieses zu ändern? Ich würde mich auch anbieten, mich darum zu kümmern. Was die Entwicklung eines Lok Stammdatenmodells angeht, so werde ich dazu noch einen Vorschlag in drmb posten. Viele Grüße Michael |
|
From: André S. <an...@me...> - 2008-10-16 15:11:15
|
Hallo Paul,
> Könnt ihr mir vielleicht ein paar Tipps für den Anfang geben oder
> beschreiben wie ihr vorgegangen seid?
Die Kommunikation mit dem DDW-Server ("SRCP") ist in einem Jar gekapselt,
das ein eigenes Projekt auf Sourceforge darstellt ("jsrcpc"). Diese
Java-Library nach .NET zu portieren würde Dich wohl ein großes Stück
weiterbringen, wenn das nicht schon jemand gemacht hat. Bei der Suche auf
Sourceforge nach SRCP-Projekten habe ich noch "EnjoyTheTime" und "nsrcp"
gefunden- beide in .NET programmiert.
Tschüß André
|
|
From: <Pau...@we...> - 2008-10-16 14:17:24
|
Hallo zusammen, ich will im Rahmen einer Bachelorarbeit eine Modelleisenbahn mit aktivem RFID orten und daraufhin Weg-Entscheidungen treffen. Dazu verwende ich den DDW-Server und das Delta Control als Booster, also eine direkte Steuerung über den PC. Mein Ziel ist einen Client zu bauen, der mit DDW kommunizieren kann und eine .NET Schnittstelle zur RFID-Software darstellt. Wegen der .NET-Schnittstelle programmiere ich in C#. Da mir Java bislang am vertrautesten ist, würde ich mich gerne an eurem Client orientieren. Könnt ihr mir vielleicht ein paar Tipps für den Anfang geben oder beschreiben wie ihr vorgegangen seid? Ebenfalls sehr nützlich wäre, wenn ich mir eure Klassen nennen könntet die für die Kommunikation zum Server bzw. für die einfachen Steuerbefehle von Weichen und Zügen zuständig sind. Da ihr euren Quellcode nicht so wirklich dokumentiert ist, finde ich mich darin leider nur schwer zurecht. Ihr wärt mir eine sehr große Hilfe! Vielen Dank im Voraus!!! Freundliche Grüße Paul Haug |
|
From: <an...@me...> - 2008-01-12 22:11:08
|
Hallo Guido, nachdem ich heute viel Zeit hatte, habe ich alle Punkte Deiner untenstehenden Liste abgearbeitet. Danke nochmal f=FCr die vielen Tips! Tsch=FC=DF Andr=E9 > Hallo Andr=E9, > > mittlerweile habe ich mit den Inhalt der SVN-Ablage heruntergeladen und > erste Erfahrungen gesammelt. Ich m=F6chte die hier mal kurz zusammenfasse= n > und damit gleich Anregungen f=FCr Verbesserungen geben. M=F6glicherweise > hilft das auch schon Nachahmern, wenn die auf die gleichen Hindernisse > sto=DFen. > > Einleitend sei erw=E4hnt, dass ich mit =BBant=AB bisher keine n=E4heren > Erfahrungen gemacht habe und mir das bisher nur als eine Art > =BBmake-Ersatz=AB f=FCr Java-Programme bekannt ist. Ich habe daher zun=E4= chst > nur kurz in die Man-Page geschaut, und entdeckt, dass es bei einem > Aufruf automatisch nach einder Datei =BBbuild.xml=AB sucht und diese > abarbeitet. > > Ein erster Aufruf von > > ant -v > > im Basisverzeichnis bescherte mir dann einen Haufen Fehlermeldungen, die > offenbar von einem installierten GNU-Java-Compiler (gjc) herr=FChrten. Da > ich > den sonst auch nicht ben=F6tige, habe ich das Paket kurzerhand > deinstalliert und es nochmal mit dem sun-java-1.5 probiert. Damit gab es > dann keine Fehlermeldungen mehr. Festzustellen ist also, dass der gjc > ungeeignet ist; eine Hinweis darauf w=E4re also eventuell hilfreich. > > In dem Basisverzeichnis gibt es eine Skript mit namen =BBj-man=AB, mit de= m > man wohl das fertig kompilierte Programm starten soll. Ein Aufruf von > > ./j-man > > brachte dann folgenden Fehler: > > ./j-man: 18: /bin/java: not found > > Ein Blick in das Skript erbrachte, dass man offenbar noch eine > Umgebungsvariable JAVA_HOME setzen mu=DF, damit die Java Virtual Machine > gefunden wird. So etwas sollte man heute eigentlich keinem Benutzer mehr > zumuten und sollte anders gel=F6st werden. > > Ein > > which java > > zeigte als Ausgabe > > /usr/bin/java > > so dass der n=E4chste Versuch mit > > JAVA_HOME=3D/usr ./j-man > > starten konnte. Das Ergebnis war folgender Fehler: > > Exception in thread "main" java.lang.UnsatisfiedLinkError: no > gameport_GameportHandler in java.library.path > > Es gab also ein Problem mit dem =BBGameportHandler=AB-Modul. Meine Vermut= ung > war direkt, dass der zugeh=F6rige Quellcode wohl noch nicht kompiliert > worden war. Ich habe dann die =BBbuild.xml=AB ausgiebiger untersucht und = bin > zu dem Schlu=DF gekommen, dass das Target =BBcompile-jni=AB daf=FCr > verantwortlich zeichnen sollte. > > Ein > > ant compile-jni > > lief erfolgreich durch und ein anschlie=DFendes > > JAVA_HOME=3D/usr ./j-man > > startete dann tats=E4chlich auch das Programm. Man kann aber wohl auch > durch > > ant j-man > > das Bauen und Starten des Programms mit _einem_ Aufruf erledigen. Wenn > ich die =BBbuild.xml=AB-Datei richtig interpretiere, dann gibt es _kein_ > Target mit dem man im Sine eines herk=F6mmlichen =BBmake=AB-Aufrufs das > Programm soweit kompilieren kann, dass es lauff=E4hig ist. F=FCr mein > Verst=E4ndnis sollte das =BBDefault-Taget=AB so etwas leisten. Das w=E4re= dann > noch nachzubessern. > > Kommen wir zum laufenden Programm. Beim ersten Starten bekam ich direkt > eine weitere Fehlermeldung entgegengehalten: > > java.io.FileNotFoundException: /home/guido/.jmanrc (No such file or > directory) > > Hier wird also das Nichtfinden der Datei f=FCr die pers=F6nlichen > Voreinstellungen nicht richtig abgefangen. Das Programm sollte sich da > anders verhalten: > > Suche ~./jmanrc > -> nicht gefunden: Nehme Voreinstellungen > -> gefunden: Lese Einstellungen > -> Fehler beim Lesen: Passende Fehlermeldung > > Auf meinem Rechner l=E4uft zum Testen ein srcpd mit Loopback-Device. Dies= en > hat j-man offenbar direkt zu kontaktieren versucht und mir folgende > weitere Fehlermeldung entgegengehalten: > > de.dermoba.srcp.common.exception.SRCPUnsupportedDeviceGroupException: > no such device group on bus > > Leider kann man diesem Meldungstext nicht entnehmen, worum es jetzt > genau geht. Das w=E4re dann eine Unzul=E4nglichkeit, die man in der > SRCP-Bibliothek von Kurt Harders nachbessern sollte. > > Ich halte es aber auch f=FCr besser, wenn j-man den SRCP-Server nicht > unaufgefordert kontaktieren w=FCrde, sondern erst nach Aktivierung einer > Benutzereinstellung: > > [ ] Beim Programmstart automatisch mit SRCP-Server verbinden > > Das h=E4tte auch den Vorteil, dass der Benutzer zun=E4chst Gelegenheit > bekommt, die richtigen Einstellungen f=FCr den SRCP-Server einzugeben. > > > Im Dialogfenster f=FCr die Benutzereinstellungen selbst, sind mir auf die > Schnelle folgende Dinge aufgefallen: > > 1) Die Voreinstellung f=FCr den SRCP-Bus ist =BB0=AB. Das macht keinen Si= nn > und sollte auf =BB1=AB ge=E4ndert werden. > > 2) Es ist nicht unmittelbar verst=E4ndlich, was folgendes bedeutet: > > autom. MDC starten > autom. LC starten > autom. FC starten > > > 3) Die Handhabung der Lokdaten-Datei =BBjman.data=AB sollte komplett ande= rs > gel=F6st werden (analog zu den Gleisbilddateien in spdrs60): > > * Es sollte eine Benutzereinstellung geben: > [ ] Lokdatendatei beim Programmstart automatisch laden > Zus=E4tzlich eine Eingabem=F6glichkeit f=FCr die zu ladende Datei. > > * Das Speicherformat der jman.data ist bin=E4r und damit nicht UNIXoid= ; > es sollte ein les- und editierbares Textformat sein. Au=DFerdem habe > ich schon mal Inkompatibilit=E4ten zwischen verschiedenen Java-VMs > gehabt; in Dateien =BBgestreamte=AB Objekte waren zwischen den > verschiedenen Java-Versionen nicht austauschbar. > > * Im Hinblick auf die MIME-Konventionen sollte das neue Dateiformat > eine eindeutige Dateierweiterung bekommen (z.B. *.jmdf - J-man > -Data-File), die es erm=F6glicht mehrere Loklisten vorr=E4tig zu > halten. > > > Das soll dann heute erstmal genug sein. Es gibt aber sicher noch mehr > Anregungen. > > Gru=DF > Guido > > -- > http://www.bayernline.de/~gscholz/ > http://www.lug-burghausen.org/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > J-man-devel mailing list > J-m...@li... > https://lists.sourceforge.net/lists/listinfo/j-man-devel |
|
From: <an...@me...> - 2008-01-08 20:46:02
|
Hallo Guido, > ja, m=FC=DFte so passen. Fein, dann checke ich das in den n=E4chsten Tagen ein. >> [java] "INIT 2 POWER " failed: no such device group on bus > ^ hier ist allerdings noch ein Leerzeichen zu > viel. Das habe ich auch schon gesehen. Kurt hat es sich da ein bi=DFchen einfach gemacht und immer ein Leerzeichen ans Ende eines SRCP-Requests angeh=E4ngt = - falls noch mehr Parameter angef=FCgt werden m=FCssen. Das zu =E4ndern ist e= in bi=DFchen m=FChsam, unde den srcpd scheint es nicht zu st=F6ren. ;-) Tsch=FC=DF Andr=E9 |
|
From: Guido S. <gui...@ba...> - 2008-01-08 18:40:35
|
Am Tue, 08. Jan 2008 um 13:29:31 +0100 schrieb Andr=E9 Schenk:
> Hallo Guido,
Hallo Andr=E9,
> Da Kurt mich vor kurzem als Entwickler f=FCr das jsrcpc-Projekt eingetrag=
en
> hat, konnte ich Deinen Wunsch nun umsetzen. Ist es so ok?
ja, m=FC=DFte so passen.
> [java] "INIT 2 POWER " failed: no such device group on bus
^ hier ist allerdings noch ein Leerzeichen zu
viel.
Gru=DF
Guido
--=20
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
|
|
From: <an...@me...> - 2008-01-08 12:31:16
|
Hallo Guido,
> Auf meinem Rechner l=E4uft zum Testen ein srcpd mit Loopback-Device. Dies=
en
> hat j-man offenbar direkt zu kontaktieren versucht und mir folgende
> weitere Fehlermeldung entgegengehalten:
>
> de.dermoba.srcp.common.exception.SRCPUnsupportedDeviceGroupException:
> no such device group on bus
>
> Leider kann man diesem Meldungstext nicht entnehmen, worum es jetzt
> genau geht. Das w=E4re dann eine Unzul=E4nglichkeit, die man in der
> SRCP-Bibliothek von Kurt Harders nachbessern sollte.
Da Kurt mich vor kurzem als Entwickler f=FCr das jsrcpc-Projekt eingetragen
hat, konnte ich Deinen Wunsch nun umsetzen. Ist es so ok?
[java] "INIT 2 POWER " failed: no such device group on bus
[java] at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[java] at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcce=
ssorImpl.java:39)
[...]
Tsch=FC=DF Andr=E9
|
|
From: <an...@me...> - 2007-08-13 20:07:09
|
Hallo Guido, >> Wie k=F6nnte die ganze Datei hei=DFen? Sie enth=E4lt im Moment Lokdaten = und >> Fahrstra=DFen. jmanData.jman klingt auch komisch... > genaugenommen stellt sich diese Frage garnicht (d.h. im augenblicklichen > Zustand des Programms nat=FCrlich schon). Ich hatte an anderer Stelle > schon mal beschrieben, wie das Programm mit Datendateien umgehen > sollte: > 1) Das Programm startet und liest die pers=F6nlichen Einstellungen. > 2) Ist in den pers. Einstellungen aktiviert, dass eine Datendatei > (beliebigen Namens) beim Programmstart automatisch geladen werden > soll, dann wird diese geladen. Andernfalls nat=FCrlich nicht und der > Benutzer bekommt nur ein leeres Fenster zu Gesicht. > 3) Der Benutzer mit oder ohne leeres Fenster kann jeder Zeit =FCber > =BBDatei/=D6ffnen=AB eine vorhandene Datendatei laden. Der Filter f=FC= r > dieses Fenster steht dann auf =BB*.jman=AB. > 4) Ebenso kann der Benutzer mit =BBDatei/Neu=AB jederzeit eine neue > Datendatei anlegen. > Was zur Zeit noch fehlt, ist die Logik, die beim Hantieren mit > Datendateien verfolgt, ob die aktuell ge=F6ffnete ver=E4ndert wurde oder > nicht und ob sie schon einen Namen hat. Damit verbunden fehlen die > =FCblichen Abfragen wie =BBDer Inhalt der Datei "blalba.jman" wurde > ver=E4ndert. Wollen Sie die =C4nderungen sichern?=AB usw. usw. Genauso habe ich es jetzt gemacht. Danke f=FCr die tollen Tips! > Was ebenfalls nicht gut gel=F6st ist, ist die Datenhaltung der > SRCP-Sitzung. Diese geh=F6rt nicht in eine jman-Instanz, sondern in eine > MainFrame-Instanz, denn dort wird sie kontrolliert. Das nehme ich mir als n=E4chstes vor, sobald ich wieder Zeit habe. Tsch=FC=DF Andr=E9 |
|
From: Guido S. <gui...@ba...> - 2007-06-26 17:35:53
|
Am Mon, 25. Jun 2007 um 23:35:05 +0200 schrieb André Schenk: > Hallo Guido, Hallo André, > >> jman.data heißt jetzt per Default jmanData.xml. Ist das ok so? > > Nein, denn die Dateikennung sollte systemweit eindeutig für ein Programm > > sein. ».xml« ist da fast so unspezifisch wie ».data«. Was wäre mit > > ».jman«? > Wie könnte die ganze Datei heißen? Sie enthält im Moment Lokdaten und > Fahrstraßen. jmanData.jman klingt auch komisch... genaugenommen stellt sich diese Frage garnicht (d.h. im augenblicklichen Zustand des Programms natürlich schon). Ich hatte an anderer Stelle schon mal beschrieben, wie das Programm mit Datendateien umgehen sollte: 1) Das Programm startet und liest die persönlichen Einstellungen. 2) Ist in den pers. Einstellungen aktiviert, dass eine Datendatei (beliebigen Namens) beim Programmstart automatisch geladen werden soll, dann wird diese geladen. Andernfalls natürlich nicht und der Benutzer bekommt nur ein leeres Fenster zu Gesicht. 3) Der Benutzer mit oder ohne leeres Fenster kann jeder Zeit über »Datei/Öffnen« eine vorhandene Datendatei laden. Der Filter für dieses Fenster steht dann auf »*.jman«. 4) Ebenso kann der Benutzer mit »Datei/Neu« jederzeit eine neue Datendatei anlegen. Was zur Zeit noch fehlt, ist die Logik, die beim Hantieren mit Datendateien verfolgt, ob die aktuell geöffnete verändert wurde oder nicht und ob sie schon einen Namen hat. Damit verbunden fehlen die üblichen Abfragen wie »Der Inhalt der Datei "blalba.jman" wurde verändert. Wollen Sie die Änderungen sichern?« usw. usw. Was ebenfalls nicht gut gelöst ist, ist die Datenhaltung der SRCP-Sitzung. Diese gehört nicht in eine jman-Instanz, sondern in eine MainFrame-Instanz, denn dort wird sie kontrolliert. Wenn das mal umgesetzt ist, dann könnte man das Programm z.B. mit mehreren Datendateien über die Kommnadozeile starten: j-man datei1.jman datei2.jman datei3.jman Der Benutzer bekäme dann drei Fenster mit unterschiedlichen Lok- usw. -listen. Jedes Fenster kann eine eigene SRCP-Sitzung managen und im Prinzip jeweils einen eigenen SRCP-Server ansteuern, wenn man die Serverdaten auch noch in der Datendatei unterbringt. So ist es auch in spdrs60 gelöst. Gruß Guido -- http://www.bayernline.de/~gscholz/ http://www.lug-burghausen.org/ |
|
From: <an...@me...> - 2007-06-25 21:35:26
|
Hallo Guido, > Die rc-Datei sollte im Property-File-Format gehalten sein. Das hat eine > sauberen, gut lesbaren und ebeso editierbaren Aufbau: Einverstanden. Java-Properties k=F6nnen wahlweise im "Schl=FCssel=3DWert"-F= ormat oder in XML gelesen und gespeichert werden, ist nur eine Frage, welche Methode man aufruft. Ich habe das eben umgestellt. > Au=DFerdem hat es einen einfachen Mechanismus, mit dem man Voreinstellung= en > handhaben kann. Ich hatte das vor l=E4ngere Zeit mal bei JTrain > nachger=FCstet, vielleicht schaust Du mal in dessen Quellcode. Wow, noch ein Java-Tool! Wenn ich das richtig sehe, verwendest Du in CControlCenter.saveSettings () auch Properties.store (). Da sind wie also einer Meinung. :-) > Das Datendateiformat kann man einfach so lassen, wie es ist. Hier gibt > es keinen Handlungsbedarf. xml w=E4re hier nur =BBHype=AB, zudem verlangs= amt > es das Lesen und Schreiben der Dateien erheblich. Ein Editieren per Hand > ist dann auch kaum mehr vern=FCnftig m=F6glich. Ich bin kein Verfechter der "verwende immer und =FCberall XML"-Theorie, abe= r f=FCr das Speichern der Lokdaten eignet sich Serialisierung sehr gut. Java bietet dazu 2 M=F6glichkeiten: a) Serialisierung in eine Bin=E4rdatei, wie es mit .jmanrc bisher gemacht wurde; Nachteil: nicht portabel b) Serialisierung in eine XML-Datei Beides bekommt man mit dem JRE geschenkt. Der Weg, ein eigenes Format zur Serialisierung zu benutzen, war deshalb unn=F6tig. Da=DF es nun XML ist - m= ein Gott, mu=DF man ja nicht so genau hinsehen. ;-) Damit kann man aber mit einem Methodenaufruf ganze Objektb=E4ume speichern und sp=E4ter wieder lade= n, ohne sich beim Programmieren einen abbrechen zu m=FCssen. >> jman.data hei=DFt jetzt per Default jmanData.xml. Ist das ok so? > Nein, denn die Dateikennung sollte systemweit eindeutig f=FCr ein Program= m > sein. =BB.xml=AB ist da fast so unspezifisch wie =BB.data=AB. Was w=E4re = mit > =BB.jman=AB? Wie k=F6nnte die ganze Datei hei=DFen? Sie enth=E4lt im Moment Lokdaten und Fahrstra=DFen. jmanData.jman klingt auch komisch... >> Nachdem .jmanrc human readable ist, sieht man erst, was da alles >> unn=F6tigerweise gepeichert wird. > Ja, vor allem ist der Inhalt _nicht_ portabel zwischen verschiedenen > Betriebssystemen. Die Datenhaltung der Benutzereinstellungen m=FC=DFte no= ch > gr=FCndlich =FCberarbeitet werden. Ideal ist ein eingenes Property-File > daf=FCr. Ich habe inzwischen einen Filter beim Speichern der Properties eingebaut, so da=DF .jmanrc nur noch jman-Properties enth=E4lt. Tsch=FC=DF Andr=E9 |
|
From: Guido S. <gui...@ba...> - 2007-06-25 14:01:53
|
Am Sat, 23. Jun 2007 um 18:09:47 +0200 schrieb André Schenk: > Hallo Guido, Hallo André, > ich hatte mal wieder ein bißchen Zeit für j-man. Die Daten in .jmanrc und > jman.data werden jetzt als XML gespeichert. Für .jmanrc habe ich einen > Fallback dringelassen, so daß auch das alte Format noch gelesen werden > kann. Also ehrlich gesagt, halte ich xml für Konfigurationsdateien als vollkommen ungeeignet. xml macht nur Sinn als genormtes Austauschformat zwischen verschiedenen Programmen oder für ein Dateiformat, bei dem der Nettoinhalt wesentlich größer ist, als das Tara. Die rc-Datei sollte im Property-File-Format gehalten sein. Das hat eine sauberen, gut lesbaren und ebeso editierbaren Aufbau: Schlüssel=Wert Außerdem hat es einen einfachen Mechanismus, mit dem man Voreinstellungen handhaben kann. Ich hatte das vor längere Zeit mal bei JTrain nachgerüstet, vielleicht schaust Du mal in dessen Quellcode. Das Datendateiformat kann man einfach so lassen, wie es ist. Hier gibt es keinen Handlungsbedarf. xml wäre hier nur »Hype«, zudem verlangsamt es das Lesen und Schreiben der Dateien erheblich. Ein Editieren per Hand ist dann auch kaum mehr vernünftig möglich. > jman.data heißt jetzt per Default jmanData.xml. Ist das ok so? Nein, denn die Dateikennung sollte systemweit eindeutig für ein Programm sein. ».xml« ist da fast so unspezifisch wie ».data«. Was wäre mit ».jman«? > Nachdem .jmanrc human readable ist, sieht man erst, was da alles > unnötigerweise gepeichert wird. Ja, vor allem ist der Inhalt _nicht_ portabel zwischen verschiedenen Betriebssystemen. Die Datenhaltung der Benutzereinstellungen müßte noch gründlich überarbeitet werden. Ideal ist ein eingenes Property-File dafür. Gruß Guido -- http://www.bayernline.de/~gscholz/ http://www.lug-burghausen.org/ |
|
From: <an...@me...> - 2007-06-23 16:11:51
|
Hallo Guido, ich hatte mal wieder ein bi=DFchen Zeit f=FCr j-man. Die Daten in .jmanrc u= nd jman.data werden jetzt als XML gespeichert. F=FCr .jmanrc habe ich einen Fallback dringelassen, so da=DF auch das alte Format noch gelesen werden kann. jman.data hei=DFt jetzt per Default jmanData.xml. Ist das ok so? Nachdem .jmanrc human readable ist, sieht man erst, was da alles unn=F6tigerweise gepeichert wird. Tsch=FC=DF Andr=E9 |
|
From: <an...@me...> - 2007-06-14 12:51:04
|
Hallo Guido, > F=FCr eine gr=F6=DFere Anlage sicher eher zu umst=E4ndlich, als > Demonstrationsprojekt aber recht nett. Es fehlt noch ein Schalter zum > konfigurieren der SRCP-Daten ;-). Vielleicht gibt es eine Properties-Datei? ;-) Nein, Du hast schon recht. Aber den Schalter brauche ich selbst ja nicht und bevor ich das Tool anderen gebe, m=FC=DFte ich erstmal den Autor des Applets um Erlaubnis fragen. Tsch=FC=DF Andr=E9 |
|
From: Guido S. <gui...@ba...> - 2007-06-13 16:57:11
|
Am Wed, 13. Jun 2007 um 09:59:05 +0200 schrieb André Schenk: > Hallo Guido, Hallo André, > Ich habe nun endlich Zeit gefunden, mich um den Lokalisierungsfehler zu > kümmern. Es lag an einem falsch kodierten Umlaut in der deutschen > Lokalisierungsdatei. Jetzt sollte es wieder funktionieren. ja, paßt wieder. Danke. Gruß Guido -- http://www.bayernline.de/~gscholz/ http://www.lug-burghausen.org/ |
|
From: Guido S. <gui...@ba...> - 2007-06-13 16:40:51
|
Am Thu, 31. May 2007 um 22:22:30 +0200 schrieb André Schenk: > Hallo Guido, Hallo André, > Kennst Du diese Seite? > http://www-users.rwth-aachen.de/christoph.schmitz2/hpsignal.html nein, kannte ich noch nicht. Die Applets zum Stellen der Signalbilder sind sehr schön gemacht. Ich habe mir gestern auch die sehr aufwändige Dokumentation zum Umbau der ICE-Strecke Köln-Düren angesehen. An der Strecke habe ich (im nicht umbebauten Zustand) ein paar Jare gewohnt. > Ich habe mir das Applet von dort heruntergeladen, in eine Java-Applikation > umgewandelt und um SRCP-Funktionen erweitert. Damit habe ich ein > wunderbares Tool, um mein "Signal" zu steuern (s. Screenshot). Für eine größere Anlage sicher eher zu umständlich, als Demonstrationsprojekt aber recht nett. Es fehlt noch ein Schalter zum konfigurieren der SRCP-Daten ;-). Gruß Guido -- http://www.bayernline.de/~gscholz/ http://www.lug-burghausen.org/ |
|
From: <an...@me...> - 2007-06-13 08:01:23
|
Hallo Guido, > seit ein paar Tagen habe ich Probleme mit der Spracheinstellung. Ich > bekomme die Oberfl=E4che immer nur in Englisch zu sehen. Ich habe ein > anderes Java-Projekt auf der Festplatte, bei dem das immer noch > ordnungsgem=E4=DF funktioniert. Ich habe nun endlich Zeit gefunden, mich um den Lokalisierungsfehler zu k=FCmmern. Es lag an einem falsch kodierten Umlaut in der deutschen Lokalisierungsdatei. Jetzt sollte es wieder funktionieren. Tsch=FC=DF Andr=E9 |
|
From: <an...@me...> - 2007-05-31 20:31:14
|
Hallo Guido, > Wurde ein Port seit der Initialisierung noch nicht ver=E4ndert, hat er de= n > Zeitstempel 0.0. Ver=E4nderte Ports zeigen den Zeitpunkt der letzten > Ver=E4nderung (wenn ich das richtig verstanden habe). Ja, genauso ist es! Kennst Du diese Seite? http://www-users.rwth-aachen.de/christoph.schmitz2/hpsignal.html Ich habe mir das Applet von dort heruntergeladen, in eine Java-Applikation umgewandelt und um SRCP-Funktionen erweitert. Damit habe ich ein wunderbares Tool, um mein "Signal" zu steuern (s. Screenshot). Tsch=FC=DF Andr=E9 |
2 messages has been excluded from this view by a project administrator.
