Announcement: there is an English version of this forum on 
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.
Angehängte Dateien:
-
tek492.png
69 KB
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
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 :)
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
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.
Andreas B. schrieb: > Die Drehknöpfe findest Du schon mal hier. > https://wiki.freepascal.org/BGRAControls/de Wo genau findet man die Dokumentation dazu?
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 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.
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.
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
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.
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).
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.
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.
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
Angehängte Dateien:
-
Panel.png
72 KB
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.
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
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
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
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.
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. ;-)
mh schrieb: > Wo genau findet man die Dokumentation dazu? https://github.com/bgrabitmap/bgracontrols/blob/master/bgraknob.pas
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.
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.
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.
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...).
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.
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
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.
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.
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.
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.
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
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.
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
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
moakadarkmaster schrieb: > Jörg W. schrieb: >> Anbei mal ein Screenshot. > > Mit welcher Lib hast du den Graph gemacht? Das ist eine qwt PlotArea.
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
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.
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" https://www.youtube.com/watch?v=TLQwwtjtiY4&t=1075s
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
Jörg W. schrieb: > Pascal scheint nach wie vor keine wirklichen statischen Variablen > innerhalb von Funktionen/Prozeduren zu kennen. Was ist eine statische Variable?
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.
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.
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:
1 | function xy(irgendwelche Parameter):irgendein Typ |
2 | var
|
3 | const i : integer = 0; |
4 | begin
|
5 | .
|
6 | .
|
7 | .
|
8 | end; |
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).
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.
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.
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
1 | var |
2 | 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
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:
1 | var |
2 | once: Boolean = False; static; |
oder schöner und maximal konsequent:
1 | procedure Blub; |
2 | var |
3 | foo: Integer; |
4 | bar: Double; |
5 | static |
6 | once: Boolean; |
7 | |
8 | begin |
9 | |
10 | end; |
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."
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.
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.
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.
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
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.)
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?
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
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.
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
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)
Ja, wäre eine Variante. Ist mir gerade zu aufwändig, ich habe ja ohnehin auch nur einen Knopp.
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)
1 | * Ctrl-Shift-C (Codegenerator) |
2 | Wenn man gerade auf der Methodendeklaration im Interface ist |
3 | implementiert das unten die Methode und springt dort hin und setzt |
4 | den Cursor zwischen begin und end; |
5 | |
6 | Wenn man gerade unten eine neue Methode implementiert hat dann |
7 | fügt es oben eine passende Deklaration ein. |
8 | |
9 | Wenn man gerade die Methodensignatur im Interface geändert hat passt es |
10 | automatisch die Signatur unten in der Implementation entsprechend an. |
11 | |
12 | Wenn man gerade die Methodensignatur in der Implementation geändert hat |
13 | passt es automatisch die Signatur oben im Interface entsprechend an. |
14 | |
15 | * Ctrl-Shift-Up |
16 | Springt von Interface zur Implementation und umgekehrt. |
17 | Sehr nützlich wenn man per Ctrl-Klick einem Methodenaufruf gefolgt |
18 | ist, dabei im Interface landet und jetzt die Implementation sehen will, |
19 | spart viel Scrollerei. |
20 | |
21 | * Ctrl-Klick |
22 | Folgt einem Methodenaufruf, springt zur Deklaration derselben |
23 | (danach Ctrl-shift-up und man ist bei der Implementation) |
24 | |
25 | * Ctrl-H |
26 | Springt wieder zurück wo man hergekommen ist. |
27 | |
28 | * F2 |
29 | Bezeichner unter dem Cursor umbenennen, semantik-bewußt. |
30 | |
31 | * F12 |
32 | Bringt das Formular in den Vordergrund in dessen Unit man sich |
33 | gerade befindet |
34 | |
35 | * Shift-F9 |
36 | Kompilieren und sofort mit dem Cursor zum ersten Fehler springen |
37 | (durch die rasende Kompiliergeschwindigkeit ist es beim Refactorn |
38 | schneller sich vom Compiler von Baustelle zu Baustelle leiten zu |
39 | lassen als diese Stellen von Hand anzunavigieren) |
:
Bearbeitet durch User
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.
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.
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.
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
1 | const |
2 | foo : Integer = 42; |
3 | |
4 | begin |
5 | if foo = 42 then begin |
6 | foo = 23; |
7 | writeln('first time')
|
8 | end |
9 | end |
ist doch nun wirklich nichts anderes als
1 | static int foo = 42; |
2 | |
3 | if (foo == 42) { |
4 | foo = 23; |
5 | puts("first time"); |
6 | }
|
Aber ich wollte hier keinen Vergleich Pascal vs. C. Ich möchte eine Qt-App nach FPC/Lazarus portieren.
:
Bearbeitet durch Moderator
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.
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
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. :)
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.
Ah, MessageBox scheint's zu sein … danke fürs Zuhören. :-)
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.
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...
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.
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.)
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.
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
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
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.
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.
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:
1 | const
|
2 | a=2; |
3 | b=2.5; |
4 | 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:
1 | procedure xy(a:integer; const b:integer=1); |
2 | begin
|
3 | ...
|
4 | 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.
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ß.
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.
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.
Hat schon jemand ungetypte Parameter erwähnt?
1 | procedure TakeAnything(const C); |
oder Variant Open Array Parameters?
1 | 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
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.
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 :-)
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.
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.
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
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.
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.
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.
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
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:
1 | type |
2 | |
3 | { TAboutForm }
|
4 | TAboutForm = class(TForm) |
5 | Copyright1: TStaticText; |
6 | Copyright2: TStaticText; |
7 | ... |
Und zum anzeigen (Menu, ButtonClick oder Action)
1 | AboutForm.ShowModal; |
Dann kannst Du Dich im Dialog auch etwas mehr austoben. /regards
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.
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.
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.
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.
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.
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
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 …
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
wie weit ist das Projekt eigentlich gediehen? Gab es noch Probleme? Ist es fertig?
Paul P. schrieb: > wie weit ist das Projekt eigentlich gediehen? Mal irgendwann in der Priorität so weit runtergerutscht, dass es derzeit auf "on hold" liegt. ;-) Ist aber definitiv noch nicht aufgehoben, nur aufgeschoben.
Welche Gründe hat der Wechsel von Qt zu FPC, dass ist irgendwie etwas untergegangen? Lizenzmodel? Deployment? Lizenzmodel Qt: Du darfst nicht statisch linken und wenn Du Qt Source code veränderst musst Du Ihn publizieren, aber nicht deinen eignenden Code, dass ist mein Verständnis. Gerne lasse ich mich hier korrigieren, wenn mein Verständnis falsch ist. Deployment: Windeployqt und dann einfach als Zip packen hat bei mir bis jetzt super geklappt, da hatte ich mehr Probleme Visual Studio Applikationen auf einen neuen Rechner zubekommen, dank Abhängigkeiten zu Visual net/C redist.
Dirk schrieb: > Welche Gründe hat der Wechsel von Qt zu FPC, dass ist irgendwie etwas > untergegangen? Dass ich den ganzen Salat zusammen mit Qwt seinerzeit nicht stabil überhaupt unter Windows compiliert bekommen hatte, außerdem das mit dem "Deployment": das ganze Teil soll noch an jemanden weitergegeben werden, der es unter Windows 2000 nutzen möchte (damit läuft sein Messgeräte-PC), sodass ein self-contained executable wünschenswert ist. In erster Linie war die Idee dabei allerdings, dass Lazarus als Plattform für systemübergreifende Applikationen hier im Forum angepriesen worden war, und ich auf diese Weise zumindest überhaupt eine nichttriviale Anwendung habe, an der man das mal exerzieren kann.
Jörg W. schrieb: > 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. Hey Jörg, das Programm hast du sehr hübsch gemacht. Ich möchte schon lange etwas ähnliches realisieren für HP 3577/4195/8753 Netzwerkanalyzer. Die haben allerdings GPIB, aber ich habe noch keine gute generische Lösung gefunden, wie man die GPIB Schnittstelle anspricht. Auch wollte ich mein Programm unter Linux und Windows verfügbar haben. Hast du evt Erfahrungen mit irgendwelchen GPIB Libraries oder ähnlichem, oder hast du eine selber geschrieben? Ja, der 492 hat keins, aber vielleicht hast du ja noch andere Geräte angesteuert ;-) ich verwende die Prologix GPIB/USB Adapter.
Tobias P. schrieb: > Hast du evt Erfahrungen mit irgendwelchen GPIB Libraries oder ähnlichem, > oder hast du eine selber geschrieben? Mit Linux-GPIB bzw. dessen Variante unter FreeBSD habe ich ein bisschen was gemacht, aber unter Windows habe ich da leider keinen Schimmer. Der Tek492 benutzt ein selbst gestricktes Interface, welches über die Aux-Schnittstelle auf den Prozessorbus zugreift. Damit kann man zwar den Analyzer nicht steuern (die Bedienelemente im Programm sind nur dafür da, dass man sie parallel zum Analyzer so einstellen kann, dass dann die entsprechenden Angaben im Plot erscheinen), aber man kann zumindest die Plot-Daten auslesen.
Dirk schrieb: > Du darfst nicht statisch linken Nein, falsch. Dirk schrieb: > und wenn Du Qt Source code veränderst > musst Du Ihn publizieren Zu ungenau. Proaktives Veröffentlichen ist nicht notwendigerweise erforderlich und nur Leute, die die betroffene Software erhalten, erlangen auch Ansprüche daran.
Jemand schrieb: > Nein, falsch. Mag sein, interessiert aber hier rein gar nicht. Der Sourcecode ist mir völlig wurscht, kann ich veröffentlichen. Also bitte diese Lizenzgeschichten woanders diskutieren. Danke.
Jörg W. schrieb: > Dass ich den ganzen Salat zusammen mit Qwt seinerzeit nicht stabil > überhaupt unter Windows compiliert bekommen hatte, außerdem das mit dem > "Deployment": das ganze Teil soll noch an jemanden weitergegeben werden, > der es unter Windows 2000 nutzen möchte (damit läuft sein > Messgeräte-PC), sodass ein self-contained executable wünschenswert ist. Könnte man dazu nicht auch mal bei QT nachfragen? Mit welchen Compilern und Bibliotheken hast du versucht? Hilft dir ein Link weiter? -> http://heikogorski.de/Compiler---Code/QT-und-Code--Blocks/qt-und-code--blocks.html (vermutlich nicht, du willst ja was mit Pascal machen?) Hast du eine Theorie, warum "nicht stabil compiliert bekommen" ? (heißt das jetzt mit VC++ Debugger oder ohne?) Windows 2000 ist schon ganz schön alt (Windows NT), da sollte man keine zu aktuellen Bibliotheken bzw. Übersetzer für das Endprodukt nehmen. (vielleicht http://lptk.sourceforge.net/index.php ? )
rbx schrieb: > Hast du eine Theorie, warum "nicht stabil compiliert bekommen" ? Ich glaube mich zu erinnern, dass das Hauptproblem irgendwelche Dinge aus Qwt waren, die hie und da mal crashten. Das Teil ist ziemlich in die Interna von Qt reingestrickt, und wenn dort was knallt, guckst du auch mit einem Debugger wie ein Schwein ins Uhrwerk. Ohne Qwt fehlen aber einige gestalterische Gimmicks, die das Ding nett aussehen ließen.
:
Bearbeitet durch Moderator
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.