mikrocontroller.net

Forum: PC-Programmierung Qt -> FPC (war: Lazarus Pascal und so)


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wie im Nachbarthread geschrieben, ich habe hier eine Qt-Applikation, die 
über einen selbst gestrickten Controller auf einen Tektronix 492 
zugreift, um dessen Daten (da er kein GPIB hat) zu visualisieren.

War vor einiger Zeit dann daran gescheitert, dass Ganze auch für Windows 
so hinzubekommen, dass man es auf einfache Weise (sprich: statisch 
gelinktes Binary) jemandem in die Hand drücken kann, ohne dass er erst 
allerlei Krimskrams noch installieren muss oder ich ihm einen Installer 
liefern muss, der ebendies tut.

Anbei mal ein Screenshot. Wenn ich Lazarus aufrufe und ein Projekt 
anfange, dann fängt meine Suche schon damit an, wie ich einerseits die 
Aufteilung des Platzes anfange, und vor allem, wo ich sowas wie diese 
Drehregler finde. Das UI ist ein wenig der Anordnung der Bedienelemente 
des Tek492 selbst nachempfunden, aber darauf wäre ich jetzt nicht 
unbedingt festgelegt. Solange man also alle dessen „Knöppe“ überhaut 
irgendwie unterbekommen kann, würde mir das reichen.

Das Ganze ist low prio, aber über ein paar Ansatzpunkte vor allem der 
UI-Seite würde ich mich freuen.

Auch interessant wäre, wie man die davon gespeicherten XML-Dateien 
(deren Inhalt der Screenshot gerade zeigt) in FPC parsen und speichern 
kann.

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Drehknöpfe findest Du schon mal hier.
https://wiki.freepascal.org/BGRAControls/de

Die Aufteilung des Fensters macht man mit TPanels, das ist nichts 
besonderes.

XML:
https://wiki.lazarus.freepascal.org/XML_Tutorial/de

Die Graphik:
https://wiki.freepascal.org/TAChart_Demos

: Bearbeitet durch User
Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> War vor einiger Zeit dann daran gescheitert, dass Ganze auch für Windows
> so hinzubekommen, dass man es auf einfache Weise (sprich: statisch
> gelinktes Binary) jemandem in die Hand drücken kann, ohne dass er erst
> allerlei Krimskrams noch installieren muss oder ich ihm einen Installer
> liefern muss, der ebendies tut.

Du brauchst lediglich die verwedete Teile der Qt-Bibliothek und ggf. 
noch die Laufzeitbibliothek deines Compilers mitzukopieren - da reicht 
eine Zip-Datei für.

Ist ja nun kein Grund, gleich alles neuzuschreiben :)

Autor: olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt im QT Verzeichnis auch ein Programm dessen Namen mir nicht
einfallen will, welches einem anzeigt welche Libary ein Programm alles
benötigt.

Olaf

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
olaf schrieb:
> Es gibt im QT Verzeichnis auch ein Programm dessen Namen mir nicht
> einfallen will, welches einem anzeigt welche Libary ein Programm alles
> benötigt.

Du meinst wahrscheinlich windeployqt.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Klassiker dafür war/ist eigentlich http://www.dependencywalker.com/

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> Die Drehknöpfe findest Du schon mal hier.
> https://wiki.freepascal.org/BGRAControls/de

Wo genau findet man die Dokumentation dazu?

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Wo genau findet man die Dokumentation dazu?

Keine Ahnung. Der Knopf an sich ist aber simpel. Da braucht es keine 
Doku dazu. Da sind die Properties selbsterklärend.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Es ist sehr empfehlenswert sich im Lazarus-Forum anzumelden und dort um 
Hilfe zu fragen. Dort herrscht normalerweise ein freundlicher Umgangston 
weil die Zielgruppe dort ein gemeinsames Interesse hat und nicht so 
extrem polarisiert ist wie hier und ein Anfänger der verstehen will wie 
etwas funktioniert wird dort gerne willkommen geheißen und an die Hand 
genommen.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> mh schrieb:
>> Wo genau findet man die Dokumentation dazu?
>
> Keine Ahnung. Der Knopf an sich ist aber simpel. Da braucht es keine
> Doku dazu. Da sind die Properties selbsterklärend.

Es geht ja nicht nur um den Knopf. Es wäre aber schön, genau zu wissen, 
wie wenig dieser Knopf kann. Bilder in nem wiki sind nicht wirklich 
ausreichend.

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hier gibt es noch schönere Knöpfe und Elemente für Gerätesteuerungen:
https://wiki.freepascal.org/uE_Controls

mh schrieb:
> Es wäre aber schön, genau zu wissen,
> wie wenig dieser Knopf kann. Bilder in nem wiki sind nicht wirklich
> ausreichend.

Installieren und gucken.

: Bearbeitet durch User
Autor: mh (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Andreas B. schrieb:
> mh schrieb:
>> Es wäre aber schön, genau zu wissen,
>> wie wenig dieser Knopf kann. Bilder in nem wiki sind nicht wirklich
>> ausreichend.
>
> Installieren und gucken.

Ich installiere grundsätzlich nichts ohne einen Blick in die Doku.

Autor: R.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> War vor einiger Zeit dann daran gescheitert, dass Ganze auch für Windows
> so hinzubekommen, dass man es auf einfache Weise (sprich: statisch
> gelinktes Binary) jemandem in die Hand drücken kann, ohne dass er erst
> allerlei Krimskrams noch installieren muss oder ich ihm einen Installer
> liefern muss, der ebendies tut.

Denk dran, wenn Du keine kommerzielle Lizenz verwendest (was Du höchst 
whrscheinlich nicht tust), Dein Programm der GPL unterliegt, d.h. dem Du 
das gibst, kann die Herausgabe des Sourcecodes verlangen (finde ich 
nicht schlimm), dann aber auch den Sourcecode und exe frei 
weiterverteilen, z.B. ins internet stellen (finde ich persönlich nicht 
angenehm).

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
mh schrieb:
> Ich installiere grundsätzlich nichts ohne einen Blick in die Doku.

Tja, Pech gehabt.
Nur mal als Anmerkung: Du bekommst hier SW für lau. Wenn Du nicht 
willens bist, Dich ohne Doku da einzuarbeiten, muß Du eben auf Löhn-SW 
zurückgreifen. Da hast Du dann jemanden wo Du Dich beschweren kannst.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> mh schrieb:
>> Ich installiere grundsätzlich nichts ohne einen Blick in die Doku.
>
> Tja, Pech gehabt.
> Nur mal als Anmerkung: Du bekommst hier SW für lau. Wenn Du nicht
> willens bist, Dich ohne Doku da einzuarbeiten, muß Du eben auf Löhn-SW
> zurückgreifen. Da hast Du dann jemanden wo Du Dich beschweren kannst.

Oder ich benutze Software, die frei und gut dokumentiert ist.

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
mh schrieb:
> Oder ich benutze Software, die frei und gut dokumentiert ist.

Klar, kann man machen. Dann ist die Auswahl halt geringer. Doku 
erstellen ist generell eine unbeliebte Aufgabe.
Wie Bernd schon erwähnte, hat man auch die Möglichkeit, sich im Lazarus 
Forum anzumelden und dort zu fragen.

: Bearbeitet durch User
Autor: Maxe (Gast)
Datum:
Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
Die TPanel wurden ja schon angesprochen, ich würde die Verschachtelung 
wie im Anhang wählen.
- Panel A (rot) bekommt im Objektinspektor (OI) die Anchor links, 
rechts, oben und unten. Damit passt es sich in allen Richtungen linear 
zur Fenstergröße an.
- Panel B (orange) bekommt die Anchor rechts, oben und unten. Damit 
passt es sich in der Höhe dem Fenster an, ist in der Breite aber starr.
- Panel C (blau) wird im OI als Child von Panel A angeordnet (mit der 
Maus ziehen) bekommt die Anchor links, rechts, oben und unten. Geht in 
der Größe also immer dem Fenster mit.
- Panel D ist in der Größe wieder starr, wird als Child von Panel A 
angeordnet und bekommt die Anchor links und unten.
- Das Diagramm ist Child von Panel C und bekommt wieder alle Anchor, 
bewegt sich also in der Größe mit.
- Alle Anderen Controls, die in der Größe fest sind, behalten die 
Standard-Anchors links und oben und werden als Child der jeweiligen 
Panels angeordnet.

Wenn man eine relative Größenänderung zwischen beiden Seiten haben 
möchte, dann macht man das im Eventhandler (OnResize) für das Formular 
(Hauptfenster). Das wählt man im OI unter dem Eigenschaftentab aus über 
den [...]-Knopf, dann wird der Handler automatisch angelegt. Darin kann 
man dann die Verhältnisse berechnen, z.B.:

PanelA.Width:= Form1.ClientWidth * 0,4;
PanelB.Left:= PanelA.Left + PanelA.Width;
PanelB.Width:= Form1.ClientWidth - PanelA.Width;

Die untergeordneten Panels ordnen sich dann weiterhin entsprechend der 
Anchors an.

Autor: Gegeg J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist das tolle an der Pascal Community, ich habe dort noch nie so was 
gelesen wie..benutz doch google oder so.
Da hilft jeder jedem, und es kommen keine Sinnfreien Gegenfragen, 
sondern nur Lösungsvörschläge..anstelle von Lösungsfragen kommt ein 
alternativer Quellcode! mit Erklärung. Die Community ist der Hammer!
https://forum.lazarus.freepascal.org/index.php?action=forum

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Gegeg J. schrieb:
> Die Community ist der Hammer!

Danach hatte ich jetzt aber wirklich nicht gefragt, und ich wünsche mir, 
dass diese aufdringliche "Wir sind alle toll!"-Werbung in diesem Thread 
nicht stattfindet. Wenn ich für dieses Projekt Freepascal wirklich 
benutze, dann nicht, weil sich die Leute dort toll fühlen, sondern weil 
es mir einen Vorteil bringt. Vernünftige Diskussionen gibt's auch hier 
im Forum, aber eben auch nur dann, wenn die Evangelisten (jeglicher 
Coleur) woanders evangelisieren.

Gleiches gilt auch für krümelkackeriges Rumreiten auf fehlender Doku – 
einmal danach gefragt, eine Antwort bekommen, damit darf es auch wieder 
gut sein.

Sven P. schrieb:
> Du brauchst lediglich die verwedete Teile der Qt-Bibliothek und ggf.
> noch die Laufzeitbibliothek deines Compilers mitzukopieren -

Ist schon 'ne Weile her, hatte dann doch irgendwie nicht funktioniert. 
Lag u.a. auch daran, dass das Zielsystem hornalt ist (Win2k), und wenn 
ich mich recht erinnere, gab es auch mit dem qwt dann Probleme. qwt 
sieht schick aus, aber scheint schon etwas schräg an Qt rangestrickt zu 
sein.

Außerdem eignet sich es halt als nettes und trotzdem sinnvolles Projekt, 
um mit Freepascal überhaupt was zu machen. Pascal kenne ich, aber aktiv 
benutzt habe ich es (in zwei verschiedenen Dialekten) vor mehr als 30 
Jahren.

R.S. schrieb:
> [Qt] Denk dran, wenn Du keine kommerzielle Lizenz verwendest (was Du höchst
> whrscheinlich nicht tust), Dein Programm der GPL unterliegt

LGPL, genau genommen. Wäre hier aber egal gewesen, es interessiert 
praktisch nur eine weitere Person, der kann ich problemlos auch den 
Sourcecode in die Hand drücken. Genaue Lizenz wäre hier wurscht, ist ein 
reines Hobbyprojekt, und ich habe schon genügend Opensource-Software 
geschrieben und veröffentlicht, dass ich mich davor nun nicht scheue. 
Wenn mich an den GPL-ähnlichen Lizenzen was stört, dann ist es die 
schiere Größe von deren Lizenztext. Ich schreib da lieber eine 
"Beer-ware license" drüber, und konzentriere mich dann auf die Arbeit. 
(Gerade nachgesehen, die steht da im Quelltext auch tatsächlich drüber, 
einschließlich des Hinweises, dass alles zusammen dann unter LGPL 
fällt.)

Danke für die hilfreichen Hinweise an Maxe und Andreas. Mal sehen, ob 
ich an einem langen Winterabend den Nerv habe, mir das mal anzusehen.

: Bearbeitet durch Moderator
Autor: Peter K. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
ach schau an, der Moderator selbst reagiert empfindlich, wenn andere 
möchten das sich Leute ihre Kommentare Ersparen gibt es nur so Sprüche 
wie "freies Forum und freie Meinungsäußerung " Wäre schön wenn die 
Moderatoren generell mal so bei Tehmen anderer Benutzer reagieren 
würden. BEVOR jedes Thema mit sinnfreien Nebenthemen gekapert wird

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> LGPL, genau genommen. Wäre hier aber egal gewesen, es interessiert
> praktisch nur eine weitere Person, der kann ich problemlos auch den
> Sourcecode in die Hand drücken. Genaue Lizenz wäre hier wurscht

Anmerkung am Rande: Die Frameworks von Lazarus sind ebenfalls LGPL aber 
mit zusätzlicher "static linking exception", das bedeutet unter dem 
Strich man kann sie mit eigener proprietärer Software statisch linken 
und muss den Quelltext NICHT liefern, man kann also seine damit erzeugte 
.exe ohne Quelltext und unter beliebiger Lizenz vertreiben! Das sollte 
interessant sein für potentielle kommerzielle Anwender. Wollt ich nur 
mal erwähnen in dem Zusammenhang.

Autor: oiuz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> R.S. schrieb:
>> [Qt] Denk dran, wenn Du keine kommerzielle Lizenz verwendest (was Du höchst
>> whrscheinlich nicht tust), Dein Programm der GPL unterliegt
>
> LGPL, genau genommen.
Ergänzung:
Nur bei statischem Linken. ;-)

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> wo ich sowas wie diese
> Drehregler finde

