Probleme nach Installieren von TeeChart 8 Pro in RAD 2007

[EccoBravo]

Hallo,

ich dümple immer noch im Dreieck TeeChart QuickReport FastReport herum.

Habe eben nochmal TeeChart 8 Pro in RAD Studio 2007 von der Companion CD installiert.
Vorbereitend habe ich in der Systemsteuerung TeeChart deinstalliert,
dann im FileExplorer alle gebliebenen Dateien *tee*.* gesucht, und die,
welche irgendwie mit RAD2007 zutun hatten, gelöscht.
Da auf meinem Rechner noch Delphi7 läuft, habe ich aber alle Dateien *tee*.*,
die mit Delpi7 zusammenhängen, bestehen lassen (an den Verzeichnissen erkannt).

Manchmal beim Starten von Delphi2007 kam schon wieder die Fehlermeldung:
daß er Komponente dclTeePro811 o.ä. nicht finden kann
(kann ich jetzt leider nicht für den genauen Wortlaut reproduzieren)


Als ich dann eine VCL-Formularanwendung unter "Neu" erstellt hatte und dort ein TChart aus der Toolpalette hineinladen wollte, frechte mich wieder eine Fehlermeldung an:

Package "tee7100" kann nicht geladen werden. Es enthält die Unit "TeeAbout", die auch im Package "Tee811" enthalten ist
Ein Diagramm erscheint dann nicht in der Form und das TeeChart-Package mit der TChart-Komponente ist aus der Toolpalette verschwunden.

Die Suchpfade zu den TeeChart-Dateien ist aber angegeben.

Manchmal kann ich in Package installieren das Häkchen bei TeeChart 8 Pro neu setzen und dann geht es.

Was ist hier das Problem?

Kann doch nicht sein, daß das Installiren der mitgelieferten Komponenten mehr Arbeit macht, als das Programmieren selbst.

Vielen Dank für Hilfee

E. B.

[EccoBravo]

PS:

tee7100.bpl habe ich in E:\WINDOWS\System32 gefunden.

Gruss E. B.

[hanspeter]

Zitat:

Zitat von EccoBravo

PS:

tee7100.bpl habe ich in E:\WINDOWS\System32 gefunden.

Gruss E. B.

Kommt mir bekannt vor.
Die Krönung hast du aber noch nicht erreicht. Wenn Delphi lange genug mit einer neuen Teechart Version läuft, meldet sich
bei jedem Start dann der Delphi Installer und will das Orginal nachinstallieren.

Seit D2005 gibt es einen immer noch nicht beseitigten Bug. Beim Deinstallieren einer Komponente wird der Componentencache
in der Registry nicht aufgeräumt.
Deinstalliere doch das Paket nochmal. Dann beseitige manuell alle Bezüge auf die Komponente in der Registry.
Dann sorge dafür, das D2007 nur seine Componenten "sehen" kann. Also aus System32 entfernen.
Es genügt wenn man unter "Microsoftwirrwarr\Dokumente Einstellungen\rad5.0 und nochwas nur die Verzeichnisse BPL und DCP
in den Suchpfad aufnimmt.
Unter D2005 habe ich die Teechart prof Version mal gekauft und ärgere mich heute noch darüber.

Gruß Peter

[EccoBravo]

Danke Peter,

so besch.. das alles ist, Du hast mich mit Deiner Antwort etwas getröstet, ich habe schon ernsthaft an meiner Person gezweifelt.
Schon unter Delphi7 war die Komponenteninstallation nicht immer leicht. Es war manchmal wie mit einem ADHS-Kind, immer bockig, wenn es nicht genau so gemacht wird wie er es gerade haben will, nur sagt er es nicht.
Eigentlich wollte ich programmieren und nun muß ich ständig RAD streicheln. Ich glaube, hier entwickelt sich gerade eine neue IT-Fachrichtung!

Nun genug gemeckert, jetzt meine produktiven Fragen:

Wie beseitige ich manuell alle Bezüge auf die Komponente in der Registry?

Wie und wo räume ich genau den KomponentenCache in der Registry auf?

Soll ich alle Dateien, die wie *tee*.* aussehen in der Windows\System32 löschen?

Welche Pfade dürfen im Suchpfad ... nicht drin stehen?

Mit dem Löschen irgendwelcher *tee*.* in den RAD-fremden und Delphi7-fremden Verzeichnissen ärgere ich damit nicht andere Programme wie Delphi7, Excel und PowerPoint?

Vielen Dank für Deine / Eure Hilfe
und Grüße aus der German-Province

E. B.

[hanspeter]

Zitat:

Zitat von EccoBravo

Danke Peter,


Nun genug gemeckert, jetzt meine produktiven Fragen:


E. B.

Der Componentencache steht unter Codegear, da ist dann ein Wurzelverzeichnis drin. Das heißt Tee... .
Ab D2005 sollte man es vermeiden bei Componenten eine Pfad zur Source einer anderen Componente anzugeben.

