Delphi 11 (28) - Suchpfad für BPL Dateien ... wie einstellen ?

[paule32.jk]

Hallo,

immer wieder habe ich das Problem, das kompilierte BPL Dateien, die ggf. auch schon registriert sind,
von Delphi nicht gefunden werden können, wenn ein anderes BPL-Projekt übersetzt werden soll.

Kann man da was einstellen ?

wenn ja, wo ?

[jaenicke]

Wie ich schon in dem anderen Thread geschrieben habe...

Zitat:

Zitat von jaenicke (Beitrag 1526653)

Zitat:

Zitat von paule32.jk (Beitrag 1526652)

momentan liegen meine BPL Dateien zu JVCL in: E:\Projekte\jediRX\jcl\jcl\lib\d22\win32\bpl

Dann musst du diesen Pfad auch dem Systempfad (PATH) hinzufügen. Der Installer (der bei der CE nicht geht) packt diese Dateien in das BPL-Verzeichnis deiner Delphiinstallation, der schon im PATH drin ist.

Das sind im Grunde DLLs und die werden auch entsprechend gesucht.

[himitsu]

Ja, alle Packages müssen im Suchpfad (PATH) stehen,
denn wenn ein Package ein Anderes läd, dann über den Suchpfad (denn den Eintrag mit Pfad in der Registry, kennt das dort nicht.

So in "Known Packages" registriert
C:\Pfad\Package1.bpl
C:\Pfad\Package2.bpl

Wobei Package2 das Package1 in seinen Requires drin hat (also als DLL-Import, wie bei einer DLL)

Wird erst Packages1 und dann Package2 geladen, ist alles OK,
aber wird zuerst Package2 geladen, dann versucht Windows Package1 zu laden, aber wenn es Dieses nicht in den DLL-Suchpfaden findet, dann knallt es.
(Besonders schön auch, dass Delphi dann sagt "Package2 wurde nicht gefunden", obwohl Windows meint Package1 sei das Problem)
https://learn.microsoft.com/de-de/wi...y-search-order


Umgebungsvariablen:
Es kann das in dem %PATH% vom System sein (SystemVariables), im %PATH% vom WindowsBenutzer (UserVariables) oder das %PATH% im Delphi (Tools > Optionen > IDE > Umgebungsvariablen)

Zitat:

Zitat von himitsu (Beitrag 1526624)

z.B. die Compiler-Schalter in der DPK kommen aus der DPROJ, allerdings schwachsinnig die Variante der Basis-Config (wie um Himmels Willen soll der Dreck mit dem IMPLICITBUILDING funktionieren, wenn die falsche Config und falsche sonstige Projektoptionen, wie z.B. Ausgabepfade, verwendet werden)

Und dann noch den Quatsch mit ImpliciteBuilding, weil dort wird nur die DPK benutzt (nicht die DPROJ), wo dann die falsche Config (Basis und nicht das Aktive, wie z.B. Release oder Debug) in der DPR steht,
sowie auch eingestellte Ausgabepfade fehlen, die aus den Projektoptionen des impliziten Packages.




Wobei es dafür seit Jahren einen offenen Bugreport bei Emba gibt, denn sie bräuchten einfach nur vorm/beim Laden der Packages alle Pfade der registrierten Packages (zumindestens Jene, welche nicht in %PATH% stehen, als DLL-Suchpfad beim Windows registrieren. (temporär, während der Abarbeitung der Liste, oder einfach permanent)

Hätte also schon seit knapp einem Jahrzehnt behoben sein können. https://quality.embarcadero.com/browse/RSP-10321

[Uwe Raabe]

Zitat:

Zitat von paule32.jk (Beitrag 1526743)

das kompilierte BPL Dateien, die ggf. auch schon registriert sind,
von Delphi nicht gefunden werden können, wenn ein anderes BPL-Projekt übersetzt werden soll.

Zum Kompilieren werden die BPL-Dateien gar nicht benötigt, sondern eher die DCP-Dateien. Eine Ergänzung der PATH-Variable zu den BPLs wird daher vermutlich nicht viel bringen.

Man macht sich das Leben einfacher, wenn man bei DCP-Ausgabeverzeichnis und Package-Ausgabeverzeichnis einfach gar nichts angibt. Dann landen die beiden Dateien in den Standardpfaden der gerade verwendeten Delphi und werden in der Regel auch gefunden.

Für den Fall dass die Anwendung mit Laufzeit-Packages erstellt wird (was aus deinen Ausführungen erstmal nicht zu entnehmen ist), müssen die BPLs natürlich mit ausgeliefert werden und sollten am besten direkt im selben Verzeichnis wie die Exe liegen.

[paule32.jk]

@Uwe:
es handelt sich um JEDI, bei denen in der VCL Version Laufzeit, wie auch Design-Time Packages
handelt.
Leider kann ich kein GetIt installieren, weil dort Nichts angeboten wird, und den Umweg von
kompilieren per Hand gehen muss.

Ich habe auch festgestellt, das Delphi gerne mal Laufzeit und Design Packages mischt, und automatisch
hinzufügt, und man keine Möglichkeit hat, dies zu unterbinden.
Es wird dann ein OK-Button angeboten, der dann stupiderweise, ich weiß nicht woher es die Informationen
nimmt, Packages nachschiebt.
Und der Cancel-Button einfach das Info-Fenster schließt.

Kann man ja in manchen Thread's lesen, das dann aufwendig die Packages in Design und Runtime umgebastelt
werden müssen ...

Aber das mit den PATH werde ich nochmals prüfen ...

@himitsu:
Ich sehe gerade wieder 4 Probleme:
PATH gibt es nur einmal:

- PATH für 32-Bit Debug
- PATH für 64-Bit Debug

- PATH für 32-Bit Release
- PATH für 64-Bit Release

[himitsu]

Ein Package als Runtime markieren (Projektoptionen)
oder auch explizit als DesignTime.
:roll:

Die Jedi waren mal im GetIt der CE drin, aber da Jedi das GetIt bloß als Downloader nutzt und dann ein eigenes Setup startet, welches den Kommandozeilen Compiler (dcc32.exe / dcc64.exe) aufrufen will, was aber in der CE nicht geht ... ja, da war es besser, das aus GetIt zu verbannen, wenn es "so" eh nicht funktioniert.

[paule32.jk]

ich bekommes es nicht hin.
- habe den PATH erweitert, mit den des DCP, und BPL.
- das Delphi mit Admin Rechte gestartet, selbes Verhalten:

Code:

[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclIniFiles' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclResources' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclDevToolsResources' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclHelpUtils' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclMsBuild' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclCompilerUtils' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclTD32' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclPeImage' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclConsole' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclWideStrings' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclRegistry' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclSecurity' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclDateTime' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclFileUtils' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclLogic' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclStringConversions' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclCharsets' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'Jcl8087' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclStreams' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclWin32' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclSynch' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclUnitVersioningProviders' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclUnitVersioning' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclIDEUtils' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclDotNet' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclSimpleXml' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclDebug' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclHookExcept' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclSysUtils' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclStrings' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclUnicode' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclSysInfo' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclShell' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'Snmp' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclAnsiStrings' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclMath' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Warnung] JclBaseExpert.dpk(63): W1033 Die Unit 'JclBase' wurde implizit in Package 'JclBaseExpert' importiert
[dcc32 Fataler Fehler] JclStackTraceViewerExpert.dpk(42): E2202 Package 'JclBaseExpert' wird benötigt, konnte aber nicht gefunden werden
Misslungen
Verstrichene Zeit: 00:00:00.8

JclBaseExtern läßt sich aber übersetzen, und die DCP sowie die BPL existieren

[himitsu]

Die Fehlermeldungen sagen doch alles?
Einmal, weil du die REQUIRES vergessen hast.
Und die JclBaseExpert.dcp nicht in den Compilersuchpfaden gefunden wurde.

REQUIRES in Packages (DPK) und LaufzeitPackages in ProjektOptionen von DLL oder EXE werden immer genommen.
Wird die DCP nicht gefunden, dann knallt es mit "Package nicht gefunden".
Angegebene DCP müssen über den Suchpfad in IDE oder Projektoptionen gefunden werden können.

BPL-Suchpfade gehören für eines der PATH für die IDE, zum Laden der Packages.


DU hast aber Units in dein Package eingebunden, welche in ein anderes Package gehören.
Units müssen "namentlich" global in der gesamten IDE-Instanz eindeutig sein.
Also selbst wenn du es kompilieren könntest, würde es dann beim Versuch das in der IDE zu laden sowieso knallen.

DU musst also dein Package so kompilieren, dass es die andere BPL benutzt, anstatt selbst diese Units einzukompilieren.

Implizit heißt, dass diese Unit nicht "explizit" zum Projekt gehören (also in DPR/DPK nicht explizit via IN im USES eingetragen sind, sondern sie "implizit" irgendwo in DPR/DPK/PAS in irgendeinem USES bloß genannt wurde und eventuell über Suchpfade gefunden wurde)

[Stolle58]

Hallo Paule32,
wo hast Du die Jedi's den her.

[paule32.jk]

@stolle:

die kannst Du auf meinen github account saugen

[Delphi.Narium]

Die Frage war wohl eher nicht, ob Du eine Kopie hast, sondern woher Du die Kopie hast.

Das Original ist hier zu finden: https://github.com/project-jedi bzw. hier: https://jcl.sourceforge.net/daily/

Alles andere ist eher unseriös.

[paule32.jk]

die Quelle war von einen älteren git-fork - müsste doch dabei stehen ...

[Stolle58]

Zitat:

Zitat von Delphi.Narium (Beitrag 1526818)

Die Frage war wohl eher nicht, ob Du eine Kopie hast, sondern woher Du die Kopie hast.

Richtig.

@Paule.Jk
Die Jedi's bringen eine "Installations.bat" Datei mit, die das Installations-Programm neu erzeugen.
Bitte beachte bei den Jedi's.
Du Benötigst unbedingt JCL und die JVCL, damit das comilieren klappt.

[himitsu]

Die BAT und EXE bringen ihm nichts, da in der Delphi CE einiges fehlt, wie z.B. der Kommandozeilen-Compiler.

Aber dann aktuell eine "ominöse" Version der JCL/JVCL unterzuschieben, anstatt des Originals und womöglich auch noch aktuell ...
Warum eine "andere" Version davon und wenn, welche Version ist das denn? (das sollte unbedingt mit genannt werden)


Natürlich ist es nicht verboten einen Fork vom Original zu nehmen, damit der eigene Code zur Fehlervermeidung mit einen definierten Stand arbeiten kann und man die Möglichkeit von eigenen Bugfixes/Anpassungen/Erweiterungen hat, aber dennoch kann leicht die originalen Neuerungen reinziehen und vorallem kann man sehen ob/was anders ist.

[paule32.jk]

@himitzu:

genau wegen dieser Einschränkungen der CE, habe ich zwei Tage für die Katz kompiliert.
Bitte nehmt es mir nicht für übel, wenn ich zurück zur Delphi 7 Version jehüpft bin,
da diese Version ja auch noch lauffähigen 32-Bit Code erzeugt, der unter 64-Bit Windows
ausgeführt werden kann, und ich mich darauf konzentriert habe, bei anderen Anbietern, eine
Vollversion zu bekommen.

Die Personal D7 ist auch gut, allerdings ist dies nur eine Testversion, und es ist ja auch
egal, wieviel Programmierer drann sitzen - die D7 ist für Einzelperson ausgelegt und die Personal
nur für Evaluation-Zwecke sowie Lehrnzwecke gedacht.

Aber man hat dann weniger das Problem, das man immer aktual: up-tu-däeit sein muss, und ich habe
gerade Heute früh eine Mail hereinbekommen, wo schon die Version 12 vom RAD Studio angekündigt
wurde.

Ich bin nicht so der Trendsetter, und verwende altherbekanntes, was dann auch funktioniert.

Um den Lizenzkrampf der einzelnen Pakete und/oder Anbieter entgegen zu wirken, veröffentliche ich
meine Projekte schon über 10 Jahre als OpenSource.
Dadurch kann jeder selbst entscheiden: kauf ich mir nun eine Vollversion, um den Quellcode zu
übersetzen, oder verwende ich ein kompiliertes Projekt, mit den Wissen, dass diese Form der
Publizierung von mir nur als Education Version angeboten wird, und es nicht erlaubt ist , Copyrights
oder Gewinn mit den Produkt zu machen.

Dazu setzen ich auf github.com meistens die Lizenz auf MIT.

MIT erlaubt das ändern, und kopieren von Code, wobei aber die Quellen unverändert mitgegeben bzw.
zugänglich gemacht werden müssen. Außerdem ist die Notiz der Autoren und deren Copyrights, die
nach Deklaration der MIT erfolgen, mitzugeben.

Die izenzen die ich so kennen gelernt habe erlauben die unver#nderte Version der Lizenz, und/oder
sie erlauben sogar Ergänzungen, die aber die vorhergehenden Vereinbarungen verletzen oder gar
aushebeln.

Die Version der JEDI CL und VCL, die ich momentan einsetze beläuft sich auf Version 3.0.
Es gibt aber schon eine neuere Version - soweit ich weiß bewegt sich dies so auf den Level 3.3.

Die JEDI Lib ist ein sehr großer Umfang von Komponenten und Tools, wovon ich aber vielleicht mal
1/3 benötige bzw. verwende.

Die 3.0 Version wird kostenlos von JEDI Community zur Verfügung gestellt.

Der Installer kann zwar erstellt werden, allerdings nützt das wenig, da der Installer auf Version
3.3 immer ein Hilfstool aufruft, das dann auf die Existenz vom RAD Studio 10, oder 11 abklappert.

Auch das Modifizieren der PATH Umgebungsvariable bringt nichts, also, wenn man versucht, das Alte
Delphi dcc32.exe als ersten Eintrag setzt, wird durch das interne Programm dcc32ex.exe glaube die
Windows-Registry durchsucht.
Anders kann ich mir nicht vorstellen, wie der Installer.bat immer die neuesten Version von RAD
daherklabautert.

Ein weiterer Schritt zurück zu D7 von mir ist, das man CrossCompiling machen muss, um die Pakete
vollständig zu übersetzen - also mit der CE.

Dann fehlt da ein Eintrag, dann ist der Eintrag falsch ...
Nene, das ist Alles nichts für mich.

Ich muss aber auch betonen, das man viele andere Möglichkeiten mit CE oder Rad Studio 11 hat, die
so nicht in D7 vorhanden sind - zum Beispiel die Abgrenzung von DEBUG/RELEASE/32-Bit/64-Bit.

Ich habe keine Firma, und brauche mich also um Lizenzen nicht kümmern, die eingekauft werden müssen,
wenn man kein non-profit Programm auf den Markt bringen möchte, und dahinter Menschen und deren
Familie stehen (Arbeiten, umd Essen, Kleidung, ... zu kaufen).

Wie gesagt, das ganze ist Hobby, und Lust an der Dallerrei.

Und was ja eventuell nicht viele Wissen:
- auch Gedanken sind Materielle-Werte, worunter auch die Logik des Produktes darunter zu Versten
ist, und durchaus per Donut an der Weiterentwicklung gespendet werden kann.
- Allerdings Wissen auch nicht viele, das die Donut-Spenden zweckgebunden eingesetzt werden müssen.
Das heißt: Ich kann die QuellCode-Donuts nicht selber Essen, sonder wieder Spenden - zum Beispiel
an die Tafel, oder (jetzt weggucken) das Programmierteam mit zusätzlichen Kaffee verköstigen...

[jaenicke]

Ich habe keine Ahnung warum es bei dir nicht funktioniert. Eigentlich sind es wirklich nur wenige Schritte:

• Repository auschecken, Submodule Update ausführen (für die jedi.inc)
• Die Pfade jcl\jcl\lib\d28\win32, jcl\jcl\source\include, jvcl\jvcl\lib\d28\win32 und jvcl\jvcl\resources mit voller Pfadangabe zum Bibliothekspfad Win32 hinzufügen
• "jcl\jcl\packages\JclPackagesD280.groupproj" öffnen, auf dem ersten Eintrag "JclPackagesD280" rechtsklicken und "Alle kompilieren" klicken
• Alle Einträge mit den grünen Symbolen mit rechts anklicken und "Installieren" klicken
• Das gleiche mit "jvcl\jvcl\packages\D28 Packages.groupproj" machen

Die BPLs landen schon an der richtigen Stelle, weitere Anpassungen sind also gar nicht nötig.

[himitsu]

Wie bereits erwähnt wurde,kann man die JEDI auch benutzten, ohne sie zu registrieren.
* Download von GIT
* Suchpfad zu den PAS in Tools>Optionen oder Projektoptionen
* und schon geht's (außer dass es keine IDE-Experten, sowie nichts KlickBunti im FormDesigner gibt ... aber im Quellcode keine Einschränkung)

Hey, es gab mal kostenlose Delphis, da konnte man garkeine Fremdpackages registrieren ... dagegen ist aktuell viel möglich.
Dass die JEDI sich im GeIt so "blöd" anstellen, dafür kann Embarcadero nichts.

[paule32.jk]

siehe Anhang.
passt.

Bilder vom alten Post gelöscht.

[haentschman]

Zitat:

passt

... eben nicht. Bitte hoste die Bilder HIER in der DP. "Dateien anhängen" ... weiter unten beim Schreiben. :zwinker:

Nicht jeder gibt allen Webseiten und damit der verbundenden Domains die Rechte für die Verarbeitung seiner Daten! :warn: ...es sind eh schon genug. :kotz:
PS: Und die Bilder sind weg, wenn die Hoster nicht mehr da sind. :zwinker:

[MEissing]

Zitat:

Zitat von paule32.jk (Beitrag 1526842)

Ich habe keine Firma, und brauche mich also um Lizenzen nicht kümmern

Du irrst dich immer noch.

Auch ein Delphi 7 Enterprise oder die Personal unterliegt Lizenzbedingungen.

[paule32.jk]

Hallo Mathias,

Ich habe meine Recherchen noch nicht vollständig, da mir nur eine englisch sprachliche Lizenz
mir vorliegt, und mein Englisch nicht so tolle ist.

Daher bin ich gerade dabei, auf Flohmarktportalen nach jemanden zu Suchen, der seine Lizenz
abtretten würde.

ABER:
Soviel ich schon mitbekommen habe, ist, dass die Lizenzen an einer bestimmten Person gebunden sind.
Wenn ich also dann eine D/ Version mir Eigenen hab, kann ich ja Quasi das Programm nicht nutzen,
weil es ja auf die Person ausgeschrieben wurde, die das Programm registriert hat - oder ?

Was ich nicht verstehe ist, wenn auf einen Produkt, das schon 20 Jahre Alt ist, auch kein Support
mehr geleistet wird so auf Lizenzen geachtet wird.
Gibt es da keine Möglichkeit, wie sowas wie ein Generalschlüssel, der für private, schulische Zwecke
verwendet werden kann ?

Es ist ja nicht so, das ich keine Lizenz kaufen würde - das Interesse ist bei mir sehr groß.
Aber ich denke mal dass es vielleicht besser wäre über solche Sachen per E-Mail sich zu unterhalten ?

Nur, ich denke mal, das es auch noch Andere Benutzer gibt, die sich eine "alte" Community Lizenz
gegen Bezahlung zulegen würden.

Ich habe auch noch keinen Schimmer, wenn ich mir CE zulege, um damit die 5.000 Euro Marke zu erreichen,
die ich aus Donuts gesponsert bekommen habe, ob dann nicht auch Steuern gezahlt werden müssen...

Weil, wenn ich mich nicht recht täusche, in Deutschland ALLES so geregelt ist, was nicht ohne
Steuergelder abgegolten wird.

Selbst beim Tot gibts doch noch die Erbschafts-Steuer...

Wenn dann nun aber die Person stirbt, auf die die Lizenz gelaufen ist, dann kann ja der Sohn oder
das Enkelchen vom Opa, die gesamte Computerausrüstung wegschmeißen, weil dann doch sicherlich die
Lizenz erlischt (bis der Tot Euch scheidet) ?

Ist doch in einen kapitalistischen Marktgeschehen eher zweifelhaft (weil, der Rubel muss doch rollen !)
oder sehe ich das Jetzt verkehrt ?

[haentschman]

Zitat:

Ich habe auch noch keinen Schimmer, wenn ich mir CE zulege, um damit die 5.000 Euro Marke zu erreichen,

Du MUSST mit der Community Edition KEINEN (in Worten: KEINEN 8-)) Umsatz machen! Erst wenn dein Umsatz 5000€ ÜBERSTEIGT, dann mußt du eine große Version kaufen. :zwinker:

Für dich ist die Community Edition...modern und legal. Du mußt NICHTS (in Worten: NICHTS) bezahlen! :zwinker:

Schmeiß die D7, alte Community Version, alle Delphi Trial Versionen und alle illegalen heruntergeladenen Versionen von der Platte!
Dann installiere die Community Edition neu. (den Key hast du ja = legale Lizenz) Dann die JEDI entsprechend der Anleitung. :zwinker:

PS: Erst dann helfen wir dir mit der Datenbank Geschichte...8-)

