Unvollständige Anzeige eines Formulars [gelöst]

Rund um die LCL und andere Komponenten
Benutzeravatar
fliegermichl
Lazarusforum e. V.
Beiträge: 1430
Registriert: Do 9. Jun 2011, 09:42
OS, Lazarus, FPC: Lazarus Fixes FPC Stable
CPU-Target: 32/64Bit
Wohnort: Echzell

Re: Problem gelöst!!!

Beitrag von fliegermichl »

zappa2 hat geschrieben:Unglaublich, wie viele Stunden ich an dem Problem gebastelt habe!!!


Ich programmiere seit ca. 30 Jahren. Ich kann die Stunden, die ich mit einem solchen Schei... verbracht hab schon gar nicht mehr zählen. Aber ich freue mich heute noch, wenn ich die Lösung finden konnte. :-)

zappa2
Beiträge: 43
Registriert: Do 28. Nov 2013, 09:54

Re: Unvollständige Anzeige eines Formulars

Beitrag von zappa2 »

Das Ärgerliche ist die Verhältnismäßigkeit des Aufwands zwischen eigentlicher Business-Logik und solcher Probleme.

Glaubt kein Chef, dass man soviel Zeit verplempert hat. Und es ist auch kein guter Ausgangspunkt im Bestreben, Lazarus als zentrale Entwicklungsplattform in der Firma zu etablieren.

Man kann bei solchen Problemen ja nicht mal danach sagen: Habe ich mich wieder mal dumm angestellt. Das kommt natürlich auch oft genug vor, aber da kann man sich mit systematischem Debugging zur richtigen Lösung vorhangeln.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Unvollständige Anzeige eines Formulars

Beitrag von af0815 »

Der Hauptgrund warum das nicht so oft verwendet wird, ist auch einfach. Für Multiplattform ist das aktuell zu unsicher und instabil.

Bezüglich obscure Probleme, es gibt schlimmeres. Ich schlage mich da mit einem Problem in einem Widgetset herum, der von der LCL ausgelöst wird. Derselbe Code läuft unter Windows, aber nicht am Raspi wenn gtk2 verwendet wird. Verwendet man QT so geht derselbe Code. Nur scheint das Problem aber in Widgetset zu liegen. Das musste ich auch mal meinen Chef beibringen, das das Berichtsmodul nicht richtig funktioniert. Daher ist mir die Problematik wohlbekannt. Allerdings gab es sowas auch schon in Delphi und da konntest du nicht mal was fixen, nur workarounds machen.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

MacWomble
Lazarusforum e. V.
Beiträge: 999
Registriert: Do 17. Apr 2008, 01:59
OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
CPU-Target: Intel i7-10750 64Bit
Wohnort: Freiburg

Re: Unvollständige Anzeige eines Formulars

Beitrag von MacWomble »

af0815 hat geschrieben:... und da konntest du nicht mal was fixen, nur workarounds machen.


