Keyboard-Handler in Freepascal unt FreeVision unter Linux

[Ralph S. (jjflash)]

Ich habe ein sehr spezielles Problem von dem ich glaube dass es hierfür 
keinen wirklichen mehr Experten gibt (ich aber sehr hoffe, dass ich mich 
täusche):

Mein "Endlosprojekt" (seit ein paar Jahren) beschäftigt sich mit einer 
reinen Konsolen-IDE unter Linux und ich hatte damals alte Projekte 
(manche sogar noch unter Windows) unter FreePascal weiter geführt.

Weil diese Projekte weit fortgeschritten waren sind, habe ich hierfür 
niemals die Sprache gewechselt und deshalb gibt es für bestimmte Dinge 
bei mir immer noch Freepascal (abgesehen davon dass ich da ein 
wirklicher "Fan" davon bin).

Mein Problem jetzt ist, dass meine Konsolen-IDE (wenn man die so nennen 
kann) im Grunde genommen ein Texteditor ist, der mit dem FreeVision 
Framework (das ist die freigegebene TurboVison "Oberfläche" von Borland 
wie man sie aus Turbo-C und Turbo-Pascal kennt) erstellt ist.

Das ganze funktioniert auch super, bis auf:

Rufe ich aus meiner IDE bspw. ein externes Konsolenprogramm (bspw. ein 
Flashprogramm) auf und die Kommunikation des Flashers mit dem Baustein 
funktioniert nicht UND das Flasherprogramm beendet sich selbst nicht mit 
einem Fehler, kehrt der Programmaufruf logischerweise nicht zu meiner 
IDE zurück.

Wird mein Konsolenprogramm aus einem Desktop heraus gestartet, muß ich 
dieses Fenster schließen, schlimmer ist es, wenn ich gar kein Desktop 
gestartet hatte und meine IDE tatsächlich auf einem "echten" 
Konsolenlinux ausgeführt habe. Hier ist dann ein Neustart erforderlich.

Mein Problem hierbei ist, dass ich ein externes Programm gestartet aus 
meiner IDE nicht wie unter einem Konsolendirektaufruf mit STRG-C 
"abwürgen" und somit beenden kann.

Ich komme auch an keine Prozessverwaltung heran, weil die FreeVision 
ihren eigenen Tastaturhandler einsetzt (und bspw. deshalb auch so etwas 
nützliches wie das Umschalten der Konsolen mit ALT-Fx nicht 
funktioniert).

Meine Frage deshalb ist: weiß jemand, wo der originale und der aktuelle 
Tastaturhandler von FreeVision abgelegt ist, damit bei einem Aufruf 
externer Programme der originale Handler verwendet werden kann und nach 
Beendigung des externen Programmes wieder der von FreeVision gesetzt 
wird?

Ich suche schon "ewig" in den Tiefen des FreeVison Frameworks, bin aber 
nicht fundig geworden.

Leider antworten auch die Entwickler der der FreePascal IDE auf Mails 
nicht (und ich glaube, dass die Konsolen-IDE von FP nicht mehr gepflegt 
wird und nur mit jeder neuen FP Version einfach neu übersetzt wird).

Wenn es hier tatsächlich einen Experten für mein Problem gibt würds mich 
freuen.

Gruß Ralph

PS: bitte bitte bitte verschont mich mit: wer braucht eine Konsolen-IDE, 
oder nimm NCURSES, oder wechsel die Programmiersprache. Mein Projekt 
funktioniert super, nur hätte ich gerne diesen Makel beseitigt. Außerdem 
wirft man ein Projekt nicht so einfach weg, wenn es schon über 100000 
Zeilen eigenen Codes groß ist.

[Bernd K. (prof7bit)]

Du kannst den Prozess doch jederzeit killen als letzten Ausweg.

Edit: Ach jeztzt sehe ich es erst, Du startest die externen Tools direkt 
von FP aus? Versuch doch mal Dir eine Art Wrapper-Tool oder script zu 
schreiben das ein beliebiges externes Programm startet und nach x 
Sekunden wieder zwangsweise killt.

Und ganz abgesehen davon: Warum um alles in der Welt entwickelst Du auf 
einer Konsole mit FP? Aus Nostalgiegründen? Nimm doch stattdessen 
Lazarus als IDE! Auch damit kann man Konsolenanwendungen entwickeln!

[Ralph S. (jjflash)]

Bernd K. schrieb:
> Und ganz abgesehen davon: Warum um alles in der Welt entwickelst Du auf
> einer Konsole mit FP? Aus Nostalgiegründen? Nimm doch stattdessen
> Lazarus als IDE! Auch damit kann man Konsolenanwendungen entwickeln!

Irgendwie hab ich gewußt, dass diese Antwort kommt.

Nostalgiegründe.. vielleicht. Ich arbeite mit meiner Konsolen-IDE 
deutlich schneller als mit jeder Desktop-IDE.

Der Editor aus Lazarus macht genau das, was ich nicht will. Ich hätte 
gerne eine Fullscreen - IDE innerhalb derer ich mehrere Editorfenster 
aufmachen kann und die verschieben kann wie ich will. Wenn ich mich 
satter damit auseinandersetze kann es schon gut möglich sein, dass das 
geht, aber für diesen Fall muß ich wirklich alles alles neu machen was 
ich bisher habe (natürlich sind Bildschirmmasken mit Lazarus aufgrund 
"Visual-Programming" deutlich einfacher zu machen als mit FreeVision).

Naaaaaatürlich kann man mit Lazarus Konsolenanwendungen programmiern 
(mach ich auch), aber Lazarus stellt kein Framework für eine TUI in der 
Konsole zur Verfügung (sondern eben nur im Desktop).

Ich mag den SchnickSchnack und das extrem Überladene einer IDE (wie 
bspw. Atmel Studio) nicht, dass 1000 Jahre braucht, bis es gestartet 
ist.

Ich will brauche auch keine graphische Oberfläche, die Resourcen bis zur 
Ewigkeit benötigt.

Meine IDE mit Compiler für AVR und ARM läuft sogar noch relativ flüssig 
auf einem 900 MHz Celeron (wie er bspw. in einem Asus eeePC 701 
werkelt).

Es funktioniert (bei Neucompilierung) sogar relativ gut auf einem 
Raspberry PI Zero (der dann sogar über die GPIO-Pins einen Atmel 
Controller flashen kann).

Eine graphische Oberfläche benötigt alleine schon für die 
Bildschirmverwaltung eine große Menge Speicher. Mit einer "Textmode-IDE" 
ist dem nicht so. Beim Programmieren geht es nur um einen reinen 
Programmtext und nicht darum, wie schick etwas ausschaut.

Wenn ich unter einem Desktop werkle, ist meine "IDE" der Wahl GEANY (das 
mir hier dann mein Makefile aufruft und alles gut ist). Es geht schlicht 
darum, dass ich Controller auf einem reinen Konsolenlinux programmieren 
kann.

Natürlich kann ich bspw. 3 Terminals aufmache, in einem editiere ich 
meinen Text mit bspw. MCEDIT, im anderen rufe ich immer wieder Make auf 
und im dritten make flash.

Aber genau das ist das, was ich nicht will. Ich möchte das in der Art 
programmieren wie ich "anno dazumal" mit Turbo Pascal und Turbo C 
gewerkelt habe.

Außerdem ist das ein Lehrsystem bei dem eben keine vorgefertigte IDE am 
Start sein soll, sondern ein Projekt eben mittels Makefile realisiert 
ist.

Bernd K. schrieb:
> Versuch doch mal Dir eine Art Wrapper-Tool oder script zu
> schreiben das ein beliebiges externes Programm startet und nach x
> Sekunden wieder zwangsweise killt.

Das, habe ich schon gemacht, aber je nachdem was ich starte, kann ein 
Compilergang oder ein Flashvorgang (bspw. 256 kByte in einen STM32F4 
mittels seriellem Bootloading) schon relativ lange dauern.

Ich könnte also im Makefile selbst eine Art Timeoutprogramm starten, 
dass das Makefile selbst aus dem Prozess wieder killt. Das ist jedoch 
Contraproduktiv, weil man zu Beginn eines Projektes nicht weiß, wie groß 
das Binärfile werden wird (und wie lange ein Compilergang und ein 
Flashen dauern wird).

[Ralph S. (jjflash)]

... so sieht die "IDE" aus, eben wie ein Turbo-C mit beliebig vielen 
Fenstern offen. Hier ein STM8 Projekt und ein dazugehörendes Makefile.

Im Statusfenster wird das Ergebnis des Compilierens oder des Flashens 
angezeigt.

[Bernd K. (prof7bit)]

Ralph S. schrieb:
> aber Lazarus stellt kein Framework für eine TUI in der
> Konsole zur Verfügung

Aber selbstverständlich kannst Du Free Vision Anwendungen mit Lazarus 
entwickeln, das Framework ist dort genauso verwendbar, was hindert Dich 
dran?

> mehrere Fenster

Und selbstverständlich kann man in der Lazarus IDE mehrere Editorfenster 
gleichzeitig offen haben und beliebig viele davon auf dem Desktop 
verteilen. Und dann kommst Du auch in den Genuss der hervorragenden 
Codeassistenz die die Lazarus-IDE bietet. Ich würde FP nicht mal mehr 
mit der Kneifzange anfassen heutzutage, das ist doch die reinste 
Quälerei.

[Ralph S. (jjflash)]

... ihr versteht einfach nicht wirklich !!!! Es geht nicht darum, mit 
was ich ein Programm entwickle (natürlich kann man mit Lazarus jedes 
x-beliebige Pascal / Delphi Programm entwickeln).

Lazarus ist ja eher das Framework für den FreePascal Compiler.

Es geht darum, eine bereits entwickelte FreeVison Anwendung (die, dich 
ich programmiert hab) zu erweitern.

Mit was mein FreeVision Programm geschrieben ist, ist doch wurst (egal 
mit welchem Editor auch immer, FP, Lazarus ... oder wie in meinem Falle 
mit Geany).

Es geht darum, den Tastaturhandler von FreeVision Programmen zu 
ermitteln (und je nach Anwendung zu verbiegen).

Mein erstelltes FreeVision Programm heißt CIDE und ist NICHT FreePascal, 
es verwendet nur die absolut gleiche Oberfläche.

MIt diesem CIDE wiederum entwickle ich Programme in C und C++ für 
Mikrocontroller auf der Konsole.

Es dreht sich nicht darum, ob man einen Konsoleneditor noch anfasst oder 
nicht. Es dreht sich schlicht darum, dass ich mit keinem Editor auf der 
Konsole glücklich geworden bin (auch nicht mit EMACS).

Projekte für Mikrocontroller (ganz speziell für 8 Bitter, meistens auch 
für ARM) werden nicht derart groß, wie es PC Programme werden.

Weshalb muß ich als mit absolut Killerfressenden IDE ein µC Programm 
entwickeln?

Fast alles bei der Mikrocontrollerprogrammierung erinnert mich an die 
Art und Weise, wie ich mit Turbo-C Programme für DOS geschrieben habe.

Warum soll das jetzt für Controller schlecht sein. Es kommt nicht auf 
die IDE an, es kommt auf Algorithmen und Codierung drauf an.

Ich kann verstehen, wenn Programme für PC mittels "Visual Programming" 
mit Programmen wie Visual Studio oder Lazarus entstehen (ich verwende 
beides)... aber ich verwende es nicht für Controller. Hier reicht für 
mich absolut ein Editor und ein Makefile (und evtl. eine Library).

Um hierfür Texte zu erstellen, bedarf es keiner gigantomanischen PC's

Booooah... ich hab nur gefragt gehabt, ob jemand weiß wo das FreeVision 
Framework den Tastaturhandler zwischenspeichert.