[MEissing]

(Danke haentschman)

Eine Benutzer-bezogene Lizenz ist dem Benutzer zugeordnet. Bei der initialen Aktivierung ist dies vom Lizenznehmer frei wählbar. Eine nachträgliche Überschreibung der Lizenz ist kostenlos, wenn die Lizenz unter Wartung (Update Subscription) steht. Das ist zB ein Problem bei Gebrauchtlizenzen(!)

(Anders sieht es bei Netzwerklizenzen aus. Da kann man als Lizenzadministrator die Benutzer selbst zuweisen)

[himitsu]

Die alten TurboPascal darfst du kostenlos uneingeschränkt nutzen. :stupid:
OK, von den Amis geht es nur bis TP 6.0 5.5, aber die Franzosen hatten auch ihre TP 7.01 freigegeben.
Ist zwar keine Freeware, aber Abandonware (antique software).

[jaenicke]

Embarcadero hatte auch Delphi 7 Personal freigegeben, sofern man die Software selbst hat. Diese war z.B. auf alten Delphi for Kids Büchern, die es in Bibliotheken noch gibt, enthalten.
Hier mehr dazu:
https://entwickler-ecke.de/topic_Off...r_92913,0.html

[MEissing]

Zitat:

Zitat von himitsu (Beitrag 1526862)

