XProfan

Michael
Wodrich

Wie fängst Du den Fehler ab, das nicht genug ins Env hineinpaßte und dann kommentarlos abgeschnitten wurde...

Für einfache Übergaben ist es schon schön, aber leider gibt es zu viele Huuuuch, wieso daaaas dennnn.

Da gelten immer noch einige Grenzen aus Uralt-DOS-Zeiten. Das das Env nach dem Programmaufruf entsorgt wird ist im Plugin-Fall eher vorteilhaft.

Sehr viele für und wider bei dieser Art der Übergabe. Aber eine einheitliche Plugin-Schnittstelle brauchen wir wirklich.

Schöne Grüße
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

RGH

Environment-Variablen halte ich für keine gute Idee. In meinen AUgen sind sie ein Relikt aus DOS-Zeiten. Der Platz ist beschränkt und man weiß nie, ob auf dem aktuellen Rechner noch Platz im Environment vorhanden ist.

Ich habe geplant, das Benutzermenu zu erweitern, so dass dann Kommandozeilenparameter übergeben werden können und es wird dann Tags geben, die z.B. für den aktuellen Dateinamen, die aktuelle Zeilennummer, das aktuelle Wort, etc. gelten sollen. Außerdem soll es ein Flag geben, daß XProfed veranlaßt, nach dem Aufruf des externen Programmes (Plugins) die Datei neu zu laden, etwa wenn sie durch das Programm verändert wurde.

Aber das werde ich sicher erst nach der endgültigen Version XProfan 10 mit XProfed 1.0 für XProfan 10 angehen können ... ansonsten wird XProfan 10 nie fertig. ;)

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Pipe-Unit ^^ also FileMapping.

[quote:f5c7607e98=RGH]Environment-Variablen halte ich für keine gute Idee. In meinen AUgen sind sie ein Relikt aus DOS-Zeiten. Der Platz ist beschränkt und man weiß nie, ob auf dem aktuellen Rechner noch Platz im Environment vorhanden ist.
[/quote:f5c7607e98]Das gilt doch nicht für lokale Environmentvariablen, diese unterstützen sogar UNICODE, wenn mann möchte. Environmentvaraiblen die im Editor gesetzt werden haben ja auch nur Gültigkeit in Anwendungen die dieser startet. Ich glaube hier gibts ein Mißverständnis. Jedenfalls unter Windows ab 2000 sind mir solche Einschränkungen nicht bekannt.
[quote:f5c7607e98=RGH]
Ich habe geplant, das Benutzermenu zu erweitern, so dass dann Kommandozeilenparameter übergeben werden können und es wird dann Tags geben, die z.B. für den aktuellen Dateinamen, die aktuelle Zeilennummer, das aktuelle Wort, etc. gelten sollen. Außerdem soll es ein Flag geben, daß XProfed veranlaßt, nach dem Aufruf des externen Programmes (Plugins) die Datei neu zu laden, etwa wenn sie durch das Programm verändert wurde.

Aber das werde ich sicher erst nach der endgültigen Version XProfan 10 mit XProfed 1.0 für XProfan 10 angehen können ... ansonsten wird XProfan 10 nie fertig. ;)

Gruß
Roland[/quote:f5c7607e98]
Die Lösung sollte auch für die meisten Dinge reichen, war auch nur ein Vorschlag, weils leichter zu händeln ist

// Nachtrag: Obiges Beispiel ist so ausführbar, nur den ersten Source zur test.exe compilieren. Dann sollte man sehen, das weder der Environment des Systems, noch der des Users benutzt wird, sondern nur der innerhalb des Processes (XProEd), sowie der Processe die diese startet. Aber egal, warum einfach wenns auch anders geht

RGH

ich denke die Geschichte mit den Übergabeparametern hat den Vorteil, daß eben auch nicht speziell dafür geschriebene externe Programme eingebunden werden können, etwa z.B. mein BeyondCompare, um die aktuelle Datei mit der letzten Sicherungskopie zu vergleichen, oder meinen Windowscommander mit dem aktuellen Verzeichnis aufzurufen, oder die aktuelle Datei mit einem speziellen Editor aufzurufen, oder die aktuell bearbeitete XPGL-Datei im XPGL-Viewer zu betrachten, .......

Etwas anderes wäre eine Pluginschnittstelle, um Zusatztools zu integrieren, die einmal geladen dann nicht mehr extra aufgerufen werden, sondern im Hintergrund ihren Dienst tun, so wie z.B. ein alternativer Lexer, ein automatischer Code-Verschönerer, etc. Aber das wird dann eher etwas komplexer ...