Nicht nur bei Delphi, das Problem kenne ich auch von MS-Studio. Ein Problem mit Datenbanken besteht dort seit über 10 Jahren, da tut sich nichts. Und der Workaround hat mich bei jeder neuen Version meines Programms Tage gekostet. :x
Genau hier liegt auch ein großer Vorteil von Lazarus. Wenn was nicht funktioniert wie es soll, kann man es fixen. 8)
Leider ist die Aussage zum Debugger in Lazarus wahr. Sonderlich hilfreich ist dieser oft nicht. :(
Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.

zappa2
Beiträge: 43
Registriert: Do 28. Nov 2013, 09:54

Re: Unvollständige Anzeige eines Formulars

Beitrag von zappa2 »

Ich will ja definitiv nicht allzu sehr über Lazarus meckern - es ist derzeit meine favorisierte Entwicklungsplattform, sobald ich in der Entscheidung frei bin. Dabei hätte ich noch die Wahl D10 oder D5 (Grusel - über 20 Jahre alt; für mich eigentlich ein No-Go für Neuentwicklungen) bei uns in der Firma.

DAS IST EINE GUTE GELEGENHEIT, DEN VIELEN ENTWICKLERN VON LAZARUS MAL DANKE ZU SAGEN!

Trotzdem:

Der Debugger in Lazarus verunsichert mich auch immer mal wieder: Gerade jetzt hatte ich mal wieder den Effekt, dass der Ablauf innerhalb eines try-except-Blocks von unten wieder nach oben gesprungen ist. Da war nirgendwo eine Schleife und goto gibt es bei mir seit 30 Jahren absolut und generell niemals. Mag etwas mit Optimierung des Compilers zu tun haben, aber da bin ich sehr konservativ, gehe niemals über die Default-Stufe 1 hinaus.

Auch nervt heftig, dass der Debugger sehr viele Propertys nicht anzeigen kann, obwohl er sie im Step-Over sehr wohl richtig auswertet. Da baue ich dann oftmals völlig unnötige Variablen ein, nur um zu sehen, was in der Tat da drin steht. Nach dem Debugging fliegt das Zeugs wieder raus. Man könnte da natürlich mehr mit {$DEFINE DebugMode}-{$IFDEF DebugMode}-Konstrukten arbeiten, aber der Aufwand hierfür ist schon immens und doch eigentlich sollte das überflüssig sein...

Und ich denke, einige der Probleme in Lazarus sind hausgemacht: für einige Projekte benötige ich andere Projekteinstellungen, was ab und zu ein komplettes Neukompilieren von Lazarus zur Folge hat. Was da an Hinweisen und Warnungen(!!!) kommt, geht auf keine Kuhhaut! Für mich ist eine Warnung grundsätzlich ein Fehler und ein Hinweis kurz davor. Ich würde niemals auch nur eine Zeile Quellcode mit Warnungen ausliefern. Die Vermutung liegt nahe, dass einige der Fehler, mit denen wir uns herumschlagen nicht auftauchen würden, wenn diese ganzen Warnungen bereinigt würden.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Unvollständige Anzeige eines Formulars

Beitrag von af0815 »

zappa2 hat geschrieben:Und ich denke, einige der Probleme in Lazarus sind hausgemacht: für einige Projekte benötige ich andere Projekteinstellungen, was ab und zu ein komplettes Neukompilieren von Lazarus zur Folge hat. Was da an Hinweisen und Warnungen(!!!) kommt, geht auf keine Kuhhaut! Für mich ist eine Warnung grundsätzlich ein Fehler und ein Hinweis kurz davor. Ich würde niemals auch nur eine Zeile Quellcode mit Warnungen ausliefern. Die Vermutung liegt nahe, dass einige der Fehler, mit denen wir uns herumschlagen nicht auftauchen würden, wenn diese ganzen Warnungen bereinigt würden.


Andere Projekteinstellungen bedingen aber IMHO kein neu kompilieren von Lazarus. Das halte ich für ein Gerücht. Da musst du mir erklären was du da wirklich damit meinst.

Bei den Warnungen von Lazarus muss man die Struktur von Lazarus und die (relative) Plattformunabhängigkeit berücksichtigen. Dazu kommt ja auch die Abhängigkeit vom FPC der ja der Compiler ist und dort werden immer wieder kleiner (manchmal böse) Adaptierungen und Änderungen vorgenommen. Daher muss man mal unterscheiden:
*) Kommt das Warning von FPC oder Lazarus.
*) Ist es ein Warning aus einer Komponente, die von Lazarus nur eingebunden ist.
*) Ist es eine Warnung, das der Code NUR auf dieser Plattform funktioniert

Nachdem ja beide Projekte OpenSource sind, kann man ja im Bugtracker nachsehen ob das bekannt ist und wenn nicht einen Bugfix erstellen und einreichen :-)

Auch wenn man das Firmenmässig verwendet ist es mehr als fair auch Firmenzeit zurück in das Projekt zu geben. Das wird oft vergessen, das man ja einen Grund hat, wenn man von einer anderen Plattform kommt :-) Dort kostet jede neue Version so richtig Kohle und man kann ja nicht einmal nachsehen wieviele Fehler in den Biblitheken stecken, weil man darauf gar keinen Zugriff hat :oops:
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

zappa2
Beiträge: 43
Registriert: Do 28. Nov 2013, 09:54

Re: Unvollständige Anzeige eines Formulars

Beitrag von zappa2 »

Okay, hat jetzt etwas gedauert, bis ich das von mir Behauptete reproduzieren konnte.

Ich habe in den Compilereinstellungen in der Systemkodierung mal -dDisableUTF8RTL angecheckt. Bei meinen aktuellen Projekten brauche ich das nicht mehr, deshalb sehe ich die Meldungen des Neukompilierens kaum noch, nur bei Neuinstallationen. Entgegen meiner Aussage oben handelt es sich nicht um Lazarus selbst, sondern um installierte Packages.

Dabei bekomme ich die in der beigelegten Datei enthaltenen Meldungen.

Daher muss man mal unterscheiden:
*) Kommt das Warning von FPC oder Lazarus.
*) Ist es ein Warning aus einer Komponente, die von Lazarus nur eingebunden ist.


Für mich als einfachen 'Benutzer' von Lazarus sind diese Packages quasi Bestandteil von Lazarus, ich kann ohne sie nicht sinnvoll mit Lazarus arbeiten. Damit ändert die Unterscheidung zw. Lazarus selbst und eingebunden Packages/Komponenten nichts. Das betrifft ja wirklich essentielle Packages wie bspw. LazUtils, LCLBase, LCL. Die meisten Meldungen kommen vom Melander-Drag&Drop-Package, die habe ich hier mal rausgenommen, sind ja ThirdParty-Produkt.

Für ein Bugfix reichen meine Kenntnisse nicht aus, die Jungs spielen in einer anderen Liga. Nun könnte ich trotzdem versuchen, diesen Warnungen abzuhelfen und die entsprechenden Stellen zu korrigieren. Aber spätestens in der nächsten Neuinstallation habe ich sie alle wieder.

Auch wenn man das Firmenmässig verwendet ist es mehr als fair auch Firmenzeit zurück in das Projekt zu geben.


Gebe ich Dir absolut Recht. Nur wie soll das aussehen? Die Warnungen und Hinweise sehen ja die betreffenden Entwickler selbst, das brauche ich denen nicht mitteilen.

Einen echten Bug würde ich selbstverständlich melden, wenn ich ihn eindeutig als solchen identifizieren könnte. Aber es sind die Fehler, wo man keine Rückmeldung vom Debugger bekommt, warum etwas crasht.

Siehe bspw. auch mein Diskussionsthema https://www.lazarusforum.de/viewtopic.php?f=17&t=12427

Da werde ich mir mal die Zeit nehmen, und das von Dir angeregte Minimalbeispiel zusammenbasteln. Denn mit diesem Effekt lebe ich nach wie vor.

Wäre das dann so ein erwähnter Beitrag, etwas von meiner Zeit zurück zu geben? Oder meinst Du da noch etwas Konkreteres?

Allerdings habe ich mal in irgend einem englischsprachigen Chat sinngemäß gelesen, dass dies ein gewolltes Verhalten sei. Leider weiß ich nicht mehr, wie der Typ das begründet hatte, klang für mich alles ziemlich nach Kauderwelsch.
Dateianhänge
err.txt
(41.38 KiB) 92-mal heruntergeladen

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Unvollständige Anzeige eines Formulars

Beitrag von Warf »

Nehmen wir mal den error file auseinander:
512 Hints und 12 Warnings.
Von diesen 512 hints sind 201 einfach nur "unused Parameter", was bei Eventbasierter Programmierung unerlässlich ist. Während das bei klassischer Prozessualer Programmierung tatsächlich eine Fehlerquelle sein kann, ist das bei Events zu erwarten, da du meistens nur die Info brauchst das ein Event gefeuert wurde (i.e. das die Funktion überhaupt ausgeführt wird) und oftmals keine weiteren Infos brauchst.
Von den 311 verbleibenden Hints sind 195 portabilitätswarnungen. Da die LCL sehr häufig auf die Targetplatform optimiert sind die auch zu erwarten.
Von den verbleibenden 116 Hints sind 92 nicht initialisierte Variablen Hints. Da stimm ich dir zu, die sollte man auf jeden Fall vermeiden. Das problem ist hierbei das früher der FPC noch keine default initialization bei definition machen konnte, und wenn du einen Haufen vars hast die du nur in bestimmten fällen brauchst, willst du oftmals nicht am Anfang einer Funktion erst mal noch 50 Zeilen Default initialisations machen. z.B.

Code: Alles auswählen

var Counter: Integer;
...
begin
if DoDebugStuff then Counter := 0;
...
if DoDebugStuff then Inc(Counter);
...
if DoDebugStuff then WriteLn('Number of Iterations: ', Counter)

Das wird dir diese Hint werfen, und während man heute einfach var Counter: Integer = 0; schreiben kann, ging das vor ein paar Jahren noch nicht, als diese Komponenten wahrscheinlich gebaut wurden. Und Lazarus ist ein OpenSource Projekt was zwar relativ aktiv entwickelt wird, aber ich kann schon verstehen das kein Entwickler lust hat ein paar tage seiner Freizeit zu investieren um code auf die neue FPC version zu updaten nur weil ne Hint wirft.

Die restlichen Hints sind 18 mal Unit not Used, die sehr schnell durch Compilerswitches entstehen können (nicht das man sie nicht genauso einfach fixen könnte) sind aber beim besten willen nicht harmful, und können sogar false positives sein (wenn du z.B. auf den Initialization block angewiesen bist, z.B. bei der cmem unit), und die Restlichen Hints sind Signed/Unsigned oder Overflow Hints. Und da muss ich ganz ehrlich sagen ist das ein allgemeines Problem in der Lazarus welt, das sehr oft Signed und Unsigned durcheinander geworfen wird (Und das sehr oft Signed zahlen verwendet werden obwohl sie Technisch keinen sinn ergeben, so gibt Length z.B. einen signed SizeInt zurück obwohl es keine negativen Größen geben kann).

Die 12 verbleibenden Messages sind Warnings, von denen 5 Deprecation warnings sind, die bei einem So großen und Langlebigen Projekt wie der LCL auch unvermeidbar sind (ihnen fehlt einfach die Manpower um den ganzen alten code bei einem Update zu updaten), und der rest sind vor allem Conversion Warnings (Portability, Pointer->Signed, Verschiedene Typen) bei denen ich nicht direkt sagen kann ob diese korrekt sind oder nicht, da die aber in extrem low level Funktionen sind, würde ich einfach mal annehmen das die gewollt sind, da man auf so tiefer ebene eh genau wissen muss womit man arbeitet.

Aber man könnte, zumindest für die Warnings, wenn man als Entwickler weiß das sie da sein sollen, per compilerswitch die Warnings für diese Funktion austellen

zappa2
Beiträge: 43
Registriert: Do 28. Nov 2013, 09:54

Re: Unvollständige Anzeige eines Formulars

Beitrag von zappa2 »

Da bin ich bei Dir, zumindest im Großen und Ganzen:

- Hints über unused vars oder units:
Geschenkt, droht keine unmittelbare Gefahr. Der Sauberkeit halber sollte doch aber der Entwickler, der als letzter an dieser Unit rumwerkelt das bereinigen. Denn wenn der Berg immer größer wird, den man vor sich herschiebt, wird keiner mehr die Zeit opfern, das in Ordnung zu bringen. 20 Meldungen => kostet ein paar Minuten, weg sind sie. 200 aber: das war ja nicht ich, soll wer anderes machen. Tendenz: Verschlimmerung.

- das Problem Pointer => Signed: einmal einen kleinen Wrapper schreiben, überall drumrum gepackt, und schon habe ich nur noch eine einzige Stelle, die ich im Auge behalten muss, wenn es doch mal bei irgend einer Systemumstellung brenzlig wird. Das sollte selbst mit Suchen-Ersetzen funktionieren.

Depcrecatet finde ich einfach nur peinlich: 5 Stellen sind in 2 Minuten gefixed. So was sollte nicht vorkommen, darf nicht vorkommen. Meist steht sogar im Log, was man stattdessen nehmen sollte.

Zum Signed/Unsigned: Das stimmt, da sollte man schon wissen was man tut. Ich vergewaltige übrigens auch hin und wieder gern negative Integer in Pointer, um sie als definierte Steuerungelemente z.B. TreeViews oder Grids als Object mitzugeben (z.B. negative sind IDs aus der einen Datenbanktabelle, positive aus einer anderen); funktioniert hervorragend. Und ich differenziere, wann ich PtrInt oder PtrUInt nehme - wie Du schon sagtest, man sollte schon wissen, was man wann nimmt.