Die alten TurboPascal darfst du kostenlos uneingeschränkt nutzen. :stupid:
OK, von den Amis geht es nur bis TP 6.0 5.5, aber die Franzosen hatten auch ihre TP 7.01 freigegeben.
Ist zwar keine Freeware, aber Abandonware (antique software).

Abandonware <> Antique Software!!

Von der original "Antique Software" Seite:

Zitat:

These historical files are provided to the Borland community free of charge. They may be downloaded and used "as is" for personal use only. No developer support is provided. Each individual product contains copyright notices that are still in force.

Hinweis: Ich will euch nicht ärgern. Ich möchte euch nur vor Schaden bewahren. Privat- wie auch geschäftliche Nutzung. Ja. Wir haben eine eigene Abteilung, die sich um illegale Kopien kümmert.

[jaenicke]

Zitat:

Zitat von MEissing (Beitrag 1526866)

Hinweis: Ich will euch nicht ärgern. Ich möchte euch nur vor Schaden bewahren. Privat- wie auch geschäftliche Nutzung. Ja. Wir haben eine eigene Abteilung, die sich um illegale Kopien kümmert.

Und laut Gehaltswebseiten verdienen die Mitarbeiter dieser Abteilung auch am meisten. Klar, kann ich nicht prüfen, aber im Vergleich zu anderen Firmen fällt das schon auf. So verkehrt liegen diese Webseiten ja meistens nicht.