Aber wie gesagt: Laßt uns erstmal XProfan 10 auf dem Weg bringen.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Habs mal mit dem bisherigen Benutzermenü getestet, funktioniert ohne jegliche Code-Änderung. Nur im Editor sind die entsprechenden Variablen zu setzen. Umsetzung sollte also in relativ kurzer Zeit möglich sein. Die andere Möglichkeit kann ja später zusätzlich eingebaut werden.

Am Lösungsvorschlag von iF stört mich, das man entweder die pipe.pcu benutzen muß, bzw. dieses Filemapping selbst hinzufügen muß, was ja nicht ganz so einfach für jeden ist.

Nuja stimmt schon, dennoch bietet die Unit viele Vorteile besonders im Bezug darauf das die Programmteile bidirektional miteinander kommunizieren können ohne sich um das Aufrechterhalten einer Verbindung kümmern zu müssen. Den Source der Unit kann ich ja bei Roland hinterlegen - zudem da nix sensationell oder geheim ist.

Ich kann ja mal - wenn Interesse besteht - ein Beispiel hierfür posten.

RGH

[quote:4fef0e8c6d=TS-Soft]Nur im Editor sind die entsprechenden Variablen zu setzen. Umsetzung sollte also in relativ kurzer Zeit möglich sein.[/quote:4fef0e8c6d]
Ok, überzeugt! ;)

In der nächsten Version ist es drin. In der Kommandozeile gibt es folgende Variablen:
Kompilieren Markieren Separieren

!
:D = Kompletter Dateiname mit Pfad
:P = Pfad ohne Dateiname (mit  am Ende)
:N = Dateiname (mit Endung, aber ohne Pfad)
:E = Dateiendung ohne Punkt
:? = Wert wird per Inpubox abgefragt *
:! = Aktuelle Datei wird vorher gespeichert und nach Beedigung des
Programmes erneut geladen **
*  Wenn man als Kommando ein schlichtes ":?" eingibt, hat man quasi
eine Kommandozeile im Benutzermenü
** Das ":!" kann irgendwo im Kommando stehen. Es wird vorm
Ausführen einfach entfernt und dient nur als Flag.

Mit folgendem Kommando würde also Windows Notepad mit der aktuellen Datei geladen werden:
Kompilieren Markieren Separieren

!
notepad exe ":D" :!

Die Anführungszeichen stehen hier, damit es auch mit Leer- und Sonderzeichen im Pfad klappt.
Notepad wird mit der aktuellen Datei, die zuvor gespeichert wird, gestartet. Dann kann man im Notepad die Datei verändern und speichern. Nach dem Beenden von Notepad kann man die veränderte Datei im Profed weiterbearbeiten. (Notepad muß natürlich erst beendet werden, sonst gehts im Profed nicht weiter. Ohne :! geht es nach dem Starten des Kommandos natürlich sofort weiter.)

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Die Lösung von Roland sollte auf jedenfall mal umgesetzt werden, vor allem auch für Fremdtools.

Die Lösung per FileMapping hatte ich für XPrfEdit (also alte Version) ja auch benutzt. Jetzt kommts eigentlich mehr drauf an, werden die Featers dieser Unit benötigt und kann jeder damit Umgehen?

Mit Environmentvariablen ist die Umsetzung die einfachste, jeder Profaner kommt mit GetEnv$ klar, bzw. sollte es

In XProfEd gesetzte Umgebungsvariablen werden auf jedenfall an das Benutzermenü weitervererbt, und auch an die von dort aufgerufenen Tools. Ohne jeglich Änderung, habs extra getestet.

Eine alternative zu Rolands Vorschlag sollte auf jedenfall implementiert werden, weil diese Tools dann auch wesentlich einfacher zu Konfigurieren sind, für den NUR Nutzer.

Einigen sollten wir uns schon irgendwie, will die Addons nicht nur für mich schreiben

// Nachtrag: Hat sich mit Rolands-Posting überschnitten

Aktuell interessieren würde mich das aktuelle Wort unter dem Cursor, möchte nämlich den H2Viewer als Hilfe aufrufen, also Plattform SDK kontextsensitiv, arbeite nunmal viel mit API

Richtig - und in diesem Zusammenhang auch die Selektierung, wobei es hier reichen würde zwei Longs zu übergeben, start -> ende.

Schliesslich will man vielleicht nicht immer ein PlugIn auf den kompletten Source, sondern nur auf einen Teil anwenden.

Und um es komplett zu machen auch die Zeilennummer, und die Cursorposition XY.