Es gibt auch noch PascalScada, mit ganz vielen Bedien- und 
Anzeigeelementen.

Allerdings sieht das Scada-mäßig etwas altbacken aus und ich weiß nicht, 
wie es sich mit den Lizenzen verhält.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> mh schrieb:
>> Wo genau findet man die Dokumentation dazu?
>
> https://github.com/bgrabitmap/bgracontrols/blob/master/bgraknob.pas
Also was die BGRAControls als solche angeht: Eine ziemlich bunte 
Sammlung für allerhand Kram, den man mit Qt wohl mit zwei, drei Zeilen 
Stylesheet erledigt hätte.

Das war für mich damals auch der Ausstieg aus Delphi und in meinen Augen 
auch das K.O.-Kriterium für Delphi als "RAD": Viel zu viel Aufwand für 
hart programmierten Oberflächenkram. Die mitgelieferten Klassen (damals 
noch VLC) können ziemlich wenig.
Genau dafür will ich doch ein durchdachtes GUI-Framework... damit ich 
nicht jeden nebensächlichen Mist wieder programmieren oder mit 
einigermaßen-halbgaren Zusatzkomponenten zusammenbritzeln muss.

Autor: Karl K. (karl2go)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Sven P. schrieb:
> Eine ziemlich bunte
> Sammlung für allerhand Kram, den man mit Qt wohl mit zwei, drei Zeilen
> Stylesheet erledigt hätte.

Nur bietet weder WinApi noch GTK Drehräder als Gadgets / Widgets an, 
somit ist das eh eine Qt-eigene Implementierung. Die an der Stelle ganz 
witzig sein mag, normalerweise finde ich mit der Maus bedienbare 
Drehräder ziemlich unhaptisch.

Ansonsten ist mir noch nichts aufgefallen, was in der LCL an Widgets 
fehlen würde.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> XML:
> https://wiki.lazarus.freepascal.org/XML_Tutorial/de

Hier aufpassen: Die normalen FPC XML Units (DOM, XMLRead, XMLWrite, 
XMLCfg) nehmen die Systemcodierung an. Das ist ein Sackgang, wenn man 
unter Windows Configs für Linux erstellt und die vielleicht noch mit 
Geany oder so bearbeitet.

Plattformübergreifend sollte man XML möglichst mit Utf8 erstellen, und 
dazu gibt es für Lazarus die laz2_xx Units (laz2_DOM, laz2XMLRead...).

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Die normalen FPC XML Units (DOM, XMLRead, XMLWrite, XMLCfg) nehmen die
> Systemcodierung an.

Das ist doof, warum kann man das nicht überschreiben bzw. hat nicht 
gleich UTF-8 zum Default gemacht? Ist meiner Erinnerung nach für XML 
eigentlich die grundsätzliche Empfehlung.

Meine bisherige Qt-Applikation hat die Daten in XML-Dateien abgelegt, 
und die würde ich natürlich auch gern beibehalten.

Danke jedenfalls für den Hinweis, wenn's mal soweit ist.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Das ist doof, warum kann man das nicht überschreiben bzw. hat nicht
> gleich UTF-8 zum Default gemacht?

Weil die FCL (Freepascal) auf Ansi basiert, und das kann je nach 
Plattform halt Windows-Ansi oder Unicode sein. Die LCL (Lazarus) 
verwendet Unicode.

Man hat das Problem schon erkannt, aber will halt offenbar aus 
Kombatibilitätsgründen da nichts ändern.

Jörg W. schrieb:
> Meine bisherige Qt-Applikation hat die Daten in XML-Dateien abgelegt,
> und die würde ich natürlich auch gern beibehalten.

Ja kannst Du doch, was für ein Encoding steht denn im Header?

Ansi-Unicode war bisher in so ziemlich jeder Sprache ein Hickhack - 
außer in Assembler... Wenn Du plattformübergreifend programmieren 
willst, mach alles in Utf-8. Das nimmt die Lazarus IDE von vornherein 
an, wenn keine BOM vorhanden.

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Das nimmt die Lazarus IDE von vornherein an, wenn keine BOM vorhanden.

Versteh' ich jetzt nicht – was hat die IDE jetzt mit abgelegten 
XML-Dateien am Hut? Die IDE muss die sich ja nicht angucken können …

Aber bis dahin ist sowieso noch einiges zu tun, erst müsste ich mal den 
GUI-Kram und die USB-Anbindung zimmern.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> was hat die IDE jetzt mit abgelegten
> XML-Dateien am Hut?

Karl K. schrieb:
> Wenn Du plattformübergreifend programmieren
> willst, mach alles in Utf-8.

Alles heisst: Alles. Auch die Units (sollten sie eigentlich, kann man 
aber ändern). Auch ini-Files. Auch Dateiausgaben. Alles was irgendwie 
Text ist, der Sonderzeichen haben kann, und seien es Deine Kommentare im 
Code.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von mir aus soll ja auch alles als UTF-8 da sein, aber eben auch der 
Kram, der aus der Applikation gespeichert wird, wenn sie unter Windows 
läuft.

Wobei: für das bisschen Datenformat ist das Encoding sowieso egal, denn 
das kommt komplett mit ASCII aus.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Sven P. schrieb:
>> Eine ziemlich bunte
>> Sammlung für allerhand Kram, den man mit Qt wohl mit zwei, drei Zeilen
>> Stylesheet erledigt hätte.
>
> Nur bietet weder WinApi noch GTK Drehräder als Gadgets / Widgets an,
> somit ist das eh eine Qt-eigene Implementierung.

Es könnte eine Erweiterungsbibliothek zu Qt namens qwt sein.
Siehe https://qwt.sourceforge.io/
Qt von sich aus hat soweit ich weiß keine solchen Drehknöpfe.

> Die an der Stelle ganz witzig sein mag, normalerweise finde ich mit der
> Maus bedienbare Drehräder ziemlich unhaptisch.

Kommt immer drauf an, wie die Maussteuerung dann umgesetzt ist. Wenn man 
wirklich die Maus im Kreis rumschieben muss, ist das natürlich Mist. 
Sowas wird aber meist eher so gemacht, dass man mit der Maus 
draufklicken und dann bei gedrückter Taste die Maus einfach nur hoch und 
runter schieben muss - oder dass man das Mausrad für die Verstellung 
verwenden kann. Dann ist es durchaus bedienbar.

Autor: Gegeg J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier hat doch mal jemand seine selbstgeschriebene Alternative zu 
Profilab und Co vorgestellt, die war auch in Free Pascal programmiert.
Der kann Dir sicher Quellen für seine Bedienelemente nennen.
Leider finde ich den Beitrag jetzt nicht aus die schnelle

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Es könnte eine Erweiterungsbibliothek zu Qt namens qwt sein.

Könnte nicht, war/ist es. Schrieb ich doch, und ich schrieb auch, dass 
genau diese halt bei Qt immer mal wieder Späne gemacht hat und in 
verschiedenen Konstellationen auf verschiedenen Systemen für Segfaults 
verantwortlich zu sein scheint.

Das war ja u.a. der Anlass, die Portierung der Qt-App auf FPC ins Auge 
zu fassen.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
>> Die an der Stelle ganz witzig sein mag, normalerweise finde ich mit der
>> Maus bedienbare Drehräder ziemlich unhaptisch.
>
> Kommt immer drauf an, wie die Maussteuerung dann umgesetzt ist.

Bei Qwt kann man die mit dem Scrollrad bedienen (aber auch mit der Maus 
in der "Fingermulde" drehen, das ist durchaus bedienbar).

Der Drehknopf ist hier aber eher optisches Gimmick, damit das Look&Feel 
einigermaßen dem Analyzer selbst entspricht. Da der Tek492 sowieso keine 
GPIB-Schnittstelle hat, kann man ihn über die Ext-Schnittstelle nicht 
steuern (nur die Daten auslesen), sondern man kann an diesen Knöppen 
hier lediglich nachvollziehen, was man real am Analyzer eingestellt hat, 
damit auch die Beschriftung der Diagramme stimmt. Insofern wird man beim 
Drehknopf normalerweise einfach die Frequenz ins Eingabefeld mit der 
Tastatur eingeben.

Auf den könnte ich bei einem FPC-Rewrite also auch verzichten.