Wobei ich an der Stelle nicht verstehe, dass uralte Versionen, die man gar nicht mehr offiziell kaufen kann, nicht einfach für private Zwecke und auch zum Testen freigegeben werden. Ich wollte vor einigen Jahren z.B. einfach nur veröffentlichte Quelltexte kompatibel mit alten Versionen halten. Die aktuelleren Versionen hatte ich ja über die Möglichkeit, auch Vorgängerversionen beim Kauf zu erhalten, aber die davor eben nicht.

Für den Zweck wird man dann gezwungen, entweder darauf zu verzichten oder illegale Quellen zu nutzen. Das finde ich sehr schade... Warum gibt es nicht zumindest die offizielle Erlaubnis, auch noch ältere Versionen zu nutzen, wenn man eine aktuelle Lizenz hat? Da ist es ja schon rein theoretisch nicht möglich, dass Embarcadero das auch nur einen Cent Umsatz kostet. Schließlich werden die Versionen nicht mehr angeboten (sonst hätte ich dafür ja auch bezahlt) und eine aktuelle Lizenz liegt ja vor.
Davon abgesehen dürfte es für Embarcadero ziemlich unmöglich sein, die Verwendung solcher Versionen, die nicht nach Hause telefonieren und ohne Lizenzserver aktivierbar waren, festzustellen.