Manche der hier antwortenden haben nicht wirklich verstanden was ich 
machen mag.

Nochmal: es geht nicht darum mit was ich ein Konsolenprogramm schreibe, 
es geht um das Konsolenprogramm selbst...  !!!!!

[Zeno (Gast)]

Vielleicht ist es über einen kleinen Umweg möglich.
Unter Linux ist es doch möglich ein Programm zu starten und es sofort in 
den Hintergrund zu schicken. Das funktioniert meines Wissens auch mit 
einem Bashscript. Du startest von Deiner IDE das Bashscript welches 
seinerseits das gewünschte Program startet. Geht meines Wissens mit 
<Program> & . Das Bashscript sollte sich dann nach Start des Programmes 
beenden und Du kehrst somit in Deine IDE zurück. Allerdings mußt Du Dich 
jetzt selbst darum kümmern und selbst nachschauen ob das Programm noch 
läuft.
Das Ganze ist jetzt zwar nicht super elegant, aber Du solltest so 
zumindest wieder Zugriff auf Deine IDE haben.
Probiert habe ich das ganze natürlich nicht. Aber vielleicht ist es für 
Dich ein Gedankenanstoß.

[Zeno (Gast)]

Hast Du Dir mal die RunCommand Procedur 
(https://www.freepascal.org/docs-html/fcl/process/runcommand.html) 
angesehen. Da kann man über TProcessOptions das Verhalten des neuen 
Prozesses steuern. Schau Dir das mal an

[Ralph S. (jjflash)]

Zeno schrieb:
> Hast Du Dir mal die RunCommand Procedur
> (https://www.freepascal.org/docs-html/fcl/process/runcommand.html)
> angesehen. Da kann man über TProcessOptions das Verhalten des neuen
> Prozesses steuern. Schau Dir das mal an

Hab ich mir angesehen. Letztendlich habe ich dadurch dieselben 
Möglichkeiten wie ich es bisher gemacht habe:

var
  myprocess       : tprocess;  

begin

  myprocess:= tprocess.create(nil);
  mystringlist:= classes.tstringlist.create;
  myprocess.commandline:= cmdnam;                   // cmdnam beinhaltet den Befehl fuer die Kommandozeile / Konsole
  myprocess.options:= myprocess.options + [powaitonexit,pousepipes,poStderrToOutput];

  // -----------------------------------------------------------------------
  //               Kommando des Betriebssystem aufrufen
  // -----------------------------------------------------------------------
  myprocess.execute;
  // -----------------------------------------------------------------------
  exitcode:= myprocess.exitstatus;

Prinzipiell habe ich einen Weg gefunden (umständlich) um eine Art 
"Watchdog" im Makefile zu verstecken, schön ist aber anderst. Eine 
Möglichkeit einen von Freepascal gestarteten Prozess aus dem Programm 
heraus über die Tastatur abzubrechen wäre mir dann doch lieber.

Aber Danke für den Hinweis mit RunCommand

[Bernd K. (prof7bit)]

Ralph S. schrieb:
> Eine
> Möglichkeit einen von Freepascal gestarteten Prozess aus dem Programm
> heraus über die Tastatur abzubrechen wäre mir dann doch lieber.

Wo liegt das Problem? Du definierst einen Hotkey in Deinem Hauptprogramm 
und wenn der gedrückt wird kann irgendwas geschehen, zum Beispiel den 
vorher mittels TProcess gestarteten Unterprozess wieder zu killen. 
TProcess hat auch ne Option daß es nicht wartet bis der Unterprozess 
beendet ist.

> Manche der hier antwortenden haben nicht wirklich verstanden was ich
> machen mag.

Vielleicht solltest Du einfach weniger Text und mehr und präziseren 
Inhalt schreiben.

Und Deine "gigantomanischer killerfressender PC"-Bemerkungen als 
Umschreibung für alle Arbeitsplatzrechner die man seit 30 Jahren aus 
jeder Elektroschrott Gitterbox rausziehen kann um Dein skurriles Projekt 
zu rechtfertigen musst Du auch nicht in jeden zweiten Nebensatz 
einflechten, das lässt Dich absolut schräg erscheinen.

[Niklas G. (erlkoenig)]

Ralph S. schrieb:
> Warum soll das jetzt für Controller schlecht sein. Es kommt nicht auf
> die IDE an, es kommt auf Algorithmen und Codierung drauf an.

"Richtige" IDEs bieten Features, welche auch bei 
Mikrocontroller-Programmierung sehr hilfreich sind, wie z.B. 
git-Integration, Debugger-Oberfläche, Code-Vervollständigung und 
-Live-Prüfung, Suche nach Definition und Verwendung von Bezeichnern, ... 
Kann CIDE das auch alles?

Grafische IDEs können besser mit Bildschirmplatz haushalten - unwichtige 
Dinge können klein dargestellt werden (Icons, Menüs, Trennbalken 
zwischen Textfenstern) und viel Platz für den Quellcode lassen, während 
eine TUI für jedes Grafikelement ein ganzes Zeichen braucht, und die 
Schriftgröße muss überall gleich sein. Mikrocontroller-Programme können 
auch über eine Bildschirmseite groß werden...

Ich vermute mal, du startest die CIDE von einer Shell auf einem Terminal 
aus. Kann man Strg+C da überhaupt abfangen? Geht das nicht direkt an das 
Terminal, welches SIGINT an den Prozess sendet? Du könntest SIGINT 
abfangen und ignorieren bzw. nur an make weiterleiten, aber dann kann 
man die CIDE auch nicht mehr abbrechen falls nötig.

Kannst du nicht make über die normalen Unix-Funktionen 
fork,exec,pipe,dup2 "im Hintergrund" starten (ggf. über eine C-Library), 
dann ganz normal Maus- und Tastatureingaben abfangen und ggf. über kill 
den make-Prozess abbrechen?

[Bernd K. (prof7bit)]

Niklas G. schrieb:
> Kannst du nicht make über die normalen Unix-Funktionen
> fork,exec,pipe,dup2 "im Hintergrund" starten

Das kann man auch mit TProcess machen wenn WaitOnExit auf False setzt 
(was glaub ich sogar der Default ist), wofür man ungefähr 10 Sekunden 
nach dem Handbuch googeln muss. Mit nem reinen Konsolen-PC von 1980 
gestaltet sich das Googeln natürlich etwas schwieriger. Aber das 
Handbuch für die fcl gibts glaub ich auch in irgend einer Textform.

@OP: Schonmal versucht F1 zu drücken wenn der Cursor auf dem Wort 
TProcess steht?

[Niklas G. (erlkoenig)]

Bernd K. schrieb:
> Das kann man auch mit TProcess machen wenn WaitOnExit auf False setzt

Achso. Ich hatte vermutet dass der Grund für die Frage war, dass das so 
nicht geht...

[Ralph S. (jjflash)]

Bernd K. schrieb:
> TProcess hat auch ne Option daß es nicht wartet bis der Unterprozess
> beendet ist.

Genau das hab ich jetzt auch gemacht und funktioniert. Danke dafür.

Bernd K. schrieb:
> das lässt Dich absolut schräg erscheinen.

Wahrscheinlich bin ich ja auch n bissi schräg (genau wie das Projekt)... 
sorry.

@Bernd: grundsätzlich ging es darum, dass ich das Gefühl hatte 
(eigentlich nicht nur das Gefühl) das andere hier gar nicht mein 
"Problem" verstanden hatten (du hast das skurille Projekt erfasst).

Außerdem war ich vernagelt: Ich wollte so sehr an den Tastaturhandler 
ran, dass ich nicht daran gedacht hatte, schlicht den Prozess zu 
überwachen und ggf. abzuschiessen.

Momentan funktioniert mein Makeaufruf nun so, wie ich das gerne hätte.