: Bearbeitet durch Moderator
Autor: Roland F. (rhf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,
Gegeg J. schrieb:
> Hier hat doch mal jemand seine selbstgeschriebene Alternative zu
> Profilab und Co vorgestellt, die war auch in Free Pascal programmiert.

Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle"

rhf

Autor: moakadarkmaster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Anbei mal ein Screenshot.

Mit welcher Lib hast du den Graph gemacht?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moakadarkmaster schrieb:
> Jörg W. schrieb:
>> Anbei mal ein Screenshot.
>
> Mit welcher Lib hast du den Graph gemacht?

Das ist eine qwt PlotArea.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
>> Mit welcher Lib hast du den Graph gemacht?
>
> Das ist eine qwt PlotArea.

Dafür gibts dann in Lazarus TChart, sehr mächtig das Teil, und 
standardmäßig dabei.

: Bearbeitet durch User
Autor: moakadarkmaster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Das ist eine qwt PlotArea.

Danke! Probiere immer wieder gerne mal Alternativen aus.

Nutze qcustomplot für online Visualisierungen mit vielen Datenpunkten (> 
1 Million) und mehreren Plots.

Autor: Franko S. (frank_s866)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Nur bietet weder WinApi noch GTK Drehräder als Gadgets / Widgets an,
> somit ist das eh eine Qt-eigene Implementierung. Die an der Stelle ganz
> witzig sein mag, normalerweise finde ich mit der Maus bedienbare
> Drehräder ziemlich unhaptisch.

Die Perversion dessen ist das:
Da geht um Rebirth das einen TB-303 emuliert und man wegen der 
realistischen Drehknopfdarstellung wieder Dritthardware herausbrachte 
mit echten Knöpfen weil man die Drehknöpfe schlecht mit der Maus 
bedienen konnte:

"So today we have computer software consisting on a 3-dimensional 
interface on a 2-dimensional screen being controlled by 3rd-party 
hardware so as to emulate a machine built 20 years ago, which was itself 
built to emulate a machine built 30 years before it"

Youtube-Video "TB-303 Documentary - Bassline Baseline (2005)"

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Drehknopf habe ich inzwischen sogar als Demo in FPC (mit den 
empfohlen BGRAcontrols) zusammen. Die Logik, um einen "roll over" über 
das Ende des Stellbereichs zu erkennen (und die Variable in die richtige 
Richtung weiterzuzählen), konnte ich vom Qt-Code übernehmen. Scrollrad 
geht allerdings nicht (anders als bei qwt). Macht aber nichts, denn wie 
ich schon schrieb, in aller Regel wird man die Frequenz ohnehin ins 
Eingabefeld tippen. Der Knopf ist eher ein optisches Gimmick.

Pascal scheint nach wie vor keine wirklichen statischen Variablen 
innerhalb von Funktionen/Prozeduren zu kennen. Stattdessen eine 
Konstante zu definieren, die man dann innerhalb der Prozedur aber 
verändern darf, ist schon ein heftiger Hack. (Braucht man an dieser 
Stelle, um im Eventhandler des Knopfes zu wissen, welcher Wert beim 
letzten Aufruf übergeben worden war.)

: Bearbeitet durch Moderator
Autor: Guido B. (guido-b)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Pascal scheint nach wie vor keine wirklichen statischen Variablen
> innerhalb von Funktionen/Prozeduren zu kennen.

Was ist eine statische Variable?

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Pascal scheint nach wie vor keine wirklichen statischen Variablen
> innerhalb von Funktionen/Prozeduren zu kennen.

Du kannst das als private Variable in der Unit deklarieren.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roland F. schrieb:
> Hallo,
> Gegeg J. schrieb:
>> Hier hat doch mal jemand seine selbstgeschriebene Alternative zu
>> Profilab und Co vorgestellt, die war auch in Free Pascal programmiert.
>
> Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle"

Der Typ des Projektes "Virtuelle Instrumente ...." benutzt Delphi7 
soweit ich weis. Da gab es doch ne ellenlange Diskussion wegen der 
Portierung des Programmes nach Linux. Was er wegen Delphi und der 
speziellen Komponenten abgelehnt hat. Wenn ich mich recht erinnere hatte 
er, zumindest zeitweise, die Ausführung seines Programmes in einer VM 
unterbunden.

Autor: Zeno (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Pascal scheint nach wie vor keine wirklichen statischen Variablen
> innerhalb von Funktionen/Prozeduren zu kennen.

FPC soll das können. Sieht dann so aus:
function xy(irgendwelche Parameter):irgendein Typ
var
  const i : integer = 0;
begin
.
.
.
end;

Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie Zeno es schreibt ist es richtig. Ist auch kein Hack, sondern 
offiziell. Auch wenns nicht gerade intuitiv ist.

Ich wuerde aber eher eine Unit-private Variable anlegen (d.h. Variable 
deklariert im Implentation-Teil).

Autor: Carl D. (jcw2)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Maxe schrieb:
> Wie Zeno es schreibt ist es richtig. Ist auch kein Hack, sondern
> offiziell. Auch wenns nicht gerade intuitiv ist.

Was Jörg wohl meint ist daß per Compiler-Switch die Haupteigenschaft von 
const ins Gegenteil verkehrt wird.
Man hätte ja einfach das (eh an anderer Stelle benutzte) Schlüsselwort 
static dafür benutzen können. Zumal man auch so den vielbeschworenen 
Delphi-Standard verlässt. Und man hätte auch klarere Fehlermeldungen, 
wenn man den Switch vergessen hat.

Außerdem gibt es Sprachen, bei denen "offiziell" nicht bedeutet, daß ein 
Compiler es so macht, sondern daß es im Standard so drinsteht.

Autor: Nop (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Carl D. schrieb:

> Außerdem gibt es Sprachen, bei denen "offiziell" nicht bedeutet, daß ein
> Compiler es so macht, sondern daß es im Standard so drinsteht.

Das war doch schon immer ein Problem. Der ISO-Standard hat eine 
unbraucbare Spielzeugsprache standardisiert, und die nachfolgende 
Balkanisierung durch Compiler-spezifische Erweiterungen war einer der 
Gründe, wieso Pascal heute ein Nischendasein führt.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Was Jörg wohl meint ist daß per Compiler-Switch die Haupteigenschaft von
> const ins Gegenteil verkehrt wird. Man hätte ja einfach das (eh an
> anderer Stelle benutzte) Schlüsselwort static dafür benutzen können.

Ja, genau das war meine Idee. Man hätte es als
  var
    static once: Boolean = False;

stattdessen definieren können. Das liest sich auf jeden Fall intuitiver, 
als eine "Konstante" nachher zu modifizieren. ;-)

Ja, Unit-Variable würde auch gehen, widerspricht allerdings dem 
Grundprinzip, Daten so lokal (vom Scope her) zu halten wie möglich. 
Damit gehört sie nun mal in die "*click"-Prozedur. Das hilft, besser die 
Übersicht zu bewahren, denn die Unit kann bei einem größeren GUI dann 
schon mal einige Lines of Code umfassen.

Das heißt auch nicht, dass ich nicht damit leben kann, fand es nur wenig 
intuitiv.

> Zumal man auch so den vielbeschworenen Delphi-Standard verlässt.

Wobei sich die Frage stellt, warum Delphi-Nutzer sowas wohl vermeintlich 
nicht brauchen könnten … aber das soll nicht unser Problem sein. ;-)

: Bearbeitet durch Moderator
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ja, genau das war meine Idee. Man hätte es als
>   var
>     static once: Boolean = False;

Das wäre aber eine unpascalische Grammatik. Eher schon so:
var
  once: Boolean = False; static;

oder schöner und maximal konsequent:
procedure Blub;
var
  foo: Integer;
  bar: Double;
static
  once: Boolean;

begin

end;

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> static
>   once: Boolean;

Ja, das wäre wohl die sinnvollste Variante.

Egal, nachdem man's weiß, kann man das mit der modizierten Konstante 
schon so machen. "Is' eben so."

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ja, Unit-Variable würde auch gehen, widerspricht allerdings dem
> Grundprinzip, Daten so lokal (vom Scope her) zu halten wie möglich.

Das Grundprinzip ist, lokale Variablen in einer Prozedur nur für die 
Dauer der Ausführung dieser Prozedur zu halten. Deswegen macht Pascal ja 
ein ordentliches Speichermanagement.

Wenn du die Variable auch nach Verlassen der Prozedur behalten willst, 
dann packe sie als private Variable in die Unit.

Meiner Erfahrung nach ist es bei Konstanten besser, sie im Kopf der Unit 
zu definieren, da man dann bei Änderungen alle Konstanten zusammen hat 
und nicht die Prozeduren nach ihnen durchsuchen muss.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> var
>   foo: Integer;
>   bar: Double;
> static
>   once: Boolean;

Jetzt ersetze static noch durch const und mache die Zuweisung und Du 
hast genau das, was seit Jahrhunderten schon funktioniert.

Ob das static oder const heisst... mich hat am Anfang bei Basic auch 
verwirrt, wieso eine Variable statisch sein soll.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:

> Das Grundprinzip ist, lokale Variablen in einer Prozedur nur für die
> Dauer der Ausführung dieser Prozedur zu halten. Deswegen macht Pascal ja
> ein ordentliches Speichermanagement.

Der letzte Satz hat so einfach gar keinen Sinn (weil es keine besondere 
Eigenschaft von Pascal ist, sondern von lokalen Variablen jedweder 
Programmiersprache, die ein solches Konzept überhaupt hat).

> Wenn du die Variable auch nach Verlassen der Prozedur behalten willst,
> dann packe sie als private Variable in die Unit.

Nein, ich lass sie in der Prozedur, denn dort gehört sie logisch hin 
(narrowing of scope). Niemanden sonst in der Unit geht sie etwas an.

> Meiner Erfahrung nach ist es bei Konstanten besser

Es ist ja eben gar keine Konstante.

Autor: Roland F. (rhf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Karl K. schrieb:
> Meiner Erfahrung nach ist es bei Konstanten besser, sie im Kopf der Unit
> zu definieren, da man dann bei Änderungen alle Konstanten zusammen hat
> und nicht die Prozeduren nach ihnen durchsuchen muss.

Würde denn bei einer Definition auf Unit-Ebene nicht auch alle anderen 
Funktionen b.z.w. Prozeduren diese Variable benutzen können? Wäre das 
dann nicht so was wie eine globale Variable in C?
Static in C bedeutet ja, das die Variable das Ende der Funktion, in der 
sie definiert ist überlebt und auch nur in dieser Funktion bekannt ist.

rhf

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roland F. schrieb:
> Wäre das dann nicht so was wie eine globale Variable in C?

Es wäre wie "static" auf Toplevel in C: modulintern, aber ja, jeder im 
Modul (in der Unit) kann sie benutzen. Daher mag ich diese Variante auch 
nicht so.

(Dass das Schlüsselwort "static" in C unglücklich in seiner 
Doppelbedeutung ist, hat auch Dennis Ritchie bekannt, darüber muss man 
jetzt und hier nicht weiter diskutieren.)

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roland F. schrieb:
> Würde denn bei einer Definition auf Unit-Ebene nicht auch alle anderen
> Funktionen b.z.w. Prozeduren diese Variable benutzen können?

Ja. Allerdings ist es mir noch nie passiert, dass eine Prozedur einfach 
mal so eine Variable benutzt, wenn ich das nicht hingeschrieben habe.

Speichertechnisch ist das egal. Ich machs mal für den AVR, da schaue ich 
immer mal in den erzeugten Code und weiss daher was der Compiler macht:

var global: Wird im Speicher direkt addressiert, schneller Zugriff.
const global: Wird direkt im Code eingesetzt.
var lokal: Wird
- als Register verwendet, schneller Zugriff, nach Ende der Prozedur 
wieder frei.
- auf den Heap gepackt, wenn keine Register mehr frei sind, langsamerer 
Zugriff als var global, weil Adresse berechnet wird. Nach Ende der 
Prozedur wieder frei.
const lokal: Wird direkt im Code eingesetzt.
const lokal mit Zuweisung = "static": Wird im Speicher adressiert. Geht 
ja nicht anders.

Eine "static" Variable mit const lokal in der Prozedur definiert verhält 
sich speichertechnisch genauso wie eine globale Variable.

Natürlich kann man eine "static" Variable lokal mit const in der 
Prozedur definieren, wo ist das Problem?

Autor: Roland F. (rhf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Jörg W. schrieb:
> Es wäre wie "static" auf Toplevel in C: modulintern, aber ja, jeder im
> Modul (in der Unit) kann sie benutzen. Daher mag ich diese Variante auch
> nicht so.

Dann habe ich das richtig verstanden, ich teile deine Abneigung.


> (Dass das Schlüsselwort "static" in C unglücklich in seiner
> Doppelbedeutung ist, hat auch Dennis Ritchie bekannt, darüber muss man
> jetzt und hier nicht weiter diskutieren.)

Ja, das war eine echte Fehlentscheidung, aber du hast recht, das ist 
hier nicht das Thema.

rhf

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Speichertechnisch ist das egal.

Das hat auch keiner in Abrede gestellt. Eine statische Variable braucht 
logischerweise statischen Speicherplatz, den kann sie natürlich nicht 
auf dem Stack bekommen.

> wo ist das Problem?

Dass es eben etwas widersinnig anmutet, ein Objekt, welches als "const" 
bezeichnet worden ist, hernach verändern zu können und zu dürfen.

Aber das ist jetzt ausreichend durchgekaut worden, es hatte sich halt 
mal jemand entschlossen, das genau so zu implementieren, nun ist es 
einfach so.

Autor: Roland F. (rhf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Karl K. schrieb:
> Ja. Allerdings ist es mir noch nie passiert, dass eine Prozedur einfach
> mal so eine Variable benutzt, wenn ich das nicht hingeschrieben habe.

Das glaube ich dir, aber es widerspricht doch der allgegenwärtigen 
Forderung Variablen (oder allgemein Daten) nur dort sichtbar werden zu 
lassen wo sie benötigt werden. In diesem Fall finde ich die 
Vorgehensweise bei C besser.

> Natürlich kann man eine "static" Variable lokal mit const in der
> Prozedur definieren, wo ist das Problem?

Mich stört "const". Wenn etwas als "const" definiert ist, würde ich 
erwarten, das es nicht mehr veränderbar ist. Aber wenn das so in 
Free-Pascal  so vereinbart ist muss man das eben akzeptieren.

rhf

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man mehr als nur einen solchen Drehknopf auf dem Form hat und seine 
Zusatzmethode samt eigenem State für jeden davon implementieren will 
(und dafür nicht extra eine neue Komponente vom Drehknopf ableiten und 
in der IDE registrieren will) kann es auch sinnvoll sein eine kleine 
Hilfsklasse zu schreiben die man genausooft instantiiert wie man 
Drehknöpfe hat, jeder davon eine Referenz auf den echten Drehknopf 
mitgeben und dann dort in seiner TDrehknopfHelper-Klasse den ganzen 
zusätzlichen State und Hilfsmethoden unterzubringen.

(Aber nicht verwechseln mit class helper, denn letztere können keine 
zusätzlichen Felder speichern sondern sind im Wesentlichen nur 
Syntax-Zucker)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, wäre eine Variante. Ist mir gerade zu aufwändig, ich habe ja ohnehin 
auch nur einen Knopp.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ist mir gerade zu *aufwändig*

Und es lohnt sich bei der Arbeit mit Lazarus sich als erstes folgende 
Tastenkürzel in Fleisch und Blut übergehen zu lassen, so lange bis man 
sie reflexartig und ohne Nachdenken benutzt:

(In absteigender Reihenfolge der Wichtigkeit, also oben anfangen mit dem 
Eintrainieren)
* Ctrl-Shift-C (Codegenerator)
  Wenn man gerade auf der Methodendeklaration im Interface ist 
  implementiert das unten die Methode und springt dort hin und setzt 
  den Cursor zwischen begin und end;

  Wenn man gerade unten eine neue Methode implementiert hat dann
  fügt es oben eine passende Deklaration ein.

  Wenn man gerade die Methodensignatur im Interface geändert hat passt es 
  automatisch die Signatur unten in der Implementation entsprechend an.

  Wenn man gerade die Methodensignatur in der Implementation geändert hat
  passt es automatisch die Signatur oben im Interface entsprechend an.

* Ctrl-Shift-Up
  Springt von Interface zur Implementation und umgekehrt. 
  Sehr nützlich wenn man per Ctrl-Klick einem Methodenaufruf gefolgt
  ist, dabei im Interface landet und jetzt die Implementation sehen will,
  spart viel Scrollerei.

* Ctrl-Klick
  Folgt einem Methodenaufruf, springt zur Deklaration derselben
  (danach Ctrl-shift-up und man ist bei der Implementation)

* Ctrl-H
  Springt wieder zurück wo man hergekommen ist.

* F2 
  Bezeichner unter dem Cursor umbenennen, semantik-bewußt.

* F12
  Bringt das Formular in den Vordergrund in dessen Unit man sich 
  gerade befindet

* Shift-F9
  Kompilieren und sofort mit dem Cursor zum ersten Fehler springen
  (durch die rasende Kompiliergeschwindigkeit ist es beim Refactorn
  schneller sich vom Compiler von Baustelle zu Baustelle leiten zu
  lassen als diese Stellen von Hand anzunavigieren)

: Bearbeitet durch User
Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roland F. schrieb:
> Das glaube ich dir, aber es widerspricht doch der allgegenwärtigen
> Forderung Variablen (oder allgemein Daten) nur dort sichtbar werden zu
> lassen wo sie benötigt werden. In diesem Fall finde ich die
> Vorgehensweise bei C besser.

Nochmal: Du darfst gern eine "static" Variable mit const direkt im 
Prozedurkopf anlegen.

Mit dem Argument - und das fiel hier im Forum schon - könntest du auch 
das Anlegen von Variablen im Prozedurkopf bei Pascal kritisieren, weil 
man sie in C direkt am verwendeten Ort - z.B. einer for-Schleife - 
anlegen kann.

Andererseits ist sowohl die Bezeichnung "static" für den Uneingeweihten 
verwirrend als auch, dass eine static Variable im laufenden Code 
angelegt und initialisiert wird, wo sie zwar bei jedem Prozeduraufruf 
"überlaufen", aber dennoch nur beim ersten Mal angelegt und initalisiert 
wird. Wer das nicht kennt, denkt sich auch: Häh, hier wird jedesmal eine 
foo = 100 zugewiesen?

Das stört dich nur nicht, weil du das so gewohnt bist. Das ist halt so 
gewachsen.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Häh, hier wird jedesmal eine foo = 100 zugewiesen?

Ist ja bei der „modifizierten Konstanten“ nicht anders … irgendwie 
muss man ja auch einen Initialwert in eine nicht-volatile Variable 
reinbekommen können.

> Mit dem Argument - und das fiel hier im Forum schon - könntest du auch
> das Anlegen von Variablen im Prozedurkopf bei Pascal kritisieren, weil
> man sie in C direkt am verwendeten Ort - z.B. einer for-Schleife -
> anlegen kann.

Stimmt schon, aber das zu ändern, lässt die Pascal-Syntax schlicht nicht 
zu. Wenn überhaupt, dann müsste man "const" und "var" innerhalb von 
begin/end-Blöcken neu verwenden dürfen, das wäre dann das Äquivalent von 
block-internen Variablen, wie sie auch schon vor C99 nicht gingen.

Ich wollte jetzt auch nicht an der Pascal-Syntax rummäkeln, sondern 
hatte mich nur ein wenig gewundert, dass für so ein ja durchaus 
alltägliches Problem keine elegantere Lösung als das Modifizieren einer 
Konstanten existiert.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ist ja bei der „modifizierten Konstanten“ nicht anders … irgendwie
> muss man ja auch einen Initialwert in eine nicht-volatile Variable
> reinbekommen können.

Häh?

Ich nehm mal schnell das Beispiel aus Wikipedia:

static int summe = 100; // Variable wird beim ersten Durchlauf der 
Deklaration initialisiert.
    summe += 1; => 101, 102, 103...

vs

int summe = 100; // Variable wird beim jedem Durchlauf der Deklaration 
initialisiert.
    summe += 1; => 101, 101, 101...

Da ist mir die Schreibweise in Pascal mit der einmaligen Initialisierung 
im Prozedurkopf logischer.

Btw: In Freepascal geht auch

var
  summe : int = 100;

im Kopf, da wird summe jedesmal beim Prozeduraufruf neu angelegt und mit 
100 initialisiert.

vs.

const
  summe : int = 100;

Hier ist summe wieder "static" mit Startwert 100.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Da ist mir die Schreibweise in Pascal mit der einmaligen Initialisierung
> im Prozedurkopf logischer.

Kannst du doch in C auch haben. Keiner zwingt dich, die Variablen 
zwischendrin anzulegen … wenn du ganz klassisches C wie zu Zeiten der 
Herren Kernighan und Ritchie hast, stehen die Variablendefinitionen auch 
alle im Prozedurkopf.

Also
  const
     foo : Integer = 42;

  begin
     if foo = 42 then begin
       foo = 23;
       writeln('first time')
     end
  end
ist doch nun wirklich nichts anderes als
  static int foo = 42;

  if (foo == 42) {
    foo = 23;
    puts("first time");
  }

Aber ich wollte hier keinen Vergleich Pascal vs. C. Ich möchte eine 
Qt-App nach FPC/Lazarus portieren.

: Bearbeitet durch Moderator
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Und es lohnt sich bei der Arbeit mit Lazarus sich als erstes folgende
> Tastenkürzel in Fleisch und Blut übergehen zu lassen

Bin eigentlich überhaupt nicht der große Freund von „In dieser IDE musst 
du dies und in jener jenes machen“ (und ich finde den Editor von Lazarus 
auch nicht gerade schön bedienbar), aber auf jeden Fall danke für die 
Hinweise. Mal sehen, ob mir diese Tastenkürzel hilfreich werden.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> und ich finde den Editor von Lazarus
> auch nicht gerade schön bedienbar

Wenn Du auf das "über Zeilenende hinaus scrollen" anspielst, das kann 
man abschalten, der lässt sich so konfigurieren daß er sich vollkommen 
normal anfühlt.

Aber die Codeintelligenz geht halt schon sehr weit bei Lazarus und die 
Einsicht die er in die Sprache hat ist sehr tief, tiefer als bei jedem 
anderen Editor und das hilft massiv bei dem ganzen Pascal-Boilerplate, 
der kann Dir viel Tipparbeit abnehmen.

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Wenn Du auf das "über Zeilenende hinaus scrollen" anspielst, das kann
> man abschalten, der lässt sich so konfigurieren daß er sich vollkommen
> normal anfühlt.

Hatte gesucht und nichts gefunden: wo denn?

Ja, das stört mich eigentlich am meisten. Ich glaube mich zu erinnern, 
dass Turbo* sich auch so benommen hat, möglicherweise soll es ja dazu 
bug-kompatibel sein.

Auch das Tab-Handling ist irgendwie nicht toll: wenn ich mitten in einem 
Wort einen Tab drücke, will ich doch mit an Sicherheit grenzender 
Wahrscheinlichkeit nicht das aktuelle Wort zerpflücken, sondern wohl 
eher die Zeile neu einrücken. Aber vermutlich bin ich da einfach zu sehr 
Emacs-vorgeschädigt. ;-) Andere IDEs sind da aus meiner Sicht auch nur 
anders blöd benutzbar, egal ob nun Visual Studio mit seinen Ablegern, 
Creator von Qt oder Eclipse. Trotzdem hat natürlich für ein komplexes 
Framework wie Qt oder FPC das "inhärente Wissen" dieser IDEs um die 
Interna des Frameworks schon was, deshalb benutze ich es ja auch, und 
editiere hier mal nicht mit dem Emacs. :)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie erzeuge ich eigentlich ein Popup-Fenster, bspw. für das übliche Help 
-> About? Finde irgendwie nicht die passende Klasse, wenn man nach Popup 
sucht, kommt man immer irgendwie bei Popup-Menüs raus oder bei der IDE 
selbst.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, MessageBox scheint's zu sein … danke fürs Zuhören. :-)

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roland F. schrieb:

>> Natürlich kann man eine "static" Variable lokal mit
>> const in der Prozedur definieren, wo ist das Problem?
>
> Mich stört "const". Wenn etwas als "const" definiert
> ist, würde ich erwarten, das es nicht mehr veränderbar
> ist.

Ja... "const" erzeugt keine Konstante, sondern eine
vorbelegte Variable. Unlogisch.


> Aber wenn das so in Free-Pascal  so vereinbart
> ist muss man das eben akzeptieren.

Ich mag mich täuschen, aber meiner Meinung nach geht
dieser Widersinn mindestens bis auf TurboPascal zurück.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Aber die Codeintelligenz geht halt schon sehr weit bei Lazarus und die
> Einsicht die er in die Sprache hat ist sehr tief, tiefer als bei jedem
> anderen Editor und das hilft massiv bei dem ganzen Pascal-Boilerplate,
> der kann Dir viel Tipparbeit abnehmen.

Ich glaub, du hast noch nie QtCreator benutzt. Dort ist die 
Sprach-Integration weit fortgeschritten...

Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Wenn Du auf das "über Zeilenende hinaus scrollen" anspielst, das kann
> man abschalten, der lässt sich so konfigurieren daß er sich vollkommen
> normal anfühlt.
Gehts um die "unendlichen" Leerzeichen in jeder Zeile?
Mich hat das anfangs auch gestoert, aber es hat auch echt Vorteile beim 
Navigieren des Cursors mit den Pfeiltasten, weil er dann nicht an den 
Zeilenenden hin- und herspringt. Pos1 und Ende verwendet man sowieso 
dauernd, dann ist das mit den erweiterten Zeilen m.E. keine 
Einschraenkung.

Ist halt auch wie mans gewohnt ist. Andererseits, Einheitlichkeit 
zwischen benutzten IDEs/Editoren ist in so einem Fall wohl wichtiger wie 
die Funktionalitaet selbst.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Egon D. schrieb:
> Ja... "const" erzeugt keine Konstante, sondern eine vorbelegte Variable.
> Unlogisch.

Ist allerdings bei C auch so, ist genauso unlogisch. Pascal hätte 
eigentlich echte Konstanten, vom Sprachstandard her sind sie es.

Sven P. schrieb:
> Ich glaub, du hast noch nie QtCreator benutzt.

Ich würde das als vergleichbar ansehen. (Schließlich habe ich die 
Qt-App, die ich gerade portiere, ja vorher mal damit gebaut.)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maxe schrieb:

> Gehts um die "unendlichen" Leerzeichen in jeder Zeile?

Ja, vor allem.

> Mich hat das anfangs auch gestoert, aber es hat auch echt Vorteile beim
> Navigieren des Cursors mit den Pfeiltasten, weil er dann nicht an den
> Zeilenenden hin- und herspringt.

Genau das empfinde ich aber als großen Nachteil. Ich erwarte einfach, 
dass man am Anfang der Zeile mit einem Linksschritt ans Ende der 
vorherigen Zeile rutscht.

> Pos1 und Ende verwendet man sowieso
> dauernd

Verwende ich so gut wie nie.

Wie schon geschrieben, wenn sich dieses Verhalten abstellen ließe, dann 
wäre mir das schon eine Hilfe.

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wie schon geschrieben, wenn sich dieses Verhalten abstellen ließe, dann
> wäre mir das schon eine Hilfe.

Editor - Kontextmenü - Einstellungen
dann
Editor allgemein - Caret - Über das Zeilenbende hinausscrollen 
wegklicken

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Wie schon geschrieben, wenn sich dieses Verhalten abstellen ließe, dann
> wäre mir das schon eine Hilfe.

Tools|Options -> Editor|General|Cursor: "Caret past end of line"

Der Options-Dialog ist im Laufe der Zeit so umfangreich und damit 
unübersichtlich geworden daß er eine Suchfunktion bekommen hat, die 
hilft es etwas schneller an gesuchte Einstellungen heranzukommen.

: Bearbeitet durch User
Autor: Carl D. (jcw2)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Egon D. schrieb:
>> Ja... "const" erzeugt keine Konstante, sondern eine vorbelegte Variable.
>> Unlogisch.
>
> Ist allerdings bei C auch so, ist genauso unlogisch.

Es geht aber weniger um die Frage, ob es in bestimmten Architekturen so 
implementiert ist, daß man es über halbseidene Tricks hinbekommt, die 
Konstante zu verändern, sonder darum, daß das als valide Konstruktion 
angesehen wird.
Versuch mal eine Konstante zu überschreiben, die der Arm-GCC in den 
Flash platziert hat. Nur (nicht exklusiv) beim AVR gibt es "variable 
Konstanten", weil die Hardware nicht zum Speichermodell von C paßt.
Und selbst im Flash könnte nun jemand sagen, kann man den Wert ändern. 
Richtig, aber: "easy to use right and hard to use wrong". Änderbare 
Konstanten sind das Gegenteil davon.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Ist allerdings bei C auch so

const heißt in C aber auch nicht "Konstante", sondern nur, daß man diese 
Variable nicht programmatisch beschreibt. Ändern kann sie sich trotzdem 
(insbesondere in Verbindung mit volatile natürlich), nur nicht 
programmatisch.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ist allerdings bei C auch so, ist genauso unlogisch. Pascal hätte
> eigentlich echte Konstanten, vom Sprachstandard her sind sie es.

Pascal hat schon echte Konstanten. Wenn ich es so schreibe:
const
  a=2;
  b=2.5;
  c='abc';
dann sind es echte Konstanten, die ich auch nicht mehr verändern kann. 
Im Zusammenhang mit einer Typdefinition verhält sich const halt etwas 
anders. Das muß man eben einfach lernen und das ist auch eine kleine 
Stolperfalle die Pascal bereit hält. In Procedur-/Funktionsköpfen hat 
das const die Bedeutung, das der betroffene Parameter optional ist. 
Beispiel:
procedure xy(a:integer; const b:integer=1);
begin
  ...
end;
Dies bedeutet das der Parameter b optional ist, d.h. ich muß ihn bei der 
Übergabe nicht belegen. In diesem Falle würde er mit 1 belegt werden. 
Ich nutze das gern, wenn ich eine Procedure/Function im Nachgang 
erweitere und nun nicht an allen Aufrufstellen eine Anpassung vornehmen 
möchte. Ohne Parameter b verhält sich die Procedure wie bisher.
Eine Auswirkung hat dieses const im Procedurkopf jedoch. Innerhalb der 
Procedur wird b wie eine Konstante behandelt, d.h. ich kann es dort 
nicht ändern.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeno schrieb:

> Ich nutze das gern, wenn ich eine Procedure/Function im Nachgang
> erweitere und nun nicht an allen Aufrufstellen eine Anpassung vornehmen
> möchte.

Das gibt's in C++ auch und ist IMO ein Antipattern. Man kann nämlich 
dann nicht mehr merken, ob beim Hinzufügen eines neuen Aufrufes einfach 
ein Parameter vergessen wurde. Besonders lustig, wenn in der Mitte ein 
Parameter fehlt und alle anderen eins aufrücken, das führt zu 
Debugging-Spaß.

Autor: Carl D. (jcw2)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Nop schrieb:
> Zeno schrieb:
>
>> Ich nutze das gern, wenn ich eine Procedure/Function im Nachgang
>> erweitere und nun nicht an allen Aufrufstellen eine Anpassung vornehmen
>> möchte.
>
> Das gibt's in C++ auch und ist IMO ein Antipattern. Man kann nämlich
> dann nicht mehr merken, ob beim Hinzufügen eines neuen Aufrufes einfach
> ein Parameter vergessen wurde. Besonders lustig, wenn in der Mitte ein
> Parameter fehlt und alle anderen eins aufrücken, das führt zu
> Debugging-Spaß.

Ich glaube, ich werde mir keine weiteren Details von Pascal mehr 
anschauen, sondern mir das für den Fall aufbewahren, daß mal wieder 
jemand anderen Sprache "Undurchschaubarkeit" vorwirft. Das ist hier 
nicht besser, sondern im besten Fall anders. Konstantoptionalstatische 
Variablen. Cool.

Autor: Klimatester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeno schrieb:
> In Procedur-/Funktionsköpfen hat das const die Bedeutung, das der
> betroffene Parameter optional ist. Beispiel:procedure xy(a:integer;
> const b:integer=1);
> begin
>   ...
> end;
>  Dies bedeutet das der Parameter b optional ist, d.h. ich muß ihn bei
> der Übergabe nicht belegen. In diesem Falle würde er mit 1 belegt
> werden. Ich nutze das gern, wenn ich eine Procedure/Function im Nachgang
> erweitere und nun nicht an allen Aufrufstellen eine Anpassung vornehmen
> möchte. Ohne Parameter

Das

Zeno schrieb:
> In Procedur-/Funktionsköpfen hat das const die Bedeutung, das der
> betroffene Parameter optional ist. Beispiel:procedure xy(a:integer;
> const b:integer=1);
> begin
>   ...
> end;
>  Dies bedeutet das der Parameter b optional ist, d.h. ich muß ihn bei
> der Übergabe nicht belegen. In diesem Falle würde er mit 1 belegt
> werden. Ich nutze das gern, wenn ich eine Procedure/Function im Nachgang
> erweitere und nun nicht an allen Aufrufstellen eine Anpassung vornehmen
> möchte. Ohne Parameter b verhält sich die Procedure wie bisher.

Das hat nichts mit "const" zu tun. Es funktioniert genauso ohne "const". 
=1 ist hier der default Wert des optionalen Parameters.


> Eine Auswirkung hat dieses const im Procedurkopf jedoch. Innerhalb der
> Procedur wird b wie eine Konstante behandelt, d.h. ich kann es dort
> nicht ändern.

Das ist korrekt.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat schon jemand ungetypte Parameter erwähnt?
procedure TakeAnything(const C);

oder Variant Open Array Parameters?
procedure DoSomething(A: array of const);

Dieses Schlüsselwort ist sowas wie der Rote Knopf auf der Fernbedienung, 
je nachdem wo man es verwendet hat es eine vollkommen andere Bedeutung. 
Ich würde mich nicht so sehr daran festbeißen daß es "const" heißt, das 
lässt sich heute leider nicht mehr ändern.

Man benutzt es (mindestens)

* Zur Deklaration von Konstanten
* Zur Deklaration von "statischen" Variablen in Prozeduren
* Für konstante Funktionsargumente
* Für ungetypte Funktionsargumente (ungefähr wie void*)
* Für Open Variant Arrays (Sowas wie variadic function arguments)

Hab ich jetzt noch was vergessen?

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Hab ich jetzt noch was vergessen?

Ja: das Ziel dieses Threads. :-)

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ja: das Ziel dieses Threads.

Also ganz ehrlich: Wenn du ernsthaft vorhast mit Pascal weiterzumachen, 
dann frag im Lazarusforum. Da gibt es von Leuten die das seit Jahren 
einsetzen zielgerichtete, schnelle und fundierte Antworten.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:

> Tools|Options -> Editor|General|Cursor: "Caret past end of line"

Danke (auch an Andreas), fühlt sich jetzt schon viel besser an.

"Caret" als Name für den Cursor kannte ich allerdings auch noch nicht.

> Der Options-Dialog ist im Laufe der Zeit so umfangreich und damit
> unübersichtlich geworden daß er eine Suchfunktion bekommen hat

:-)

Autor: W.S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Pascal scheint nach wie vor keine wirklichen statischen Variablen
> innerhalb von Funktionen/Prozeduren zu kennen. Stattdessen eine
> Konstante zu definieren, die man dann innerhalb der Prozedur aber
> verändern darf, ist schon ein heftiger Hack. (Braucht man an dieser
> Stelle, um im Eventhandler des Knopfes zu wissen, welcher Wert beim
> letzten Aufruf übergeben worden war.)

Moment mal.. Redest du von Funktionen oder Methoden?

Also, dein Knopf dürfte mMn. ein Objekt sein. Das hat Properties, innere 
Variablen und Methoden - und es dürfte persistent sein. Problem 
eigentlich erledigt.

Verstehe mal, daß du es hier mit Objekten zu tun hast. Vielleicht hilft 
es dir, wenn du all diese Ereignis-Prozeduren, mit denen du es beim 
Benutzen dieser Objekte zu tun hast, als eine Art Callback-Routinen 
begreifst. Das ist eben NICHT der Event-Handler des Knopfes, sondern 
eine Routine, die der Event-Handler dieses Knopfes oder eines anderen 
Knopfes aufrufen kann, wenn du diese Routine in die Liste des 
betreffenden Knopfes einträgst. Deine Routine soll NICHT sich intern 
irgendwelches Zeugs merken wollen. Wenn es etwas zu merken gibt, dann 
merkst du dir das in deinem Haupt-Objekt, also da:

 TMainForm = class(TForm)
 ...;