Nebenbei war das auch der Grund, weshalb ich privat keine Version gekauft hatte. Ich hatte ja Zugriff auf die auch beruflich genutzte Lizenz. Und da nicht alle Versionen enthalten waren, auch nicht gegen Aufpreis, gab es für mich privat keinen Anreiz, eine Version zu kaufen.

[mmw]

Hallo,

Zitat:

Zitat von himitsu (Beitrag 1526828)

Die BAT und EXE bringen ihm nichts, da in der Delphi CE einiges fehlt, wie z.B. der Kommandozeilen-Compiler.

die würden aber die Verzeichnisse in der IDE eintragen - zumindestenz bei mir war es so.

Gruß

[MEissing]

Bis runter zu Delphi 7 verkaufen wir ja. (Bis auf D8/2005/2006)

Du denkst an Delphi 1 bis 6?

[paule32.jk]

sodele....
hui, das war ne fukkellei.
Ich habe es hinbekommen, indem ich eine Datei geändert habe (irgendwas mit Versioning).

meine Arbeit für Heute, siehe Anhang.
Ich bin mal gespannt, ob sich das D7 Projekt nach CE übertragen läßt ...

[jaenicke]

Zitat:

Zitat von MEissing (Beitrag 1526870)

Bis runter zu Delphi 7 verkaufen wir ja. (Bis auf D8/2005/2006)

