XProfan

- Seite 1 -

Gehe zu Zeile... ist jetzt implementiert, gibts aber erst beim nächsten Update.

11.06.2005 ▲

Meine Frage: Sollt ich die bisherigen Projekt-Dateien unterstützen und lediglich erweitern oder etwas eigenes Entwickeln. Beides hat Vor- und Nachteile, deswegen ist Eure Meinung hierzu wichtig!

Bisherige Projekt-Dateien unterstützen ist am einfachsten zu integrieren, ich würde die Datei lediglich um ein paar Optionen wie: CPP2Profan, FileList usw. erweitern.

Eigene Projektverwaltung würde bedeuten, das alle Einstellungen in einer zentralen Datenbank gespeichert werden, und somit autom. zur Verfügung stehen. Extra Projekt-Dateien können entfallen.

Zahlreiche Antworten erwünscht, damit ich möglichst bald eine Entscheidung treffen kann. Gänzlich neue Vorschlage könnt Ihr natürlich auch machen!

Gruß
Thomas

17.06.2005 ▲

Michael
Wodrich

Da bin ich für die zentrale Projektverwaltung.
Damit sollte es dann möglich sein, alle Projekte im Auge zu behalten.

Ich stelle mir vor, daß das Umschalten zwischen verschiedenen Projekten dann einfacher wird.

Bitte nicht vergessen: Jedes Projekt kann in einer anderen Profan-Version laufen. Die Runtime muß also auf jeden Fall wählbar sein. Gut wäre es auch, wenn Sie nachträglich verstellbar ist.
Denn es gibt sicher Situationen, wo man ein Projekt auf eine neue Version umstellen möchte.

Wenn alles in einer Datei steht, kann man dann auch einen Editiermodus mit einbauen? Runtime-Pfad und Fileliste nicht nur per Dateiwahl-Dialog sondern schnell mal von Hand editiert?

MfG
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

[quote:e3bc3d1b12=Michael Wodrich]Bitte nicht vergessen: Jedes Projekt kann in einer anderen Profan-Version laufen. Die Runtime muß also auf jeden Fall wählbar sein.[/quote:e3bc3d1b12]Das wird sie. Ich bastele gerade an einen eigenen integrierten Linker, so das die Runtime auch bei älteren Profan² Versionen anzugeben ist.[quote:e3bc3d1b12=Michael Wodrich] Gut wäre es auch, wenn Sie nachträglich verstellbar ist. Denn es gibt sicher Situationen, wo man ein Projekt auf eine neue Version umstellen möchte.
[/quote:e3bc3d1b12]Sobald eine Datei als Tab aktiviert wird, werden die zuletzt verwendeten Optionen voreingestellt. Jede Veränderung wird sofort in die Datenbank übertragen. Also Datei aktivieren und auf Kompilieren klicken. Nur wenn Du was ändern möchtest rufst Du die Compiler-Optionen auf.[quote:e3bc3d1b12=Michael Wodrich]
Wenn alles in einer Datei steht, kann man dann auch einen Editiermodus mit einbauen? Runtime-Pfad und Fileliste nicht nur per Dateiwahl-Dialog sondern schnell mal von Hand editiert?[/quote:e3bc3d1b12]
Ist aber Fehlerträchtig. Wenn der Wunsch noch öfters geäußert wird, werde ich es Optional einrichten. Die Filelist ist dann sowieso unabhängig von der Datenbank. Also Filelist oder Datei öffnen, alles weitere wird aus der Datenbank gelesen.

Ich will nochmal kurz die Unterschiede zwischen Datenbank und Projektdatei erklären.
Bei Projektdatei wird im Ordner des Sources eine Zusatzdatei mit den Compiler-Optionen erstellt. Also MeinSource.prf und dazu automatisch generiert MeinSource.prf.co
Lädt man MeinSource, egal wie, wird vorm kompilieren nachgesehen, ob die co-Datei vorhanden ist und dessen Einstellungen werden vorgegeben.
Vorteil: Man kann den Source zusammen mit dieser Datei verschieben, es ist eine einfach editierbare Textdatei.
Nachteil: Es entsteht zu den meisten Sources eine kleine Zusatztextdatei.

Bei der Datenbank-Alternative, wird z.B. eine DBase-Datei mit einer Tabelle verwaltet. Die Einstellungen werden anhand des Dateinamens incl. Pfad ermittelt.
Vorteil: zusätzliche Textdateien im Source-Ordner entfallen.
Nachteil: Werden Sources verschoben sind alle Einstellungen futsch, die Datenbank muß ab und zu aktualisiert werden, um nicht mehr existierende Source zu entfernen und die Editierbarkeit ist nicht so ohne weiteres gegeben.

Rolf
Koch

Hi Thomas,

ich persönlich tendiere zu der Projektdatei. Man verschiebt ja öfters mal ein Ordner u.s.w.

Rolf

Michael
Wodrich