Wegen der Targetplatform-Abhängigkeiten: Es gibt doch die define/ifdef-Clauseln. Für systemnahe Packages halte ich die für Pflicht. Das machen doch selbst wir kleinen Anwendungsentwickler, wenn wir parallel für Linux/Unix und Windows entwickeln. Für Systemprogrammierer sollte das doch dann erst Recht Pflicht sein - oder?

Und ja: unkritische Hints, die der Entwickler wohlwissend in Kauf nimmt, weil er an dieser Stelle um ihre Nichtrelevanz weiß, könnte man ja einfach mal unterdrücken. Ein Rechtsklick mit der Maus und im Kontextmenü den Punkt 'Meldungen xyz unterdrücken' = Klick - fertig.

Nochmal: die Jungs machen einen hervorragenden Job - das wird viel zu selten gewürdigt. Es sind nur diese kleinen Stolperstellen, die einen doch hin und wieder grübeln lassen.

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Unvollständige Anzeige eines Formulars

Beitrag von Warf »

zappa2 hat geschrieben:- Hints über unused vars oder units:
Geschenkt, droht keine unmittelbare Gefahr. Der Sauberkeit halber sollte doch aber der Entwickler, der als letzter an dieser Unit rumwerkelt das bereinigen. Denn wenn der Berg immer größer wird, den man vor sich herschiebt, wird keiner mehr die Zeit opfern, das in Ordnung zu bringen. 20 Meldungen => kostet ein paar Minuten, weg sind sie. 200 aber: das war ja nicht ich, soll wer anderes machen. Tendenz: Verschlimmerung.


Ja, der großteil ist ja Unused Parameter. Das ist halt bei event basierter Programmierung einfach der Fall das die aufkommen, und da kann man auch nix machen. Wenn man die Argumente von einem Event nicht braucht, braucht man sie einfach nicht. Soweit ich weiß kann man in Lazarus die aber mittlerweile (ich glaub nur projektweit, nicht global) unterdrücken lassen, bin mir aber nicht so sicher (Ich hab sie einfach akzeptieren gelernt :mrgreen: )

zappa2 hat geschrieben:Depcrecatet finde ich einfach nur peinlich: 5 Stellen sind in 2 Minuten gefixed. So was sollte nicht vorkommen, darf nicht vorkommen. Meist steht sogar im Log, was man stattdessen nehmen sollte.

Grundsätzlich ja, aber Deprecation zu ersetzen ist nicht immer trivial. Ich hab mir die Codestellen nicht weiter angeschaut, aber ich habs schon selbst erlebt das die Funktion die genau das macht was man will deprecated ist, und es keine 1-zu-1 ersatz gibt, bzw. es echt kompliziert wird das selbe über andere Methoden zu erreichen. Eventuell warten die entwickler auch auf ein neues feature um das alte zu ersetzen (hatte ich schonmal in nem java projekt, wo wir n deprecated call nicht ersetzen konnten bis die nächste version von ner Lib draußen war die endlich die vernünftige alternative bildet). Da steckt man einfach nicht drin, und es sind immerhin nur 5 stück.

zappa2 hat geschrieben:Zum Signed/Unsigned: Das stimmt, da sollte man schon wissen was man tut. Ich vergewaltige übrigens auch hin und wieder gern negative Integer in Pointer, um sie als definierte Steuerungelemente z.B. TreeViews oder Grids als Object mitzugeben (z.B. negative sind IDs aus der einen Datenbanktabelle, positive aus einer anderen); funktioniert hervorragend. Und ich differenziere, wann ich PtrInt oder PtrUInt nehme - wie Du schon sagtest, man sollte schon wissen, was man wann nimmt.


Solang man weiß was man tut ist alles in Ordnung. Problematisch wirds eher bei der Übersetzung auf andere Plattformen. x86 und x86_64 garantieren soweit ich weiß das das geht (was übrigens nicht trivial ist, 64 bit Betriebsysteme und Prozessoren arbeiten für gewöhnlich auf 48 bit pointern, das so schweinereien also überhaupt gehen ist mehr dem guten willen von Intel und Co zu verdanken statt der unterliegenden technik). Aber auf anderen architekturen sieht das direkt ganz anders aus. Auf ARM ist soweit ich weiß nicht jede Zahl ein gültiger Pointer, d.h. Pointer(x) und Pointer(x+1) kann den selben pointer ergeben (es ist also nicht möglich hin und her zu converten ohne informationen zu verlieren), und damit kann das programm von einem ganz schnell in die Hose gehen. Und grade weil ARM prozessoren mehr und mehr werden (Handies, Raspies, und in zukunft eventuell sogar desktops) Versuche ich mittlerweile sowas ganz und gar sein zu lassen, wer weiß ob ich in 5 jahren nicht eine meiner Anwendungen mal auf ARM porten möchte

zappa2 hat geschrieben:Wegen der Targetplatform-Abhängigkeiten: Es gibt doch die define/ifdef-Clauseln. Für systemnahe Packages halte ich die für Pflicht. Das machen doch selbst wir kleinen Anwendungsentwickler, wenn wir parallel für Linux/Unix und Windows entwickeln. Für Systemprogrammierer sollte das doch dann erst Recht Pflicht sein - oder?


Ja in der LCL (sowie auch der RTL und FCL) wird das normalerweise so gehandhabt das der ganze Plattform spezifische code in eigenen Include dateien hockt, die dann je nachdem eingebunden werden:

Code: Alles auswählen

{$ifdef WINDOWS}
{$include ImplXYZWindows.inc}
{$else}
{$ifdef DARWIN}
{$include ImplXYZMacOS.inc}
{$else}
{$ifdef LINUX}
{$include ImplXYZLinux.inc}
{$endif}
{$endif}
{$endif}

Das problem ist, der FPC merkt sich nicht ob er jetzt in einem IFDEF Windows block ist oder nicht, und wenn er einen nicht portablen code findet meckert er, obs angebracht ist oder nicht. Genauso, selbst wenn der FPC sich das merken würde, gibt es ja noch "soft constraints", so kann man davon ausgehen wenn man windows hat das es auf ner x86 architektur läuft, weils einfach kein wirkliches Windows gerät auf einer anderen Architektur gibt (Windows phone ist tot und selbst das Surface läuft wieder auf x86)

zappa2 hat geschrieben:Und ja: unkritische Hints, die der Entwickler wohlwissend in Kauf nimmt, weil er an dieser Stelle um ihre Nichtrelevanz weiß, könnte man ja einfach mal unterdrücken. Ein Rechtsklick mit der Maus und im Kontextmenü den Punkt 'Meldungen xyz unterdrücken' = Klick - fertig.

Man kann auch über Compiler Switches bestimmte Warnings oder Hints für einen Code abschnitt deaktivieren. Wenn man also weiß das ein No-Portable Hint auftreten soll, kann man theoretisch einfach sagen: Für die folgende Funktion ignoriere alle No-Portable Hints. Aber um ehrlich zu sein kann ich den Lazarusentwicklern nicht verübeln sich nicht den Aufwand zu machen, ich würds wahrscheinlich nicht besser machen (bzw. ich weiß das ichs in meinen projekten nicht besser mache)

zappa2 hat geschrieben:Nochmal: die Jungs machen einen hervorragenden Job - das wird viel zu selten gewürdigt. Es sind nur diese kleinen Stolperstellen, die einen doch hin und wieder grübeln lassen.

Auf jeden Fall. Vor allem wenn man sich ansieht was da auch in den Letzen jahren geschehen ist. Als ich damals zu Lazarus 0.9.28 angefangen hab (Ist mittlerweile 10 Jahre her) war Lazarus zwar schon benutzbar und für ne Open Source IDE recht solide, aber im vergleich was seit dem alles geschehen ist, ist Lazarus mittlerweile zu einer Echt Top IDE geworden. Wenn ich eine GUI anwendung schreiben will, gibts mMn. kaum vernünftige alternativen. Für C++ und QT darf man mindestens mit dem doppelten aufwand rechnen für das selbe ergebnis (und muss unter Windows noch die paar hundert MB QT Libs mitliefern), bei .Not darf man entweder seine Seele an Microsoft verkaufen (i.e. Visual Studio/Xamarin benutzen) oder mit MonoDevelop sich auf GTK festschießen und mit einer deutlich schlechteren IDE arbeiten, oder bei Java direkt auf seinen Formulareditor verzichten und alles über Code regeln.

Zwar mach ich aktuell recht viel mit anderen Programmiersprachen (Arbeite mit C++, benutz Java für die Uni, etc.) und ich kritisier Lazarus auch sehr oft weil ich einfach sehe das andere Programmiersprachen einige sachen einfach besser machen (z.B. stackobjekte in C++ vs Objects oder Advanced Records in Pascal, oder Memory management mit Refrence count, etc.), aber letzendlich macht Pascal programmieren immernoch am meisten spaß, denn egal was, ich kann mir sicher sein ich bekomm es relativ einfach und schnell gelöst mit Lazarus. Einfach die Fähigkeit mal eben in 5 minuten eine schnelle form zu designen und simple sachen auszuprobieren ist schon gold wert (In der zeit in der ich in C++ überhaupt die toolchain aufgesetzt hab hab ich ja schon ein halbes projekt mit Lazarus fertig). Es ist vielleicht nicht optimal für alles, macht aber alles so gut das es immer meine goto lösung ist wenn ich nicht grade besondere vorraussetzungen hab.

Das einzige was mMn seit jahren fehlt ist endlich eine vernünftige Möglichkeit Lazarusprojekte über die Kommandozeile zu kompilieren ohne das GUI benutzen zu müssen (selbst für Lazbuild musst du zu erst über das GUI alle packages die du brauchst installieren)

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Unvollständige Anzeige eines Formulars

Beitrag von af0815 »

Ausserdem muss man unterscheiden zwischen IDE bauen und Applikationsbau.

Das bauen von der IDE würde ich einmal nicht bewerten, sondern nure, wenn man selbst Applikationen baut oder die reinen Schnittstellen recompiliert. Dann kann man ja mal nachsehen ob im Bugtracker es Informationen dazu gibt. Wenn nicht, so sollte man sich zumindest den letzten fixes Zweig ansehen, ob nicht dort bereits gefixt wurde. Den aktuellen Trunk ist natürlich auch nicht schlecht. Und wenn das Problem da ist, entweder selbst fixen und einen Patch einreichen oder zumindest eine Info im Bugtracker hinterlassen.

Wobei anzumerken ist, das manche deprecated sich relativ lange halten, da die Lösung, so wie Warf schon gesagt hat, alles andere als trivial ist. Man sollte sich auch immer wieder die Änderungen und Breaking news in der Wiki zu den Versionen ansehen. Vor allen sollte ja der Fix nicht die verschiedenen Kombinatiopnen von fpc und Lazarus umbringen. Das ist auch eine hohe Kunst - verschiedene Plattformen - verschiedene Widgetsets je Plattform - verschiedene Compiler (stable, fixes,trunk) je Plattform möglich.

Am besten mal einen Bugfix einreichen und den Prozess einmal kennen lernen. :D Schnellere und unmittelbare Rückmeldung gibts matürlich auf der Maillingliste.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Benutzeravatar
six1
Beiträge: 782
Registriert: Do 1. Jul 2010, 19:01

Re: Unvollständige Anzeige eines Formulars

Beitrag von six1 »

zappa2 hat geschrieben:Die meisten Meldungen kommen vom Melander-Drag&Drop-Package, die habe ich hier mal rausgenommen, sind ja ThirdParty-Produkt.


Die Melander Suite habe ich damals aus purer Verzweiflung für Lazarus ge-forked.
Ich war mitten in einem größeren Projekt und die Lazarus Drag&Drop Funktionalitäten waren unzureichend.
Ich hatte keine Zeit, das "schön" zu machen; funktional und stable war es.
Andere Anwender hatten dann noch Probleme mit 64Bit oder/und WIN7, was nach und nach repariert wurde... aber "schön gemacht" wurde es immer noch nicht :D
Habe es im Hinterkopf und wenn ich Zeit finde, schaue ich nochmal drüber...
Gruß, Michael

zappa2
Beiträge: 43
Registriert: Do 28. Nov 2013, 09:54

Re: Unvollständige Anzeige eines Formulars

Beitrag von zappa2 »

Guter Mann!!!
1000 Dank für Deine bisher schon geleistete Arbeit, hat mir einiges gebracht: die Verwendbarkeit von Lazarus für ein neues Projekt! Hätte mich sonst mit Delphi5 rumschlagen müssen, worauf ich wirklich keinen Bock mehr habe.

Antworten