Das habe ich in Form von Turbo Delphi.

Zitat:

Zitat von MEissing (Beitrag 1526870)

Du denkst an Delphi 1 bis 6?

Ja, mittlerweile allerdings eher aus historischen Gründen. Damals schlicht, weil es noch eingesetzt wurde.

Ja, mir fällt ein, dass da etwas war mit den Rechten an den Versionen, dass Embarcadero die nicht hat oder so. Allerdings hieße das natürlich auch, dass Embarcadero Lizenzverletzungen dieser Versionen ohnehin nicht verfolgen würde, oder?

[himitsu]

Zitat:

Abandonware <> Antique Software!!

OK, das wurde überall immer zusammen genannt, da könnte man denken es wäre equivalent. (z.B. deutsche und englische Wikipedia und andere Artikel, von als es damals freigegeben wurde ... bin mir fast sicher, als wenn es damals auch bei Embarcadero so im Artikel stand)

Zitat:

Zitat von jaenicke (Beitrag 1526868)

Wobei ich an der Stelle nicht verstehe, dass uralte Versionen, die man gar nicht mehr offiziell kaufen kann, nicht einfach für private Zwecke und auch zum Testen freigegeben werden.

Jupp, so wie ich das verstanden hatte, hatte Embarcadero quasi die Rechte daran nicht gekauft.
Ich weiß jetzt nicht, ob es schon im Codegear nicht drin war, oder später entfiel,
aber daher können sie es auch nicht rausgeben. (und natürlich auch nicht gegen Illegales vorgehen, was ihnen nicht gehört)