was dein eigentliches Fenster ist. Und zum Merken von irgendwas dient 
dort der Abschnitt 'private'. Typisches Beispiel: Maus ziehen. Besteht 
aus Maus down, dann move, dann up. Kann (nicht muss) aus 3 verschiedenen 
OnEvent-Routinen bestehen. Keine davon merkt sich was intern, sondern 
Startposition plus ggf. Knopf-Info in MainForm - schließlich brauchen es 
die anderen 2 Routinen ja zum Funktionieren.

So..

Ich hab mir mal dein Bild angeschaut - das sieht eigentlich so aus, daß 
du es fast 1:1 mit Delphi/Lazarus abbilden kannst.

Das Einzige, was wohl nicht im Standard-Repertoire ist, ist der 
Drehknopf. Aber der sieht so simpel aus, daß man ihn mit irgend einer 
Standard-Komponente selber zeichnen kann, die einen frei benutzbaren 
Canvas enthält. Allerdings macht der halbmondförmige Schatten etwas 
Arbeit, wenn man ihn zu Fuß ohne eine passende Grafik realisieren will.

Die Funktionalität macht man dann mit den diversen OnEvent-Handlern 
(OnMouseDown usw.). Das sollte kein Thema sein und es entbindet dich 
davon, Lib's von anderen Leuten heranziehen zu müssen.


