Lazarus 1.2 veröffentlicht

[JamesTKirk]

Zitat von Sir Rufo:

Und die Unterscheidung ob Datei oder Verzeichnis ist sowieso egal, der PathDelimiter am Ende darf einfach nicht entfernt oder angehängt werden.

Ich weiß grad leider nicht, wie's konkrekt umgesetzt wurde. Das müsste man also ausprobieren...

Zitat von QuickAndDirty:

Ich arbeite gerne damit. Allerdings fehlt wirklich sowas wie ein Package-Konzept(dynamisch gelinkte Packages) für FreePascal! Es fehlt doch noch?

Ja, das fehlt noch. Ich habe letztes Jahr mal damit begonnen, dass umzusetzen, aber überraschenderweise ist besonders die Unterstützung unter Windows recht schwierig (wegen indirekter Auflösung von globalen Variablen, die unterschiedlichen Code für Package/nicht-Package benötigt...)

Zitat:

Es kann doch nicht angehen das man für jede Komponente die komplette IDE neu kompilieren muss.

Wieso? Angenehmer geht es doch kaum: Klick auf den passenden Menüeintrag und fertig. Im Normalfall werden sogar nur die neuen Packages neu kompiliert und dann die IDE neu gelinkt. Das geht selbst auf meinem betagten 800 MHz/1 GB Rechner relativ flott (zumindest schneller als das Kompilieren von manchen C Projekt ).

Gruß,
Sven

[QuickAndDirty]

Zitat von JamesTKirk:

Zitat von QuickAndDirty:

Ich arbeite gerne damit. Allerdings fehlt wirklich sowas wie ein Package-Konzept(dynamisch gelinkte Packages) für FreePascal! Es fehlt doch noch?

Ja, das fehlt noch. Ich habe letztes Jahr mal damit begonnen, dass umzusetzen, aber überraschenderweise ist besonders die Unterstützung unter Windows recht schwierig (wegen indirekter Auflösung von globalen Variablen, die unterschiedlichen Code für Package/nicht-Package benötigt...)

Wenn man erstmal die LCL in 'nem Dynamisch linkbaren Package hat, ist es dann nicht auch möglich ein Freepascal+LCL Plugin für Visualstudio und Eclipse zu bauen?

[michaelthuma]

Für IntelliJ gibt es zumindest ein FPC Plugin ... zumindest FPC.PasIdea Grad auch in der community edition die Android support hat. Ist bestimmt noch einiges zu tun.

Zitat von QuickAndDirty:

Wenn man erstmal die LCL in 'nem Dynamisch linkbaren Package hat, ist es dann nicht auch möglich ein Freepascal+LCL Plugin für Visualstudio und Eclipse zu bauen?

[QuickAndDirty]

Zitat von michaelthuma:

Für IntelliJ gibt es zumindest ein FPC Plugin ... zumindest FPC.PasIdea Grad auch in der community edition die Android support hat. Ist bestimmt noch einiges zu tun.

Zitat von QuickAndDirty:

Wenn man erstmal die LCL in 'nem Dynamisch linkbaren Package hat, ist es dann nicht auch möglich ein Freepascal+LCL Plugin für Visualstudio und Eclipse zu bauen?

Super, aber wie bekommen wir da unseren visuellen GUI Editor?
Ich denke dazu braucht es dynamisch linkbare Packages.

[michaelthuma]

Wäre sehr ungewöhnlich würde ein GUI Editor in dem Umfeld mitgeliefert werden. Wer nimmt Java und Anverwandtes für visuelle Entwicklung... Das wird wohl für Lazarus oder ähnliche Alternativen reserviert bleiben. Ich finde allein recht nett, dass auch mal eine andere IDE überhaupt mal ein Pascal mitberücksichtigt.

Auch wenn bspw. sehr viel geschimpft wird über den FM. Das potentielle Interesse von jenen die solch eine erquickliche Kombi benötigen ist schon da oder wird zumindest als spannend bis praktisch empfunden. Genauso wie die DB Anbindung von FPC oder Delphi allgemein ...

Zitat von QuickAndDirty:

Zitat von michaelthuma:

Für IntelliJ gibt es zumindest ein FPC Plugin ... zumindest FPC.PasIdea Grad auch in der community edition die Android support hat. Ist bestimmt noch einiges zu tun.

Zitat von QuickAndDirty:

Wenn man erstmal die LCL in 'nem Dynamisch linkbaren Package hat, ist es dann nicht auch möglich ein Freepascal+LCL Plugin für Visualstudio und Eclipse zu bauen?

Super, aber wie bekommen wir da unseren visuellen GUI Editor?
Ich denke dazu braucht es dynamisch linkbare Packages.

[JamesTKirk]

Zitat von QuickAndDirty:

Wenn man erstmal die LCL in 'nem Dynamisch linkbaren Package hat, ist es dann nicht auch möglich ein Freepascal+LCL Plugin für Visualstudio und Eclipse zu bauen?

Warum sollte ich mir dieses schwergewichtige Eclipse antun, wenn Lazarus um ein vielfaches performanter ist? Und die Unterstützung von Pascal Code (Refactoring, etc.) ist sicherlich auch nicht auf nem ähnlichen Level wie in Lazarus, da in letzterem die Entwickler selbst in Lazarus arbeiten und dadurch fehlende Featues leicht ins Auge fallen. Von Visual Studio will ich da noch gar nicht mal reden, das hat ja nichtmal rudimentären Pascal Support (das Oxygene Plugin mal ausgenommen).

Nichtsdestotrotz würde technisch natürlich nichts dagegen sprechen...

Zitat von Patito:

Nur Hersteller von GUI-Komponenten haben natürlich ein Problem, wenn sie eine Trial-Version herausgeben wollen.
Richtig kaufen sollte man solche Komponenten ja sowieso nicht ohne Source.

Ich glaub DevArt bietet ne Trial seiner *DAC Komponenten an, welche dann halt für ne bestimmte Free Pascal Version ist (wenn keine IDE-Integration benötigt wird, dann muss man es nichtmal von der Lazarus Version abhängig machen).

Gruß,
Sven

[Sir Rufo]

Zitat von JamesTKirk:

Zitat von Sir Rufo:

Und die Unterscheidung ob Datei oder Verzeichnis ist sowieso egal, der PathDelimiter am Ende darf einfach nicht entfernt oder angehängt werden.

Ich weiß grad leider nicht, wie's konkrekt umgesetzt wurde. Das müsste man also ausprobieren...

Nö, es kommt immer ein Ergebnis ohne PathDelimiter raus, egal was man da rein gibt ... kann doch nicht so schwer sein ... obwohl, evtl. war das vorher so und haben die das geändert, weil die meisten damit nicht zurechtkamen

[Popov]

Zitat von Sir Rufo:

Nö, es kommt immer ein Ergebnis ohne PathDelimiter raus, egal was man da rein gibt ... kann doch nicht so schwer sein ... obwohl, evtl. war das vorher so und haben die das geändert, weil die meisten damit nicht zurechtkamen

Ich persönlich vertraue nie drauf, dass da wo Path steht, immer auch ein PathDelimiter am Ende steht. Ich weiß, dass es bei ExtractFilePath so ist und dementsprechend bei ExtractFileDir nicht, also alles der Regel nach. Das sind aber auch die einzigen Funktionen denen ich blind vertraue, muss ich auch, denn das muß ja funktionieren: ExtractFilePath(s) + 'Datei.dat'. Ansonsten sind in meinen Codes tausende von IncludeTrailingPathDelimiter Funktionen verteilt. Selbst meinen Funktionen traue ich nicht, obwohl ich mich an die Konvention halt. Man kann es mal vergessen. Aber sicher ist sicher.

[himitsu]

Wobei ExtractFilePath und ExtractFileDir auch ihre Bugs haben.

Denn bei den Rootpfaden muß auch ein DIR den Backslash am Ende haben!

C: ist das Laufwerk, aber C:\ ist der Path/Dir, denn C: ist relativ zum CurrentDir des Laufwerks.

[Sir Rufo]

Zitat von himitsu:

Wobei ExtractFilePath und ExtractFileDir auch ihre Bugs haben.

Denn bei den Rootpfaden muß auch ein DIR den Backslash am Ende haben!

C: ist das Laufwerk, aber C:\ ist der Path/Dir, denn C: ist relativ zum CurrentDir des Laufwerks.

Das Root-Verzeichnis nimmt hier eine Sonderrolle ein, da es keinen Namen dafür gibt (Root ist nur eine Bezeichnung).
Es wird lediglich durch den Laufwerksbuchstaben (C bzw. Freigabe (\\myserver\data) und dem darauf folgenden PathDelimiter bestimmt.