Da handelt man sich früher oder später Ärger ein. Der Compiler braucht eigentlich nur die BPL und die DCL.

Tritt der Fehler auf xxx konnte nicht geladen werden, enthält Modul yyy welches auch in zzz verwendet wird,
hat man ohne Source schlechte Karten.
Hier hilft nur das betroffene Modul aus allen bpl herauszunehmen, in einem eigenen Modul unterzubringen und
dieses unter reqiered in allen anderen Modulen aufzuführen.
TMS-Software (ADV Grid) ist so ein Kandidat. Sobald man von dieser Firma mehr als eine Komponente einsetzt geht keine
Installation oder Update mehr ohne nervige Nacharbeit im Quelltext.
Das Componentenmodell und das BPL Prinzip sind halt über 10 Jahre alt. In Net werden hier wesentlich modernere
Ansätze realisiert.
Der Abstand ist zwischenzeitlich so groß, das bei uns Delphi für Neuentwicklungen nicht mehr eingesetzt wird.


Gruß Peter

[EccoBravo]

Hallo Peter,

Danke, aber die Fragerei geht weiter:

Wo finde ich in CodeGear den KomponentenCache?
Habe schon alles durchgesucht, auch die Hilfe und nichts gefunden.

Danke

E. B.

[mkinzler]

HKLM\Software\Borland\BDS\5.0\Known Packages

[hanspeter]

Zitat:

Zitat von EccoBravo

Hallo Peter,

Danke, aber die Fragerei geht weiter:

Wo finde ich in CodeGear den KomponentenCache?
Habe schon alles durchgesucht, auch die Hilfe und nichts gefunden.

Danke

E. B.

In der Registry ist ein Schlüssel Codegear\ Componentencache, da findet man alle installierten Componenten.
Wie der Schlüssel genau heist, kann ich erst heute abend nachsehen, da in der Firma nur Delphi 7 genutzt wird.

Gruß
Peter

[EccoBravo]

Danke Peter und mkinzer,

eine Formulierung aber verstehe ich noch nicht richtig:

Zitat:

Tritt der Fehler auf xxx konnte nicht geladen werden, enthält Modul yyy welches auch in zzz verwendet wird,
hat man ohne Source schlechte Karten.

gewöhnlich versuche ich Abhängigkeiten zwischen meinen eigenen Komponenten zu vermeiden. d.h. ich leite meine Komponenten nur von den Standardkomponenten von Delphi ab, wie von TEdit, TPaintBox und Co.

War das gemeint?

Was aber, wenn erwerbbare Komponenten Abhängigkeiten voneinander haben, was mache ich dann und wie erfahre ich denn das?
Habe eben folgende Formulierung nicht richtig verstanden:

Zitat:

Hier hilft nur das betroffene Modul aus allen bpl herauszunehmen, in einem eigenen Modul unterzubringen und
dieses unter reqiered in allen anderen Modulen aufzuführen.

Grüße und Dank

E. B.

[hanspeter]

Zitat:

Zitat von EccoBravo

Danke Peter und mkinzer,

eine Formulierung aber verstehe ich noch nicht richtig:
E. B.

praktisches Beispiel. Ich kaufe die kommerzielle Komponente TADVGRID (Gridpack). Diese enthält u.a. die Unit "ADVstyleif".
Die Installation ist kein Problem.
Jetzt kaufe ich noch die kommerzielle Komponente ADVOfficetab vom gleichen Hersteller.
Diese Komponente enthält ebenfalls die Unit "ADVStyleif".
Der Effekt die zweite Komponente läßt sich nicht installieren und bricht mit der Fehlermeldung ab
ADVOfficeTab kann nicht geladen werden. Die Komponente enthält ADVStyleif, die auch in ADVGrid verwendet wird.
Der Workaround ADVStyleif aus den beiden Projekten entfernen und in einer eigenen BPL z.B. ADVCommon unterbringen.
Jetzt diese neue BPL als requiered in beiden Projekten angeben.
Das ganze bei jeder weiteren Komponente dieses Herstellers und bei jedem Update einer Komponente dieses Herstellers
wiederholen.

Gruß
Peter

[EccoBravo]

Danke Peter,
Prima, jetzt habe ich es begriffen.
Ich freue mich auf die Zusendung/das Posting der RegEdit-Arbeitsanweisung heute Abend.

ProvinzGrüße

E. B.

[EccoBravo]

Hallo Peter,

Deine folgende Formulierung habe ich auch nicht ganz verstanden:

Zitat:

Ab D2005 sollte man es vermeiden bei Componenten eine Pfad zur Source einer anderen Componente anzugeben

Ich habe ein eigenes Verzeichnis EB_RAD, in dem stehen alle selbst entwickelten Komponenten und ihr Code sowie alle eigenen dpk´s und bpl´s drin. Diesen habe ich auch in den Bibliotheks und Suchpfad angegeben.