Nun zum Aussehen:

Müssen die Bezeichnungen deiner Paneele separat oberhalb der Paneele 
stehen, oder geht es auch so, daß die Bezeichner in die Umrandung 
eingefügt sind? Ersteres geht mit Labels und captionlosen Paneelen, 
letzteres mit normalen Paneelen, die ne 'caption' haben. Ich häng dir 
mal ein mittlerweile 7 Jahre altes Beispiel hier dran. Da siehst du die 
Paneele mit Bezeichnungen im Paneel-Rahmen. Und für deine Marker gibt es 
dort auch eine Entsprechung. Frequenz ziehen mit linker MT im Screen, 
Zoom-IN mit Ziehen rechte MT (von..bis). Störe dich nicht am fehlenden 
Gerät am USB, hier geht's ja nur um das Aussehen.

Die Schiebeknöpfe (Span, Reference, Markers) sind auch keine üblichen, 
also gibt's auch da noch was zu tun oder anders zu machen. Sind die nur 
vor-nix-rück oder analog wie bei Yokogawa?

Was ist das für eine Greif-Zeile oben direkt unterhalb der Menüleiste?

W.S.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> "Caret" als Name für den Cursor kannte ich allerdings auch noch nicht.

Als Unterscheidung zum Mauscursor. Allerdings ist die Verwendung 
inkonsistent, da manchmal auch der Textcursor als Cursor bezeichnet 
wird. Je nachdem, wer gerade den Teil der Übersetzung gemacht hat 
wahrscheinlich.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:

> Also, dein Knopf dürfte mMn. ein Objekt sein. Das hat Properties, innere
> Variablen und Methoden - und es dürfte persistent sein. Problem
> eigentlich erledigt.

Ist es, aber ich fang' jetzt nicht an, das Objekt zu subclassen. Wurde 
ja schon vorgeschlagen, aber ist mir für das bisschen Gimmick den 
Aufwand nicht wert.

Das ist ja mittlerweile ohnehin gelöst, die "modifizierbare Konstante" 
ist zwar nicht intuitiv, aber sie tut, was ich davon will. конец.

> Ich hab mir mal dein Bild angeschaut - das sieht eigentlich so aus, daß
> du es fast 1:1 mit Delphi/Lazarus abbilden kannst.

So weit waren wir ja schon zu Anfang des Threads. :-)

Ich hatte da eigentlich auch keine großen Zweifel, daher habe ich mir 
auch dieses Projekt als Beispiel rangezogen.

> Das Einzige, was wohl nicht im Standard-Repertoire ist, ist der
> Drehknopf.

BGRAControls, wurden schon vorgeschlagen, sieht OK aus. Du bist bisschen 
spät dran im Thread. :)

> Nun zum Aussehen:
>
> Müssen die Bezeichnungen deiner Paneele separat oberhalb der Paneele
> stehen, oder geht es auch so, daß die Bezeichner in die Umrandung
> eingefügt sind?

Das ist eigentlich nicht wirklich wichtig, das werde ich wohl so 
umsetzen, wie es am einfachsten machbar ist.

Das UI soll geringfügig an das Bedienfeld des Tek492 erinnern, damit man 
sich möglichst schnell damit zurechtfindet, wenn man den Tek492 selbst 
besitzt und benutzt (nur in diesem Zusammenhang ist das Ganze sinnvoll).

> Die Schiebeknöpfe (Span, Reference, Markers) sind auch keine üblichen,
> also gibt's auch da noch was zu tun oder anders zu machen. Sind die nur
> vor-nix-rück oder analog wie bei Yokogawa?

Am Ende sind das einfache Scrollbars. Ich hatte da ursprünglich so 
drehknopfähliche Gebilde (wie man sie früher an Taschenradios hatte) aus 
qwt, aber der qwt-Code dafür war mir zu instabil. Die Scroller tun's 
auch, und da wird sich auch bei FPC schon was finden, da bin ich mir 
sicher.

Sieht analog aus, am Ende ist es natürlich digital: die Marker können ja 
lediglich eine der <N> Frequenzen der eingelesenen Messdaten anfahren 
und im Diagramm anzeigen, Zwischenwerte gibt es nicht.

> Was ist das für eine Greif-Zeile oben direkt unterhalb der Menüleiste?

Unnötiges Qt-Überbleibsel, in das man wohl irgendwelche Unterfenster 
eindocken kann. Unwichtig, kann weg.

: Bearbeitet durch Moderator
Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Carl D. schrieb:
> Ich glaube, ich werde mir keine weiteren Details von Pascal mehr
> anschauen, sondern mir das für den Fall aufbewahren, daß mal wieder
> jemand anderen Sprache "Undurchschaubarkeit" vorwirft.

Ach was. Für den normalen Gebrauch ist Pascal überhaupt nicht so 
undurchsichtig. Aber es bietet eben auch Bereiche für Ausdrücke an, die 
über das Gewöhnliche ziemlich hinausgehen. Das Arbeiten mit Set's zum 
Beispiel.

Aber um mit Delphi/Lazarus ordentliche Programme mit GUI zu machen, 
braucht man derartige Spezereien nicht wirklich.

Denk mal daran, was so alles in C an Zeugs möglich ist - und was davon 
man zum normalen Programmieren nicht wirklich braucht.

W.S.

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> die "modifizierbare Konstante"
> ist zwar nicht intuitiv, aber sie tut, was ich davon will. конец.

Eher nicht. Mir scheint, du bist auf dem falschen Dampfer, weil du 
Lazarus quasi gegen den Strich kämmen willst. Genau deshalb hab ich mich 
ja über das ganze Objekt- und OnEvent-Zeugs so ausgelassen. Also laß 
lieber bleiben, was du dir damit vorgenommen hast und mach es anders. 
Ohne persistente Variablen in einem OnEvent-Callback, denn das riecht 
nach Brechstange im Porzellanladen.

Und die analogen Yokogawa-Schiebe-Knöpfe sind keine Scrollbars, sondern 
quasi deren 1. Ableitung. Sie ändern also den Wert der assoziierten 
Eingabezeile proportional zur Auslenkung von ihrer Mitte. Je weiter man 
sie auslenkt, desto schneller ändert sich der Wert in der Eingabezeile. 
Läßt man sie los, schnipst der Knopf in Mittelstellung und die 
Eigabezeile bleibt stehen.