Stimmt, so gesehen ist die Projektdatei im Vorteil.

Und wie wäre es wenn alles auf Projektdatei basiert, aber diese Projektdateien in eine Datenbank importiert, dort editiert und bei Bedarf wieder exportiert werden können? Dann kann man die Pfade selbst anpassen.

Beispiel: Es wird ein Projekt gesichert (z.B. gezippt). Später wird dieses Projekt in einem anderen Verzeichnis entpackt.

MfG
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

- Seite 2 -

Michael
Wodrich

Wird der Editor automatisch geänderte Sources auf der Platte erkennen können?

Beispiel: Ein PlugIn verändert den Source, der sich gerade im Editor befindet und speichert ihn in die Datei. Der Editor sollte das nach dem PlugIn-Aufruf testen und darauf hinweisen.

Möglichkeit:
Die Datei wurde verändert. Sollen die geänderten Daten neu eingelesen werden?
Wenn der Editor-Inhalt nicht geändert wurde (z.B. vor PlugIn-Aufruf wurde gespeichert), dann sollte der Inhalt gleich ohne Nachfrage eingelesen werden.

MfG
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

Im moment sehe ich es so, da ich erstmal nur Compiler-Optionen zu jeder *.prf Datei speichern werde. Diese werden beim laden gleich mit erfasst und beim speichern aktualisiert. Ausserdem werde ich vorher noch ein doppeltes Laden derselben Datei verhindern, wobei dies nur für die jeweilige Editor-Instanz gilt. Wer den Editor mehrmals öffnet muß dann schon selber ein bissel aufpassen.
Ausserdem halte ich es für Sinnvoll vorm Interpretieren (Ausnahme Schnellstart), Kompilieren oder Aufruf eines Plugins alle benannten und modifizierten Dateien zu speichern. Hat den Vorteil, eine *.inc anzupassen und dann die *.prf starten zu können usw.

@Michael:
Nein, wird hoffentlich auch nicht nötig sein. Eine Anweisung zum Neuladen des Sources werde ich später mal integrieren. Ansonsten geht es jetzt schon, durch geschickte SendString-Anweisungen, was aber wirklich nur eine Notlösung bleiben soll. Die Plugin-Unit sorgt ja für einen gesicherten Shared-Memory, den der Editor zur Zeit nur aktualisiert, später wird er dort auch selber Daten abfragen, die vom Plugin kommen. Identifizierung von Editor-Instanz zum Plugin passiert über eine GUID, so das Verwechslungen eigentlich ausgeschlossen werden können.
Im Moment bin ich ja noch bei den Vorarbeiten, so das noch Vorschläge erwünscht sind.
Nebenbei um Irrtümern vorzubeugen: Die Projektdatei wird keine Infos zu dazugehörigen Dateien enthalten, da dies auch völlig unnötig ist. Um alle Dateien eines Projekts zu laden, dafür sind die Filelists geeignet. Ansonsten genügt ja ein Doppelclick auf die *.inc oder sonstwas im Editor und diese wird sofort geöffnet

ASKTEC

Hallo Thomas...

der Editor sieht sehr vielversprechend aus...

Gefällt mir gut...

Hier noch eine kleine Bitte für die Optionen: Ermögliche bitte eine Pfadangabe, für das öffnen und speichern der Projekte... Damit man voreinstellen kann, wo man seine Projekte gespeichert hat und beim öffnen nicht immer die gesamte Platte durchforsten muss...

Desweiteren wäre es Klasse, wenn man später auch eine eigene Schrift für den Editor einstellen könnte...

Ansonsten freue ich mich schon auf die zukünftigen Versionen

Gruß

Andreas

Profan 7.6 / XProfan 8 / XProfan 9 ~ W2k Prof. / Win XP Prof. ~ AMD XP2000+ / P4 3.80 GHz

21.06.2005 ▲

>> Pfadangabe, für das öffnen und speichern der Projekte
Ist auf jedenfall eine praktische Sache und wird kommen

>> eine eigene Schrift für den Editor einstellen könnte
Ist geplant. Ob die Schrift dann On-The-Fly aktualisiert wird kann ich noch nicht sagen. Die Syntax-Farben und Attribute werden auch austauschbar sein.
Da die Unterscheidung von Befehl und Function sowieso etwas ungenau ist, kann es sein das ich diese in eine Gruppe packe und als 3 Highlightfarbe eine Benutzerdefinierte Liste einlese. Da kann man entweder XPSE Erweiterungen oder InlineASM hervorheben lassen. Hab leider nur 3 Wortlisten in diesem Lexxer zur Verfügung.

21.06.2005 ▲

@Andreas
Bis es soweit ist, speichere doch einfach die FileList unter Eigene Dateien ab. Die sorgt dafür, das alle benötigten Dateien geladen werden, unabhängig davon wo sie sich befinden. Außerdem kann man diese auch Doppelklicken

21.06.2005 ▲