Wobei, Borland dann doch noch die Rechte besitzen müsste, und die hätten können wollen.

Zitat:

Zitat von jaenicke (Beitrag 1526868)

Und da nicht alle Versionen enthalten waren, auch nicht gegen Aufpreis,

Wobei es da schon seit Längerem etwas gibt.
https://www.embarcadero.com/de/produ...vious-versions
Für Delphi, C++Builder und RAD-Studio.

Wobei der Text irgendwie immer so klingt, als wenn man es nur beim Neukauf bekommen kann, oder zählt der Kauf einer SubscriptionVerlängerung auch dazu?
Und dann auch nur ein paar Monate lang, was blöd wäre, falls man vorher noch nicht davon wusste.
(da ich inzwischen von Denen alle Versionen zusammen habe, damals durch diese PreviousVersions, hatte ich nicht weiter genauer danach gefragt ... aber die EEP, da wäre es zu geil sie noch zu bekommen)

[MEissing]

Die Anforderungsmöglichkeit der Altversionen steht in der Auftragsbestätigung („Order Confirmation“)

[haentschman]

@paule32.jk

:thumb: geht doch...

Jetzt richte dir die IDE ein.
* Positionen der "Fenster" in der IDE (Standard, Debug)
* deine bevorzugten Farben für verschiedene "Eigenschaften" und die IDE selbst
* Nützliche Tools in die IDE: (jeder Geschmack ist anders :wink:)
- CnPack
- GExpert
* Nützliche Tools Extern:
- Versionskontrollsystem GIT! Ein Muß! Tutorial: https://entwickler-ecke.de/topic_Kur..._115462,0.html Geht auch mit BitBucket, GITHub etc...außer Haus.
- MadExcept. Ein Muß. Im Fehlerfalle zeigt er dir den Fehler und die Stelle mit Zeilennummer und Callstack.
- BeyondCompare. Ein gutes DIFF Tool. Bei Delphi in der Basisversion dabei. "C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\BCompareLite.exe "