Sah mir so aus, deshalb die Frage.

W.S.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Die Scroller tun's
> auch, und da wird sich auch bei FPC schon was finden, da bin ich mir
> sicher.

Für Schiebregler eignet sich TTrackBar ganz gut anstelle von Scrollbars.

Für Eingabefelder von Integerwerten nehme ich meistens TSpinEdit, da 
kann man min und max festlegen und eine Schrittweite für das Mausrad.

Beide gehen schön mit dem Mausrad zu bedienen, Einfach drüberhalten 
(kein Klick nötig!) und am Rad drehen.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Karl K. schrieb:
> Also ganz ehrlich: Wenn du ernsthaft vorhast mit Pascal weiterzumachen,
> dann frag im Lazarusforum.

Lazarusforum ist zwar immer empfehlenswert (habe ich auch schon erwähnt) 
aber ich finde es auch durchaus OK wenn das auch mal exemplarisch hier 
in der Öffentlichkeit durchexerziert wird, der eine oder andere 
Unbeteiligte könnte es dadurch kennenlernen und bemerken daß er so ein 
Werkzeug eigentlich schon sein Leben lang gesucht und nie gefunden hat.

: Bearbeitet durch User
Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wie erzeuge ich eigentlich ein Popup-Fenster, bspw. für das übliche Help
> -> About? Finde irgendwie nicht die passende Klasse, wenn man nach Popup
> sucht, kommt man immer irgendwie bei Popup-Menüs raus oder bei der IDE
> selbst.

Jörg W. schrieb:
> Ah, MessageBox scheint's zu sein … danke fürs Zuhören. :-)

Hi Jörg

Du kannst aber auch jede "normale" Form als modalen Dialog anzeigen 
lassen:
type

  { TAboutForm }
     TAboutForm = class(TForm)
       Copyright1: TStaticText;
       Copyright2: TStaticText;    
       ...

Und zum anzeigen (Menu, ButtonClick oder Action)
  AboutForm.ShowModal;

Dann kannst Du Dich im Dialog auch etwas mehr austoben.

/regards

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:

> Eher nicht. Mir scheint, du bist auf dem falschen Dampfer, weil du
> Lazarus quasi gegen den Strich kämmen willst.

Kann sein, aber ganz ehrlich: für das bisschen Knopp mache ich jetzt 
keine weiteren Klimmzüge. Das Ding ist sowieso bloß eye-candy. Der hat 
mit dem BGRAKnob aus der Dose raus funktioniert, und praktisch genauso, 
wie ich das damals unter Qt gemacht habe.

> Und die analogen Yokogawa-Schiebe-Knöpfe sind keine Scrollbars, sondern
> quasi deren 1. Ableitung.

Ah ja, jetzt weiß ich, was du meinst. Nee, so aufwändig muss das nicht 
sein.

Bernd K. schrieb:
> Für Schiebregler eignet sich TTrackBar ganz gut anstelle von Scrollbars.

Kling gut, erstmal suchen … ich würde sagen, das ist exakt das, was ich 
dann auch unter Qt benutzt habe.

> Für Eingabefelder von Integerwerten nehme ich meistens TSpinEdit, da
> kann man min und max festlegen und eine Schrittweite für das Mausrad.

Habe ich jetzt auch schon bei der Frequenz gemacht, allerdings als 
TTIFloatSpinEdit, da ich dort eine Nachkommastelle haben möchte (auch, 
wenn der Tek492 das in natura nicht hat, der hat nur ganze MHz :).

Andreas H. schrieb:
> Du kannst aber auch jede "normale" Form als modalen Dialog anzeigen
> lassen:

Danke für den Hinweis, da komme ich vielleicht später mal drauf zurück.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
>> Ich nutze das gern, wenn ich eine Procedure/Function im Nachgang
>> erweitere und nun nicht an allen Aufrufstellen eine Anpassung vornehmen
>> möchte.
>
> Das gibt's in C++ auch und ist IMO ein Antipattern. Man kann nämlich
> dann nicht mehr merken, ob beim Hinzufügen eines neuen Aufrufes einfach
> ein Parameter vergessen wurde. Besonders lustig, wenn in der Mitte ein
> Parameter fehlt und alle anderen eins aufrücken, das führt zu
> Debugging-Spaß.

Bei einem richtig großen Projekt ist die Möglichkeit mehr als hilfreich. 
Die IDE zeigt mir doch den Procedur-/Funktionskopf an sobald ich die 
Funktion nutze. Da muß man einfach mal die Gedanken zusammen nehmen.Man 
darf auch für optionale Parameter Defaultwerte einsetzen, dann 
verschiebt sich nichts. Mache ich halt immer wenn ich einen Parameter 
"überspringen" muß.
Es ist viel aufwändiger im bestehenden Code die Parameter nachzurüsten. 
Die Gefahr das man sich dabei vertippt und und einen vom Defaultwert 
abweichenden Parameter eingibt, was dann natürlich zu einem völlig 
anderen Ergebnis führt. Dies zu debuggen ist mehr als auf wendig.
Bei C/C++ gibt es ganz andere Stolperfallen die ein gehörig auf die 
Fresse fallen lassen und noch viel schwieriger zu finden sind.
Wenn ich so eine Funktion mit optionalen Parametern benutze, dann tue 
ich das ganz bewußt. Ich hatte damit jedenfalls noch keine Probleme.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeno schrieb:

> Wenn ich so eine Funktion mit optionalen Parametern benutze, dann tue
> ich das ganz bewußt.

Du machst eine Funktion von nicht-optional mal eben zu einer mit 
optionalen Parametern. Die Benutzung, also die Aufrufe, hast Du aber 
vorher geschrieben, als die Funktion keine optionalen Parameter hatte.

> Ich hatte damit jedenfalls noch keine Probleme.

Dann mach so ein Vorgehen mal abseits von persönlichen 
Einmann-Hobbyprojekten, sondern im industriellen Einsatz mit 
Produktlebenszyklen von über zehn Jahren und immer wechselnden 
Programmierern.

Wenn man eine Funktion nicht mit der vorgesehenen Anzahl von Parametern 
aufruft, dann SOLL der Compiler sich beschweren. Stattdessen Geld für 
manuelles Debugging auszugeben ist unökonomisch.

Und ja, natürlich können die Parameter einfach eins aufrücken, solange 
sie typenkompatibel zum jeweils vorherigen Parameter sind. Das sieht für 
den Compiler nämlich genau wie eine "ganz bewußte"(tm) Benutzung dieses 
Antipatterns aus.

Und eigentlich war ein strenges Typensystem mal eine Stärke von Pascal. 
Also, bevor es mangels eines brauchbaren Standards z.T. einfach 
verbastelt wurde.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klimatester schrieb:
> Das hat nichts mit "const" zu tun. Es funktioniert genauso ohne "const".
> =1 ist hier der default Wert des optionalen Parameters.

Du hast recht. Ich hab's bisher immer mit const gemacht. Warum??????

Wieder etwas gelernt.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Dann mach so ein Vorgehen mal abseits von persönlichen
> Einmann-Hobbyprojekten, sondern im industriellen Einsatz mit
> Produktlebenszyklen von über zehn Jahren und immer wechselnden
> Programmierern.

Genau dort war das z.B. erforderlich weil bei einigen Berechnungen 
plötzlich zusätzlich Sonderfälle berücksichtigt werden mußten die zum 
Zeitpunkt der Programmerstellung (vor 15 Jahren) noch nicht absehbar 
waren und deshalb so auch nicht vorgesehen waren.
Mittlerweile sind auch völlig neue Produktkomponenten hinzugekommen, die 
zum damaligen Zeitpunkt noch nicht mal angedacht waren. Da ist es dann 
erforderlich bei der, ansonsten gleichen; Berechnung einen zusätzlichen 
Parameter zu berücksichtigen.
Normen ändern sich und plötzlich muß eine an einer Stelle die Berechnung 
etwas anders ausgeführt werden. Dann rufe ich an dieser einen Stelle die 
Funktion mit dem optionalen Parameter auf, während an allen anderen 
Stellen der Defaultwert bestehen bleibt. Ich muß also nur eine einzige 
Stelle im Sourcecode ändern um auf die Neuerung zu reagieren. Das ist 
für mich ein riesen Vorteil.

Nop schrieb:
> Stattdessen Geld für
> manuelles Debugging auszugeben ist unökonomisch.

An dieser Stelle mußte ich noch nie den Debugger bemühen.

Nop schrieb:
> Und ja, natürlich können die Parameter einfach eins aufrücken, solange
> sie typenkompatibel zum jeweils vorherigen Parameter sind. Das sieht für
> den Compiler nämlich genau wie eine "ganz bewußte"(tm) Benutzung dieses
> Antipatterns aus.

In der Regel ist es ein zusätzlicher optionaler Parameter, da rückt gar 
nichts auf. Und wenn es mal wirklich mehrere sein sollten ist das auch 
kein Problem. Da wird der Parameter der übersprungen werden muß halt mit 
dem Defaultwert belegt. Man sieht doch bei Benutzung der 
Prozedur/Funktion wie der Funktionskopf aussieht. Spätesten beim Testen 
der neuen Funktionalität bemerkt man den Fehler, weil dann ja nicht das 
erwartete Ergebnis herauskommt. Wenn da Debugging erforderlich werden 
sollte dann genau an der Stelle mit dem neuen Code, andere Stellen mußte 
ich ja nicht ändern.


Du mußt diese Möglichkeit ja nicht benutzen. Ich benutze es und hatte 
damit bisher keine Probleme.

Nop schrieb:
> Und eigentlich war ein strenges Typensystem mal eine Stärke von Pascal.
> Also, bevor es mangels eines brauchbaren Standards z.T. einfach
> verbastelt wurde.

Pascal hat immer noch ein strenges Typsystem. Dennoch hat sich auch 
Pascal weiter entwickelt. Die optionalen Parameter gibt es auch erst ab 
Delphi größer Version 1. Turbopascal, Borlandpascal und Delphi 1 z.B. 
kennen keine optionalen Parameter. Man wird seine Gründe für die 
Einführung dieses Features gehabt haben.

Nop schrieb:
> Das gibt's in C++ auch und ist IMO ein Antipattern.

Das ist halt der typische C/C++ Zeigefinger. Man benutzt Features die 
die Sprache hergibt, man schreibt validen Code etc. und es kommt 
bestimmt einer daher der Zeigefinger hebt und sagt "Das darfst Du 
nicht!". Solange es beim Kompilieren weder Warnings noch Fehler gibt muß 
es wohl im Sinne des Compiler valider Code sein. Es gibt keinen 
vernünftigen Grund die Features die eine Programmiersprache bietet auch 
zu nutzen.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeno schrieb:
> Es gibt keinen
> vernünftigen Grund die Features die eine Programmiersprache bietet auch >nutzen

Richtig:
Es gibt keinen
vernünftigen Grund die Features die eine Programmiersprache bietet nicht 
zu nutzen

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeno schrieb:
>> Das gibt's in C++ auch und ist IMO ein Antipattern.
>
> Das ist halt der typische C/C++ Zeigefinger.