Bei den käuflichen Komponenten und Packages habe ich für jedes Package ein eigenes Verzeichnis erstellt und darin deren Codes und Compilate geschrieben. Diese sind dann im Bibliothekspad und Suchpfad von mir eingetragen worden.
Richtig oder falsch...?

oder gibt es eine Regel, daß man alle kompilierten bpl´s und dcu´s in einen entsprechenden extra dafür vorgesehenen bpl und dcu-Pfad schreiben soll.
...

In dieser Frage bin ich schlecht organisiert und will einfach einen Sicheren Weg kennenlernen.
Bin schlichtweg ein erimitischer Autodidakt aus der Province.

Dann freue ich mich auf die versprochene Anweisung zum Aufräumen der Regedit


Danke und Grüße

E. B.

[hanspeter]

HKEY_CURRENT_USER\Software\Borland\BDS\5.0\Package Cache

Hier einen Schlüssel Tee... löschen

Gruß Peter

[EccoBravo]

Peter, vielen Dank,

habe dann alles gestern so gemacht wie besprochen,
nur
RAD frechte dann immer nach tee7100.bpl.
Na gut, dann habe ich ihm eben tee7100 aus dem Papierkorb wieder in WINDOWS/System32 zurückgegeben.

Nach dem Anpassen der Suchpfade und dem 2. Starten von RAD und beim Versuch, TChart oder FastReport4 zu verwenden, gab es dann die von Euch schom prognostizierte Fehlermeldung:

tee7100.bpl konnte nicht geladen werden, da es TeeAbout enthält, TeeAbout wird schon von Tee811 verwendet.

Natütlich habe ich von Tee und FastReport4 keinen Code, sodass ich die empfohlene Opreation nicht durchführen kann.

Bleibt mit nur die sinnvolle Frage:
Wozu braucht denn TeeChart das Package Tee7100.bpl (das gehört doch sicherlich zu einer Vorgängerversion)?


Danke, Grüße...

E. B.

PS.: Bitte beachtet auch meine vorletzte Frage in diesem Thread

[EccoBravo]

Hallo allerseits,

ich lasse nicht vorher los, bevor ich es mit Euch gelöst habe.

Bei mir hat sich etwas getan. Als ich irgend wo etwas vom Recompile gefunden habe habe ich nach Suchen dieses auch mit einer TrialVersion von FastReport4 machen können. Es gibt im Programmverzeichnis von FastReport4 tatsächlich eine recompile.exe, hätte ich nicht gedacht. Einfach draufgedrüggt und Eingaben gemacht und dann gab es nicht mehr die vielen Fehlermeldungen mit Tee7100, Tee811 und TeeAbout.

Aber:
Nachdem ich aber die richtigen Verzeichnisse, so glaube ich, für FrxClass.dcu und FrxChart.dcu in den Suchpfad von RAD eingegeben habe, kennt RAD aber die Komponenten FrxChart, FrxClass... im Code nicht.
Beim Versuch zu compilieren gibt es die Fehlermeldung 1026

[DCC Fehler] Project1.dpr(5): F1026 Datei nicht gefunden: 'frxChart.dcu'

Kennt jemand diesen Fehler?

Vielleicht kommen wir jetzt der Lösung meines Problems mit der Dreiecksgeschichte RAD2007, TeeChart8, FastReport4 etwas näher.

Danke und viele Grüße zum Wochenende E. B.

[grenzgaenger]

das problem kommt mir bekannt vor. hast du zufällig in einer componente die tChart anbindung aktiv? z. b. recompile freereport mit tchart, oder etwas anderes? dann erst mal zurückinstallieren ohne tChart anbindung. deine component libary muss sauber sein.

dann kannst du problemlos dein tChart installieren....

und später auch wieder die anbindung einfügen...

<HTH>

[EccoBravo]

Hallo,

ich glaub ich habs (bis das nächste Problem kommt)
Mein Fehler war, daß ich das Verzeichnis mit den FastReports

C:\Programme\CodeGear\RAD Studio\5.0\FastReport4\LibD11

nicht im Bibliothekspfad sondern im Suchpfad hatte.

Ich dachte, daß beide Pfadtypen gleichberechtigt wären (deshalb auch meine vorletzte Frage in diesem Thread).

Ich habe den Besagten Pfad in den Bibliothekspfad genommen und aus dem Suchpfad gelöscht und dann gings.
Es gibt zwar noch eine Fehlermeldung

"Fehler beim Lesen von Chart1 -> ShowHint:Eigenschaft
ShowHint existiert nicht,, Den Fehler ignorieren und
fortsetzen? HINWEIS: Durch Ignorieren des Fehlers
könnten Komponenten gelöscht werden oder
Eigenschaftswerte verloren gehen."

aber sonst funzen erst mal meine Programme

Nochmals Vieln Dank für Eure Bemühungen, Hilfestellungen und Geduld.

Einen schönen sturmfreien Sonntag und Grüße aus der German-Province

E. B.