Dann lege mal Los...8-)


Tipp für die Zukunft:
Versuche dich von Fremdkomponenten, soweit es geht, unabhängig zu machen. Das erleichtert dir den Umstieg.
Bsp. TJvEdit vs. TEdit. Imho kannst du nicht das TJvEdit mit den VCL Styles (Themes) verändern...

[jaenicke]

Zitat:

Zitat von haentschman (Beitrag 1526895)

- MadExcept. Ein Muß. Im Fehlerfalle zeigt er dir den Fehler und die Stelle mit Zeilennummer und Callstack.

Aber normalerweise nur, wenn man auch Tools veröffentlicht. Selbst hat man ja Delphi und sieht den Stacktrace im Debugger, es sei denn der Fehler wäre nicht reproduzierbar.

[himitsu]

Bei Debuggen noch sowas wie MadExcept/Eurekalog drin zu haben, ist aber auch nicht so toll. (besonders geil wird es, wenn man das inkl. dessen eigenen Debuginfos kompiliert hat :freak:)

[Sinspin]

MadExcept pumpt zwar den Stacktrace auf den man im Fall eines Fehlers serviert bekommt.
Allerdings finde ich die Auswertung des Fehlers deutlich besser als was Delphi macht.

Und, mein Programm läuft noch! Mit dem Delphi Debugger ist die Chance hoch dass nach der Exception alles tot ist weil einfach alle Threads angehalten werden.

[haentschman]

Zitat:

Allerdings finde ich die Auswertung des Fehlers deutlich besser als was Delphi macht.

+1 :thumb:

[jaenicke]

Zitat:

Zitat von Sinspin (Beitrag 1526910)

MadExcept pumpt zwar den Stacktrace auf den man im Fall eines Fehlers serviert bekommt.
Allerdings finde ich die Auswertung des Fehlers deutlich besser als was Delphi macht.

Du siehst in Delphi die einzelnen Threads inkl. Bezeichnung, kannst durch die einzelnen Einträge klicken, siehst dabei auch die Inhalte von Variablen in den aufrufenden Codestellen, wenn sie nicht überschrieben wurden, kannst im Speicher nachschauen, die CPU-Register und den Stack prüfen, ...

Das sehe ich daher anders.

Schade ist nur, dass Delphi beim Wechseln des betrachteten Threads manchmal hängenbleibt, selten zum Glück, aber es kommt vor.