AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Lazarus 1.2 veröffentlicht

Ein Thema von JamesTKirk · begonnen am 11. Mär 2014 · letzter Beitrag vom 20. Aug 2019
Antwort Antwort
Seite 2 von 4     12 34   
michaelthuma
(Gast)

n/a Beiträge
 
#11

AW: Lazarus 1.2 veröffentlicht

  Alt 13. Mär 2014, 13:05
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.

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?
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#12

AW: Lazarus 1.2 veröffentlicht

  Alt 13. Mär 2014, 14:22
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
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.536 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#13

AW: Lazarus 1.2 veröffentlicht

  Alt 13. Mär 2014, 16:05
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.

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.
Andreas
#PerfMatters
  Mit Zitat antworten Zitat
michaelthuma
(Gast)

n/a Beiträge
 
#14

AW: Lazarus 1.2 veröffentlicht

  Alt 13. Mär 2014, 16:39
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 ...

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.

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.
  Mit Zitat antworten Zitat
Popov
(Gast)

n/a Beiträge
 
#15

AW: Lazarus 1.2 veröffentlicht

  Alt 13. Mär 2014, 18:29
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.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
34.931 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#16

AW: Lazarus 1.2 veröffentlicht

  Alt 13. Mär 2014, 19:26
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#17

AW: Lazarus 1.2 veröffentlicht

  Alt 13. Mär 2014, 19:37
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von JamesTKirk
JamesTKirk

Registriert seit: 9. Sep 2004
Ort: Eberfing
597 Beiträge
 
FreePascal / Lazarus
 
#18

AW: Lazarus 1.2 veröffentlicht

  Alt 14. Mär 2014, 06:30
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...

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
Sven
[Free Pascal Entwickler]
this post is printed on 100% recycled electrons

Geändert von JamesTKirk (14. Mär 2014 um 06:30 Uhr) Grund: zweiten Teil vergessen, den ich mit posten wollte *blush*
  Mit Zitat antworten Zitat
schöni

Registriert seit: 23. Jan 2005
Ort: Dresden
445 Beiträge
 
Delphi 7 Personal
 
#19

AW: Lazarus 1.2 veröffentlicht

  Alt 14. Mär 2014, 08:45
Zitat von JamesTKirk:
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 von Patito:
Zitat von QuickAndDirty:
]
Ich arbeite gerne damit. Allerdings fehlt wirklich sowas wie ein Package-Konzept(dynamisch gelinkte Packages) für FreePascal!
Das erschwert unnötig einen Professionellen Ansatz mit massig zugekaufter Vorleistung.
Das habe ich früher auch mal gedacht, aber qualitativ gute 3rd-Party Libraries (für Excel, Word, pdf, CAD, Geräte-Steuersoftware...)
gibt es doch eher selten als (proprietäres versionsabhähgiges) Delphi-Packages, normalerweise kauft man so ein qualitativ hochwertiges
Ding als DLL. Dafür gibt es dann einen freien Open-Source Pascal-Wrapper und gut.
Hmmmm, so extrem lange dauert solche Neuübersetzung auch wieder nicht, aber es gibt bei fehlerhafter Programmierung den gravierenden Nachteil, das dann die Übersetzung fehl schlägt. Hatte das bei Lazarus 1.0.6. Jetzt hab ich die Version 1.0 installiert, mit derich sehr zufrieden bin. Die 1.2er Version hab ich noch nicht getestet. Werde das nur machen, wenn ich das unabhängig von meiner 1.0 Version machen kann.

Die hier zitierten Argumente relativieren das Package Problem nun auch wieder, aber für mich ist und bleibt dieses Problem auch ein interessanter Aspekt. Ich habe nämlich noch immer nicht verstanden, warum hier die totale Neuübersetzung überhaupt erforderlich ist. Mir ist klar, das dies der Fall ist, wenn die Komponenten als neue Units statisch eingebunden werden. ABER: Kann man diese nicht auch als normale Dlls einbinden, per Interfaces?

Ein Komponentenmanager könnte so aussehen (nur Interface)

type
IComponentFactory = Interface(IInterface)
function GetComponents(Index: Integer): TComponent;
procedure SetComponents(Index: Integer; value: TComponent);
property Components[Index]: TComponentList read GetComponents write SetComponents;
property ComponentCount: Integer; //Anzahl aktuell in IDE verfügbare Komponenten
end;

Nun müssten die Komponenten von außen per dll angeschlossen werden;