Enough already. Bitte öffnet einen eigenen Thread dafür, vielleicht ja 
dann auch einen, der über Pascal und C++ hinaus geht …

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeno schrieb:

> Richtig:
> Es gibt keinen
> vernünftigen Grund die Features die eine Programmiersprache bietet nicht
> zu nutzen

Hatte mir schon gedacht, daß Du das meinst, und da sehe ich einen ganz 
grundsätzlichen Dissens.

Gute Coding-Richtlinien bestimmen eine Teilmenge dessen, was überhaupt 
benutzt werden darf, bzw. bei welchen Features ein zusätzliches Review 
verpflichtend ist. Du willst nämlich mit Sicherheit keine Codebasis 
warten, die vor sowas wie setjmp/longjmp nur so wimmelt.

Eine Programmiersprache ist nicht bloß dafür da, daß der Programmierer 
dem Computer mitteilt, was letzterer zu tun hat. Sie ist auch dafür da, 
daß man nachfolgenden Programmierern mitteilt, was man da gerade tut. 
Code wird nämlich wesentlich häufiger gelesen als geschrieben.

Insbesondere ist es praktisch notwendig, Leute einzubremsen, die 
glauben, ihre Kompetenz bemesse sich nach der Anzahl der Sprachfeatures 
in ihrem Code. Und ja, die gibt es.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
>> Für Schiebregler eignet sich TTrackBar ganz gut anstelle von Scrollbars.
>
> Kling gut, erstmal suchen … ich würde sagen, das ist exakt das, was ich
> dann auch unter Qt benutzt habe.

Gerade ausprobiert, ja, funktioniert soweit so, wie ich das dachte. 
Irgendwie bekomme ich beim Scrollrad allerdings immer 2er-Schritte, 
während ich mit manuellem Ziehen die einzelnen Werte erreiche.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Irgendwie bekomme ich beim Scrollrad allerdings immer 2er-Schritte,
> während ich mit manuellem Ziehen die einzelnen Werte erreiche.

Die "PageSize" bestimmt ja die Increments für PgUp-/PgDn-Taste (die ich 
logisch falsch herum zugeordnet finde: PgUp dekrementiert, PgDn 
inkrementiert den Wert), aber das Scrollrad scheint woanders festgelegt 
zu sein. Auch mit einer PageSize von 1 bekomme ich da immer noch 
2er-Schritte.

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Die "PageSize" bestimmt ja die Increments für PgUp-/PgDn-Taste (die ich
> logisch falsch herum zugeordnet finde: PgUp dekrementiert, PgDn
> inkrementiert den Wert)

Ne Jörg, das ist schon richtig so.

Auf dem Screen ist (meist) der Nullpunkt OBEN (!), links.
Wenn Du also in diese Richtung gehst dann wird der y-Wert kleiner.
PageUp kannst Du Dir einfach als n-mal CursorUp vorstellen.
Dann ist das auch bei einem Screen, der ja eigentlich keine Pages hat, 
wieder konsistent.

/regards

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Lazarusforum ist zwar immer empfehlenswert (habe ich auch schon erwähnt)
> aber ich finde es auch durchaus OK wenn das auch mal exemplarisch hier
> in der Öffentlichkeit durchexerziert wird, der eine oder andere
> Unbeteiligte könnte es dadurch kennenlernen und bemerken daß er so ein
> Werkzeug eigentlich schon sein Leben lang gesucht und nie gefunden hat.

Das ging mir so vor ca. einem Jahr und ich möchte es nicht mehr missen. 
:-)

Jörg: hattest Du auch mal die ue_controls angeschaut (oben verlinkt) Da 
sind die Knöpfe noch besser gemacht und dort sind auch mehr Elemente 
dabei, die Für Gerätesteuerungen nützlich sind.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Die "PageSize" bestimmt ja die Increments für PgUp-/PgDn-Taste (die ich
> logisch falsch herum zugeordnet finde: PgUp dekrementiert, PgDn
> inkrementiert den Wert)

Wir reden hier über ein TrackBar? Beim vertikalen Trackbar ist MinVal 
oben, MaxVal unten, Erklärung siehe Andreas H.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Enough already. Bitte öffnet einen eigenen Thread dafür, vielleicht ja
> dann auch einen, der über Pascal und C++ hinaus geht …

Ich werde mit NOP ganz geaiß nicht weiter über das Thema debattier - der 
Zeigefinger des Schulmeisters ist mir viel zu groß und da werden wir 
definitiv nicht auf einen Nenner kommen.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Jörg W. schrieb:
>> Die "PageSize" bestimmt ja die Increments für PgUp-/PgDn-Taste (die ich
>> logisch falsch herum zugeordnet finde: PgUp dekrementiert, PgDn
>> inkrementiert den Wert)
>
> Ne Jörg, das ist schon richtig so.

Ich empfinde es für den Anwendungszweck hier (bei dem ja keine 
Textseiten o.ä. "geblättert" werden) trotzdem unlogisch – aber das stört 
wenig, denn in meinem Falle wird sowieso keiner auf die Idee kommen, 
PgUp/PgDn zu benutzen. Ärgerlicher ist, dass das Scrollrad in 
2er-Schritten ändert.

Andreas B. schrieb:
> Jörg: hattest Du auch mal die ue_controls angeschaut (oben verlinkt) Da
> sind die Knöpfe noch besser gemacht und dort sind auch mehr Elemente
> dabei, die Für Gerätesteuerungen nützlich sind.

Nö, war bisschen untergegangen. Schau ich mir heute abend nochmal an, 
danke für die Erinnerung.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Kann sein, aber ganz ehrlich: für das bisschen Knopp mache ich jetzt
> keine weiteren Klimmzüge

Da ist meinerseits etwas anderes dahinter.

Wenn man von einer anderen Szene kommt und deshalb bei Delphi/Lazarus 
sich auf deren Komponenten nicht wirklich einlassen will, dann 
schlachtet man sich durch deren Gestrüpp mit der Machete und es wird 
immer schlimmer, je weiter man vordringt. Zum Schluß mündet das in 
Frust.

Muß aber nicht sein und soll auch nicht sein.

Es ist ne Frage des Denkansatzes.

Du wolltest dem eigentlichen Event-Handler seine Arbeit ausspannen, 
deshalb die Frage nach persistenten lokalen Variablen. Aber erstens ist 
das nicht sinnvoll oder gar nötig und zweitens sollte dann deine 
OnEvent-Routine ihr Zeug dort speichern, wo es hin gehört - nämlich in 
das Objekt, was deine OnEvent-Routine gerade gestartet hat - FALLS DAS 
schlußendlich überhaupt sinnvoll ist und nicht sofort einen weiteren 
Event auslöst. Bin da sehr skeptisch.

Das ist jetzt alles sehr herumtheoretisiert, also machen wir's 
einfacher: immer dran denken, bei OO und VCL bzw. FCL und Konsorten 
möglichst nicht wie der Elefant im Porzellanladen zu agieren. Sowas 
wie die OnEvent's sollen quasi als Anzeiger oder Botenjungen dienen, 
dafür daß irgend ein Objekt etwas getan hat oder zu tun beabsichtigt und 
deiner Anwendung (konkret deinem Main-Objekt) davon Kenntnis geben will. 
Der Botenjunge soll's nur überbringen und nicht eine eigene private 
Sache draus machen.

W.S.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Jörg W. schrieb:
>> Kann sein, aber ganz ehrlich: für das bisschen Knopp mache ich jetzt
>> keine weiteren Klimmzüge
>
> Da ist meinerseits etwas anderes dahinter.
>
> ...

Ist Object-Pascal nicht eine Multiparadigmensprache? Muss man unbedingt
alles in ein OO-Kostüm stecken, auch wenn es in einem konkreten
Anwendungsfall auf andere Weise leichter geht?

Wenn ich Jörg richtig verstanden habe, hat er bereits eine (einfache)
funktionierende Lösung gefunden und implementiert, und jeder zusätzliche
Aufwand würde seine Software zwar objektorientierter machen und damit
näher an die reine Lehre heranrücken, aber darüberhinaus kaum technische
Vorteile bieten.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Muss man unbedingt
> alles in ein OO-Kostüm stecken, auch wenn es in einem konkreten
> Anwendungsfall auf andere Weise leichter geht?

GUI-Programmierung und Simulationen sind nunmal die beiden Bereiche, in 
denen OOP am meisten Sinn ergibt.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> GUI-Programmierung und Simulationen sind nunmal die beiden Bereiche, in
> denen OOP am meisten Sinn ergibt.

Das ist schon richtig. Deswegen werden in praktisch allen GUI-Framworks
die einzelnen GUI-Elemente üblicherweise als Objekte innerhalb einer
hierarchischen Klassenstruktur realisiert (das ist sogar in GTK so,
obwohl dieses in klassischem C implementiert ist).

Aber muss deswegen der Anwendungsteil (also der Teil, der die Daten vom
GUI und von anderen Quellen verarbeitet), ebenfalls durchgängig rein
objektorientiert sein?

Ich glaube, Jörg wird schon wissen, was er tut, denn immerhin hat er die
Anwendung auch schon mit Qt implementiert, wo solche generellen Fragen
der Softwarestruktur in gleicher Weise auftreten.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Ist Object-Pascal nicht eine Multiparadigmensprache? Muss man unbedingt
> alles in ein OO-Kostüm stecken...

Nein, muss man nicht, das ist ja das Schöne dran.

Man kann eine kleine Anwendung mal schnell programmieren, ohne aus jedem 
Fliegenschiss ein Objekt zu machen.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Muss man unbedingt
> alles in ein OO-Kostüm stecken, auch wenn es in einem konkreten
> Anwendungsfall auf andere Weise leichter geht?

Nun, man kann mit ObjectPacal selbstverständlich auch schlicht 
prozedural programmieren. Das geht alles.

Aber wenn man eine Anwendung mit einer Oberfläche hat, die aus den 
Objekten einer Visual-Components-Library besteht, dann ist dort OO 
angesagt - jedenfalls was die Oberfläche und ihre Funktionalität 
betrifft.

Man kann dabei auch zweigleisig fahren, hab das schon gelegentlich so 
getan: ein Thread der Anwendung befaßt sich mit all den 
Oberflächen-Angelegenheiten, konform OO programmiert - und ein anderer 
Thread der Anwendung läuft parallel dazu und der ist schlichtweg 
prozedural. Kommunikation zwischen beiden über schlichte Semaphoren.

Dieser objektorientierte Ansatz bei der Oberfläche ist eigentlich auch 
der weitaus bessere im Vergleich zum prozeduralen Ansatz. Er braucht 
aber eben eine etwas andere Denke.

Und nochwas: Jörg hatte ja beargwöhnt, daß man für seinen Zweck ein 
eigenes Objekt aus einem Objekt der VCL/FCL ableiten müßte, was ihm 
verständlichermaßen zuviel Aufwand für das Projekt ist. Sowas muß 
garnicht sein. In seinem Falle wäre das persistente Merken von Werten im 
Hauptobjekt am ehesten sinnvoll - und wenn er nebenher auch noch 
prozedurale Dinge in der Anwendung hat, dann eben in globalen Daten der 
Anwendung. Das geht alles und macht auch keine Probleme.

W.S.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.