Wo ist da mein Denkfehler, wenn da einer ist? In den Eigenschaftseditoren gibt es doch auch Methoden wie Get/SetVerb u.a. die könnte man doch veranlassen, passenden Quelltext in den Codeeditor zu schreiben. Dabei sollte es egal sein, ob das von der IDE oder von der geladenen Dll aus passiert. Ich stelle die Frage jetzt mal hier. Bei genügend Interesse am Thema darf das auch in einen separaten Thread ausgelagert werden oder Ihr teilt hier mit, das ich bitte einen separaten Thread dazu auf machen soll. Soll ich?
Damit der Topf nicht explodiert, lässt man es ab und zu mal zischen.
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.536 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#20

AW: Lazarus 1.2 veröffentlicht

  Alt 14. Mär 2014, 09:23
Zitat von JamesTKirk:
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 von Patito:
Zitat von QuickAndDirty:
]
Ich arbeite gerne damit. Allerdings fehlt wirklich sowas wie ein Package-Konzept(dynamisch gelinkte Packages) für FreePascal!
Das erschwert unnötig einen Professionellen Ansatz mit massig zugekaufter Vorleistung.
Das habe ich früher auch mal gedacht, aber qualitativ gute 3rd-Party Libraries (für Excel, Word, pdf, CAD, Geräte-Steuersoftware...)
gibt es doch eher selten als (proprietäres versionsabhähgiges) Delphi-Packages, normalerweise kauft man so ein qualitativ hochwertiges
Ding als DLL. Dafür gibt es dann einen freien Open-Source Pascal-Wrapper und gut.
Hmmmm, so extrem lange dauert solche Neuübersetzung auch wieder nicht, aber es gibt bei fehlerhafter Programmierung den gravierenden Nachteil, das dann die Übersetzung fehl schlägt. Hatte das bei Lazarus 1.0.6. Jetzt hab ich die Version 1.0 installiert, mit derich sehr zufrieden bin. Die 1.2er Version hab ich noch nicht getestet. Werde das nur machen, wenn ich das unabhängig von meiner 1.0 Version machen kann.

Die hier zitierten Argumente relativieren das Package Problem nun auch wieder, aber für mich ist und bleibt dieses Problem auch ein interessanter Aspekt. Ich habe nämlich noch immer nicht verstanden, warum hier die totale Neuübersetzung überhaupt erforderlich ist. Mir ist klar, das dies der Fall ist, wenn die Komponenten als neue Units statisch eingebunden werden. ABER: Kann man diese nicht auch als normale Dlls einbinden, per Interfaces?

Ein Komponentenmanager könnte so aussehen (nur Interface)

type
IComponentFactory = Interface(IInterface)
function GetComponents(Index: Integer): TComponent;
procedure SetComponents(Index: Integer; value: TComponent);
property Components[Index]: TComponentList read GetComponents write SetComponents;
property ComponentCount: Integer; //Anzahl aktuell in IDE verfügbare Komponenten
end;

Nun müssten die Komponenten von außen per dll angeschlossen werden;

Wo ist da mein Denkfehler, wenn da einer ist? In den Eigenschaftseditoren gibt es doch auch Methoden wie Get/SetVerb u.a. die könnte man doch veranlassen, passenden Quelltext in den Codeeditor zu schreiben. Dabei sollte es egal sein, ob das von der IDE oder von der geladenen Dll aus passiert. Ich stelle die Frage jetzt mal hier. Bei genügend Interesse am Thema darf das auch in einen separaten Thread ausgelagert werden oder Ihr teilt hier mit, das ich bitte einen separaten Thread dazu auf machen soll. Soll ich?
1. Relativiert das nichts, denn wenn ich eine Trial für meine Komponenten ausliefern will geht das nicht! Genau so sieht es aus wenn ich closed source Komponenten verkaufen möchte.

2. Packages sind DLLs nur das sie sich beim Laden in die VMT der Anwendung einfügen. Wenn du das Problem umgehen willst das eine DLL eine eigene VMT hat, kannst du natürlich idealerweise alle Komponten auf Interfaces umstellen, das muss dann auch für alle Bezüge der Kompenenten untereinander gelten. Jedes property, jede Funktion oder Prozedur. Ich fände es aber gut so, vor allem wenn es KEINE Pascall DLLs sind sondern Stdcall DLLS.
Aber wie willst du von einer nur als Interface verfügbaren Komponente erben?
Andreas
#PerfMatters
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:32 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf