element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      • Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Autodesk EAGLE
  • Products
  • More
Autodesk EAGLE
EAGLE Support (Deutsch) Re: Fenstergröße bei Start
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Autodesk EAGLE to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 49 replies
  • Subscribers 180 subscribers
  • Views 2532 views
  • Users 0 members are here
Related

Re: Fenstergröße bei Start

autodeskguest
autodeskguest over 17 years ago

Wolfgang Gerber schrieb:

 

Joern Paschedag schrieb: 

Ich

habe in meinen Projektverzeichnissen auch alle zugehörige Dokumentation

a la pdf und co und keine Probleme damit.

 

Sorry, das halte ich für den völlig falschen Ansatz - insbesondere in

einer Firma mit mehreren Mitarbeitern und vielen Projekten (die nicht

alle etwas mit EAGLE zu tun haben müssen).

 

... Die Schaltpläne

liegen eben in jeweils einem "Schaltplan"dir neben einem "Doku"dir,

"Bilder"dir, "Messungen"dir etc. Das alles unter einem "Auftrags"dir,

einem "Projektdir" etc. Ganz oben steht ein Serverlaufwerk. Eagle

liegt lokal.

 

Das ist die m.E. einzig sinnvolle Struktur bzw. Hierarchie zur

Projektverwaltung.

 

... Mir reicht die ganz normale Funktion mit

einem Klick auf ein ".sch" dir passende Zeichnung aufzumachen.

 

Nur stört mich das Eagle völlig unsinnigerweise dabei immer im

Minifenster startet. Das ist ein Programmfehler! Ohne wenn und aber.

 

Alle anderen mir bekannten IDEs (z.B. Delphi, Raisonance, diverse

Debugger, selbst projektfähige Editoren wie PSpad) arbeiten mit an

beliebiger Stelle gespeicherten "Projektdateien" und i.d.R. dazu

relativen Pfaden zu den im Projekt verwendeten Dateien.

 

Zum Öffnen des Projektes klickt man dann auch nicht auf eine der zu

bearbeitenden Dateien, sondern öffnet die Projektdatei - und ist damit

exakt an der Stelle (mit allen Fenstern, Größen und Einstellungen), an

der man das Projekt zuletzt verlassen hat.

 

Diese Projektdateien kann man dann zusammen mit den zugehörigen Daten

auch beliebig verschieben, z.B. um auf Basis eines vorhandenen Projektes

anderswo ein neues, ähnliches zu beginnen.

 

Nun verwendet EAGLE ja auch Projektdateien (eagle.epf) - nur dummerweise

heißen die für jedes Projekt immer gleich. image

 

Immerhin kann man sich die Datei eagle.epf zusammen mit dem .sch und

.brd an beliebige Stelle legen (also durchaus auch passend zur

firmenspezifischen Projekt-Struktur auf dem Server) und diese dann per

Doppelklick öffnen (nach Zuordnung von .epf zu EAGLE).

 

Die Pfade zu .sch und .brd sind im .epf relativ eingetragen, also werden

diese Fenster/Editoren sauber mit dem Projekt geöffnet. Einziger kleiner

Nachteil: Nach dem Öffnen einer eagle.epf ist das Control Panel im

Vordergrund, man muß also erst auf .sch bzw. .brd wechseln, je nachdem

was man bearbeiten möchte.

 

Und noch ein grundsätzlicher Punkt: die Datei muß wirklich eagle.epf

heißen, sonst kann EAGLE sie nicht öffnen. Daher kann man auch in einer

eigenen Hierarchie nur jeweils ein Projekt pro Verzeichnis ablegen.

 

Daher mein konkreter Verbesserungsvorschlag an CadSoft:

1. (wichtig) Erlauben Sie das Öffnen auch andersnamiger .epf Dateien;

2. (auch ziemlich wichtig) Stellen Sie nach dem direkten Öffnen einer

   .epf Datei das Fenster in den Vordergrund, das auch beim Beenden des

   Programms im Vordergrund stand (das dürfte wohl in der .epf stehen);

3. (nicht ganz so wichtig) Erlauben Sie das Abspeichern von Projekten

   mitsamt .epf Datei an beliebigem Ort.

4. (das wäre Luxus) Prüfen Sie beim Öffnen einer .sch oder .brd, ob im

   selben Verzeichnis eine gleichnamige .epf liegt und öffnen Sie dann

   diese, falls vorhanden.

 

(Mit "Öffnen" meine ich dabei jeweils das Öffnen per Doppelklick bzw.

Kontextmenü, programmtechnisch läuft das wohl als Parameter beim Aufruf

von EAGLE.)

 

Diese m.E. extrem kleinen Änderungen sollten wohl problemlos und auch

kurzfristig machbar sein (5.0.1?) und das grundsätzliche Problem der

Projektverwaltung nachhaltig lösen (für Experten), während sich für die

Nutzer der bisherigen Methode überhaupt nichts ändern würde.

 

Herr Schmidinger, können Sie das bitte kurz kommentieren? Danke.

 

Wegen des Verbesserungsvorschlags: Xpost und Fup2 eagle.suggest.ger

 

Tilmann

 

  • Sign in to reply
  • Cancel
Parents
  • autodeskguest
    autodeskguest over 17 years ago

    Hello Tilmann Reh !:

    ...

     

     

    Die Pfade zu .sch und .brd sind im .epf relativ eingetragen, also werden

    diese Fenster/Editoren sauber mit dem Projekt geöffnet.

     

    Stimmt .....

     

    Einziger kleiner

    Nachteil: Nach dem Öffnen einer eagle.epf ist das Control Panel im

    Vordergrund, man muß also erst auf .sch bzw. .brd wechseln, je nachdem

    was man bearbeiten möchte.

     

    Das ist das kleinste Problem - leider die Pfade zu den Libraries sind

    absolut eingetragen !!!!! Das ist leider total inkonsequent und bei

    einem Update auf hoehere Version fuehrt zu einem unbeabsichtigen

    Abspeichern der alten Libraries in falschem Verzeichniss.

     

    Dasselbe gillt fuer CAM-Jobs !!!!!

     

    Ich wuensche mir an dieser Stelle eine saubere konsequente Pfadeintraege

    .....

     

    Gruss

    --

    Grzegorz Zalot

     

    complex ltd.

    office tel/fax : +48 32 2505840

    mobil : +48 501 301515

     

    http://www.complex.org.pl/

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • autodeskguest
    autodeskguest over 17 years ago in reply to autodeskguest

    Grzegorz Zalot schrieb:

     

    Das ist das kleinste Problem - leider die Pfade zu den Libraries sind

    absolut eingetragen !!!!! Das ist leider total inkonsequent und bei

    einem Update auf hoehere Version fuehrt zu einem unbeabsichtigen

    Abspeichern der alten Libraries in falschem Verzeichniss.

     

    Das ist m.E. auch durchaus sinnvoll - und das Problem bei verschiedenen

    Versionen liegt an ganz anderer Stelle:

     

    Wenn die Projektdateien (.epf) nicht mehr in einem festgelegten Pfad

    liegen (was meine "Forderung" ist), /müssen/ die Bibliotheken absolut

    angegeben werden, sonst werden sie nicht mehr gefunden - oder man müßte

    sämtliche Libs in sämtliche Projektverzeichnisse kopieren...

     

    Der "Versionskonflikt" liegt darin begründet, daß die Einstellungen

    ebenfalls in einer Datei mit (versionsunabhängig) festgelegtem URI

    (eaglerc.usr) abgelegt werden. Das wäre an anderer Stelle sehr einfach

    lösbar (z.B. durch Angabe des URI für diese Datei in einer INI-Datei im

    bin-Verzeichnis, dann könnte man bei Bedarf mit verschiedenen

    eaglerc.usr Dateien arbeiten).

     

    Im Moment (und in diesem Thread) möchte ich mich aber auf die

    Projektverwaltung konzentrieren.

     

    Für das Speichern der globalen Einstellungen können wir ja einen eigenen

    Thread aufmachen.

     

    Tilmann

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • autodeskguest
    autodeskguest over 17 years ago in reply to autodeskguest

    Hello Tilmann Reh !:

     

    Das ist das kleinste Problem - leider die Pfade zu den Libraries sind

    absolut eingetragen !!!!! Das ist leider total inkonsequent und bei

    einem Update auf hoehere Version fuehrt zu einem unbeabsichtigen

    Abspeichern der alten Libraries in falschem Verzeichniss.

     

    Das ist m.E. auch durchaus sinnvoll -

     

    Da bin ich dagegen .....

     

    und das Problem bei verschiedenen

    Versionen liegt an ganz anderer Stelle:

     

    Wenn die Projektdateien (.epf) nicht mehr in einem festgelegten Pfad

    liegen (was meine "Forderung" ist), /müssen/ die Bibliotheken absolut

    angegeben werden, sonst werden sie nicht mehr gefunden - oder man müßte

    sämtliche Libs in sämtliche Projektverzeichnisse kopieren...

     

    Nein - es reicht, dass das Programm nach den Libs in dem

    Programm-Library-Verzeichniss sucht. Das ist doch explizit definiert,

    oder ????

     

    Man soll bedenken, ganze Projekte sollen ainfach von einer zu anderen

    Version vrschiebbar sein. Und ... jetzt entsteht ganz schoener Mist image

    ! Ich glaube, keiner in Pleiskirchen parallell 4.x und 5.x betrieben hat

    .... Schade ...

     

     

    Der "Versionskonflikt" liegt darin begründet, daß die Einstellungen

    ebenfalls in einer Datei mit (versionsunabhängig) festgelegtem URI

    (eaglerc.usr) abgelegt werden.

     

    Stimmt. MMN das ist eindeutig ein Fehler !!!! Und recht einfach zu

    beheben indem diese Gatei einfach die Versionsnummer beeinhaelt.....

     

    Das wäre an anderer Stelle sehr einfach

    lösbar (z.B. durch Angabe des URI für diese Datei in einer INI-Datei im

    bin-Verzeichnis, dann könnte man bei Bedarf mit verschiedenen

    eaglerc.usr Dateien arbeiten).

     

    Auch ....

     

     

    Im Moment (und in diesem Thread) möchte ich mich aber auf die

    Projektverwaltung konzentrieren.

     

    Na ja ..... zuerst sollte man auf jeden Fall die Dateimuell aus dem

    Browser entfernen, sonst kann man gar nicht von der Verwaltung im

    Control Panel sprechen

     

    BTW, derzeitige Projektstruktur waere fuer moch gar nicht sooo schlecht,

      mit einer Ausnahme : alle Dateien sollen einfach kopierbar sein,

    ohte achten auf andere Verzeichnisse usw. Also leider auch Libraries ...

    und das ist schon ein Problem. Ehrlich gesagt, die Datenstruktur in 4.x

    und 5.x ist eigentlich schwer fuer Datenaustausch geeignet image ....

     

    Ich habe einige Ideen, allerdings alle nicht einfach sind und alle

    benoetigen grosse Dateistrukturaenderung. Und jetzt ist nicht die

    richtige Zeit um das zu diskutieren. Es sind viele Sachen, die

    wesentlich wichtiger sind !

     

     

    Für das Speichern der globalen Einstellungen können wir ja einen eigenen

    Thread aufmachen.

     

    Koennen wir ... und ?????

     

    Ich glaube in diesem Fall CadSoft verhaellt sich shcon extrem

    rueckhaltend image !

     

    Gruss

    --

    Grzegorz Zalot

     

    complex ltd.

    office tel/fax : +48 32 2505840

    mobil : +48 501 301515

     

    http://www.complex.org.pl/

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Reply
  • autodeskguest
    autodeskguest over 17 years ago in reply to autodeskguest

    Hello Tilmann Reh !:

     

    Das ist das kleinste Problem - leider die Pfade zu den Libraries sind

    absolut eingetragen !!!!! Das ist leider total inkonsequent und bei

    einem Update auf hoehere Version fuehrt zu einem unbeabsichtigen

    Abspeichern der alten Libraries in falschem Verzeichniss.

     

    Das ist m.E. auch durchaus sinnvoll -

     

    Da bin ich dagegen .....

     

    und das Problem bei verschiedenen

    Versionen liegt an ganz anderer Stelle:

     

    Wenn die Projektdateien (.epf) nicht mehr in einem festgelegten Pfad

    liegen (was meine "Forderung" ist), /müssen/ die Bibliotheken absolut

    angegeben werden, sonst werden sie nicht mehr gefunden - oder man müßte

    sämtliche Libs in sämtliche Projektverzeichnisse kopieren...

     

    Nein - es reicht, dass das Programm nach den Libs in dem

    Programm-Library-Verzeichniss sucht. Das ist doch explizit definiert,

    oder ????

     

    Man soll bedenken, ganze Projekte sollen ainfach von einer zu anderen

    Version vrschiebbar sein. Und ... jetzt entsteht ganz schoener Mist image

    ! Ich glaube, keiner in Pleiskirchen parallell 4.x und 5.x betrieben hat

    .... Schade ...

     

     

    Der "Versionskonflikt" liegt darin begründet, daß die Einstellungen

    ebenfalls in einer Datei mit (versionsunabhängig) festgelegtem URI

    (eaglerc.usr) abgelegt werden.

     

    Stimmt. MMN das ist eindeutig ein Fehler !!!! Und recht einfach zu

    beheben indem diese Gatei einfach die Versionsnummer beeinhaelt.....

     

    Das wäre an anderer Stelle sehr einfach

    lösbar (z.B. durch Angabe des URI für diese Datei in einer INI-Datei im

    bin-Verzeichnis, dann könnte man bei Bedarf mit verschiedenen

    eaglerc.usr Dateien arbeiten).

     

    Auch ....

     

     

    Im Moment (und in diesem Thread) möchte ich mich aber auf die

    Projektverwaltung konzentrieren.

     

    Na ja ..... zuerst sollte man auf jeden Fall die Dateimuell aus dem

    Browser entfernen, sonst kann man gar nicht von der Verwaltung im

    Control Panel sprechen

     

    BTW, derzeitige Projektstruktur waere fuer moch gar nicht sooo schlecht,

      mit einer Ausnahme : alle Dateien sollen einfach kopierbar sein,

    ohte achten auf andere Verzeichnisse usw. Also leider auch Libraries ...

    und das ist schon ein Problem. Ehrlich gesagt, die Datenstruktur in 4.x

    und 5.x ist eigentlich schwer fuer Datenaustausch geeignet image ....

     

    Ich habe einige Ideen, allerdings alle nicht einfach sind und alle

    benoetigen grosse Dateistrukturaenderung. Und jetzt ist nicht die

    richtige Zeit um das zu diskutieren. Es sind viele Sachen, die

    wesentlich wichtiger sind !

     

     

    Für das Speichern der globalen Einstellungen können wir ja einen eigenen

    Thread aufmachen.

     

    Koennen wir ... und ?????

     

    Ich glaube in diesem Fall CadSoft verhaellt sich shcon extrem

    rueckhaltend image !

     

    Gruss

    --

    Grzegorz Zalot

     

    complex ltd.

    office tel/fax : +48 32 2505840

    mobil : +48 501 301515

     

    http://www.complex.org.pl/

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Children
  • Former Member
    Former Member over 17 years ago in reply to autodeskguest

    Grzegorz Zalot schrieb:

    Hello Tilmann Reh !:

    Nein - es reicht, dass das Programm nach den Libs in dem

    Programm-Library-Verzeichniss sucht. Das ist doch explizit definiert,

    oder ????

     

    Man soll bedenken, ganze Projekte sollen ainfach von einer zu anderen

    Version vrschiebbar sein. Und ... jetzt entsteht ganz schoener Mist image

    ! Ich glaube, keiner in Pleiskirchen parallell 4.x und 5.x betrieben hat

    .... Schade ...

     

    Doch, von 3.5 bis 5.0, und damit sich die eaglerc.usr nicht in die Quere

    kommen starte ich die alten Eagle-Versionen mit einem Batch.

     

    SET HOME=EG35

    ...\eagle.exe %1

     

    bzw.

    SET HOME=EG40

    ...\eagle.exe %1

     

    bzw.

    SET HOME=EG41

    ...\eagle.exe %1

     

    Im System ist die Umgebungsvariable HOME definiert und auf eg50

    gesetzt, damit diese Version auch seinen eignen Home-Ordner besitzt.

     

    Damit holt sich jede Eagle-Version die entsprechende eaglerc.usr

    in der wiederum der Pfad zur letzen eagle.epf steht und in der

    eagle.epf stehen dann ja die Pfade zu den LBRs, ULPs, CAMs, SCRs

    und zum Projekt als 'relativer Pfad' oder 'absolut'. Je nach dem

    wie man das haben möchte. Und der Pfad zu SCH/BRD steht absolut

    drin. Dadurch muß SCH/BRD nicht zwingend im selben Ordner abgelegt

    sein wie das eagle.epf selbst. image

     

    Leider kann der Explorer nicht mehrere .exe mit einer Extension

    verwalten, aber es gibt dazu den Ordner "SendTo" bzw. ab XP

    auch "Öffnen mit".

     

     

    --

    MfG / Best regards

      A. Zaffran

     

    Hotline 08635-698930, FAX 08635-698940, eMail <alf@cadsoft.de>

    CadSoft Computer GmbH, Hofmark 2, 84568 Pleiskirchen

    Registergericht: Amtsgericht  Traunstein HRB 5573

    Geschäftsführer: Dipl.-Ing. (FH) Rudolf Hofer, Dipl.-Ing. Klaus Schmidinger

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • autodeskguest
    autodeskguest over 17 years ago in reply to Former Member

    Hallo!

     

    A. Zaffran schrieb:

    > Doch, von 3.5 bis 5.0, und damit sich die eaglerc.usr nicht in die

    > Quere kommen starte ich die alten Eagle-Versionen mit einem Batch.

     

    Batch löst das Problem in keinster Weise. Meine eigenen Libraries und

    Projekt-Daten liegen sowieso nicht unterhalb von $EAGLEDIR, da dieser

    Ordner für mich read-only ist. Ich denke, das gilt für die meisten hier.

     

    eagle.epf stehen dann ja die Pfade zu den LBRs, ULPs, CAMs, SCRs

    und zum Projekt als 'relativer Pfad' oder 'absolut'. Je nach dem

    wie man das haben möchte.

     

    Ich möchte das 'relativ' haben. Da meine EAGLE Versionen immer

    'absolut' speichern, erlauben Sie mir sicher die Frage: Wie kann ich das

    ändern?

     

    Und der Pfad zu SCH/BRD steht absolut

    drin. Dadurch muß SCH/BRD nicht zwingend im selben Ordner abgelegt

    sein wie das eagle.epf selbst. image

     

    Wenn die Pfade relativ gespeichert werden, muß SCH/BRD ebenfalls nicht

    zwingend im selben Ordner gespeichert werden.

     

    Leider kann der Explorer nicht mehrere .exe mit einer Extension

    verwalten, aber es gibt dazu den Ordner "SendTo" bzw. ab XP

    auch "Öffnen mit".

     

    Was hat das EAGLE Problem mit dem Explorer zu tun? Ich möchte weder

    "SendTo" noch "Öffnen mit", ich möchte in den Projekten relative Pfade

    sehen.

     

    Gruß,

    René

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 17 years ago in reply to autodeskguest

    René König schrieb:

    Hallo!

     

    A. Zaffran schrieb:

    > Doch, von 3.5 bis 5.0, und damit sich die eaglerc.usr nicht in die

    > Quere kommen starte ich die alten Eagle-Versionen mit einem Batch.

     

    Batch löst das Problem in keinster Weise. Meine eigenen Libraries und

     

    Es ging hier darum, daß man mehrere Eagle-Versionen zugleich betreibt.

    Und da es nur eine eaglerc.usr geben kann, so kann/muß man mit einem

    Batch den Home-Ordner in der Eagle die eaglerc.usr sucht entsprechend

    umdefinieren. image

     

     

    Projekt-Daten liegen sowieso nicht unterhalb von $EAGLEDIR, da dieser

    Ordner für mich read-only ist. Ich denke, das gilt für die meisten hier.

     

    Deshalb kann man ja einen absoluten Pfad angeben.

     

    eagle.epf stehen dann ja die Pfade zu den LBRs, ULPs, CAMs, SCRs

    und zum Projekt als 'relativer Pfad' oder 'absolut'. Je nach dem

    wie man das haben möchte.

     

    Ich möchte das 'relativ' haben. Da meine EAGLE Versionen immer

    'absolut' speichern, erlauben Sie mir sicher die Frage: Wie kann ich das

    ändern?

     

    Relativ beziert sich auf den Ordner in dem die eagle.exe liegt.

    $EAGLEDIR  Handbuch (4,1) Seite 31.

     

     

    Und der Pfad zu SCH/BRD steht absolut

    drin. Dadurch muß SCH/BRD nicht zwingend im selben Ordner abgelegt

    sein wie das eagle.epf selbst. image

     

    Wenn die Pfade relativ gespeichert werden, muß SCH/BRD ebenfalls nicht

    zwingend im selben Ordner gespeichert werden.

     

    Das habe ich doch geschrieben. Der Pfad zu SCH/BRD ist im .epf absolut

    abgelegt.

     

    Leider kann der Explorer nicht mehrere .exe mit einer Extension

    verwalten, aber es gibt dazu den Ordner "SendTo" bzw. ab XP

    auch "Öffnen mit".

     

    Was hat das EAGLE Problem mit dem Explorer zu tun? Ich möchte weder

     

    Es ging darum, das man mehrere Eagle-Versionen auf dem Rechnet hat

    und je nachdem welche .SCH .BRD man im Explorer anklickt soll die

    entspr. Eagle-Version gestartet werden.

    Der Explorer kann aber nun mal nur eine .exe mit der Extension

    verknüpfen.

     

    "SendTo" noch "Öffnen mit", ich möchte in den Projekten relative Pfade

    sehen.

     

    Zu jedem relativen Pfad braucht man einen absoluten Bezug (Startordner),

    und der ist bei $EAGLEDIR der Ordner unterhalb des Ordner in dem die

    eagle.exe abgelegt ist.

     

     

    --

    MfG / Best regards

      A. Zaffran

     

    Hotline 08635-698930, FAX 08635-698940, eMail <alf@cadsoft.de>

    CadSoft Computer GmbH, Hofmark 2, 84568 Pleiskirchen

    Registergericht: Amtsgericht  Traunstein HRB 5573

    Geschäftsführer: Dipl.-Ing. (FH) Rudolf Hofer, Dipl.-Ing. Klaus Schmidinger

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • autodeskguest
    autodeskguest over 17 years ago in reply to Former Member

    A. Zaffran schrieb:

    Es ging hier darum, daß man mehrere Eagle-Versionen zugleich betreibt.

    Und da es nur eine eaglerc.usr geben kann, so kann/muß man mit einem

    Batch den Home-Ordner in der Eagle die eaglerc.usr sucht entsprechend

    umdefinieren. image

     

    Bei der jetzigen Lösung ist es eben fast nicht wirklich möglich, mehrere

    Versionen parallel zu betreiben. Dabei ist es ganz egal, ob Sie nun

    Batch verwenden oder nicht. Das gilt jedenfalls für mich, da ich nur

    Version 4.16 und 5 parallel auf dem Rechner habe. Und da haben die

    beiden Versionen sowieso schon unterschiedliche Meinungen, was den

    HOME-Ordner betrifft.

     

    Projekt-Daten liegen sowieso nicht unterhalb von $EAGLEDIR, da dieser

    Ordner für mich read-only ist. Ich denke, das gilt für die meisten hier.

     

    Deshalb kann man ja einen absoluten Pfad angeben.

     

    Genau deshalb habe ich das auch gemacht.

     

    eagle.epf stehen dann ja die Pfade zu den LBRs, ULPs, CAMs, SCRs

    und zum Projekt als 'relativer Pfad' oder 'absolut'. Je nach dem

    wie man das haben möchte.

     

    Ich möchte das 'relativ' haben. Da meine EAGLE Versionen immer

    'absolut' speichern, erlauben Sie mir sicher die Frage: Wie kann ich

    das ändern?

     

    Relativ beziert sich auf den Ordner in dem die eagle.exe liegt.

    $EAGLEDIR  Handbuch (4,1) Seite 31.

     

    Im EPF werden die Pfade absolut gespeichert. Das ist das Problem. Mich

    interessiert dabei überhaupt nicht, wo eagle.exe liegt.

     

    Und der Pfad zu SCH/BRD steht absolut

    drin. Dadurch muß SCH/BRD nicht zwingend im selben Ordner abgelegt

    sein wie das eagle.epf selbst. image

     

    Wenn die Pfade relativ gespeichert werden, muß SCH/BRD ebenfalls nicht

    zwingend im selben Ordner gespeichert werden.

     

    Das habe ich doch geschrieben. Der Pfad zu SCH/BRD ist im .epf absolut

    abgelegt.

     

    Das habe ich doch geschrieben: Das ist das Problem.

     

    Es ging darum, das man mehrere Eagle-Versionen auf dem Rechnet hat

    und je nachdem welche .SCH .BRD man im Explorer anklickt soll die

    entspr. Eagle-Version gestartet werden.

     

    Ich glaube, wir sind hier alle in der Lage, die richtige Anwendung zu

    starten. Machen Sie sich da mal keine Sorgen. Das Problem ist, das es

    nicht vernünftig funktioniert, wenn die richtige Anwendung erst einmal

    gestartet ist. Das Problem ist, das im EPF die Pfade absolut stehen.

     

    Der Explorer kann aber nun mal nur eine .exe mit der Extension

    verknüpfen.

     

    Na und?

     

    Zu jedem relativen Pfad braucht man einen absoluten Bezug (Startordner),

     

    Das sollte/muss der Ordner sein, in dem sich eagle.epf befindet.

     

    und der ist bei $EAGLEDIR der Ordner unterhalb des Ordner in dem die

    eagle.exe abgelegt ist.

     

    Und noch nichtmal dieser Bezug wird verwendet, im EPF werden die Pfade

    absolut gespeichert werden. Das ist das Problem.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • autodeskguest
    autodeskguest over 17 years ago in reply to Former Member

    A. Zaffran schrieb:

     

    Es ging hier darum, daß man mehrere Eagle-Versionen zugleich betreibt.

     

    Nein, eigentlich ging es zunächst um etwas anderes.

     

    Ich würde mich freuen, zum Originalthema (und meinen konkreten und m.E.

    zielführenden Vorschlägen) einen Kommentar von Herrn Schmidinger zu lesen.

     

    Nur hierzu noch etwas:

     

    Relativ beziert sich auf den Ordner in dem die eagle.exe liegt.

    $EAGLEDIR  Handbuch (4,1) Seite 31.

    ...

    Das habe ich doch geschrieben. Der Pfad zu SCH/BRD ist im .epf absolut

    abgelegt.

     

    Ist er nicht. Dort steht nur der Dateiname, kein Pfad dorthin.

    "Und das ist auch gut so."

     

    Zu jedem relativen Pfad braucht man einen absoluten Bezug (Startordner),

    und der ist bei $EAGLEDIR der Ordner unterhalb des Ordner in dem die

    eagle.exe abgelegt ist.

     

    Genau an dieser Stelle liegt doch eines der Hauptprobleme: nach Ihrem

    Konzept hat jedes Projekt denselben Startordner - und genau das läuft

    einer sinnvollen (über die EAGLE-Dateien hinausgehenden)

    Projektverwaltung zuwider.

     

    Unter "relativ" versteht der Anwender nicht einen Bezug zum (fixen)

    Startverzeichnis von EAGLE, sondern einen Bezug zum (variablen) Pfad der

    jeweiligen Projektdatei - innerhalb einer Verzeichnisstruktur und

    -hierarchie, deren Aufbau dem Anwender überlassen/freigestellt bleibt.

     

    Tilmann

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • autodeskguest
    autodeskguest over 17 years ago in reply to Former Member

    Hello A. Zaffran !:

     

    an soll bedenken, ganze Projekte sollen ainfach von einer zu anderen

    Version vrschiebbar sein. Und ... jetzt entsteht ganz schoener Mist

    image ! Ich glaube, keiner in Pleiskirchen parallell 4.x und 5.x

    betrieben hat .... Schade ...

     

    Doch, von 3.5 bis 5.0, und damit sich die eaglerc.usr nicht in die Quere

    kommen starte ich die alten Eagle-Versionen mit einem Batch.

     

    SET HOME=EG35

    ...\eagle.exe %1

     

     

    Geht das etwa nicht ein bisschen professioneller ???????

     

    Ab und zu verwende ich Ersatzmethoden (man kann in Eagle.exe nach dem

    eaglerc string suchen :-P !!!) aber eigentlich so eine Kleinigkeit

    sollte langer her geloest werden.

     

    Oder moechten Sie ein kleines Buch "Tricks und Ersatzmethoden fuer

    Eagle" schreiben ???

     

    Schoene Gruesse

    --

    Grzegorz Zalot

     

    complex ltd.

    office tel/fax : +48 32 2505840

    mobil : +48 501 301515

     

    http://www.complex.org.pl/

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • autodeskguest
    autodeskguest over 17 years ago in reply to autodeskguest

    Tilmann Reh schrieb:

    Das habe ich doch geschrieben. Der Pfad zu SCH/BRD ist im .epf absolut

    abgelegt.

     

    Ist er nicht. Dort steht nur der Dateiname, kein Pfad dorthin.

    "Und das ist auch gut so."

     

    Aber nur solange, solange die Zeichnung im selben Ordner wie das EPF

    ist. Ist die Zeichnung z.B. in einem parallelen Ordner, wird sofort

    wieder absolut gespeichert. Das finde ich nicht so gut.

     

    Unter "relativ" versteht der Anwender nicht einen Bezug zum (fixen)

    Startverzeichnis von EAGLE, sondern einen Bezug zum (variablen) Pfad der

    jeweiligen Projektdatei - innerhalb einer Verzeichnisstruktur und

    -hierarchie, deren Aufbau dem Anwender überlassen/freigestellt bleibt.

     

    FULL ACK.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • autodeskguest
    autodeskguest over 17 years ago in reply to autodeskguest

    René König schrieb:

     

    Das habe ich doch geschrieben. Der Pfad zu SCH/BRD ist im .epf absolut

    abgelegt.

     

    Ist er nicht. Dort steht nur der Dateiname, kein Pfad dorthin.

    "Und das ist auch gut so."

     

    Aber nur solange, solange die Zeichnung im selben Ordner wie das EPF

    ist. Ist die Zeichnung z.B. in einem parallelen Ordner, wird sofort

    wieder absolut gespeichert. Das finde ich nicht so gut.

     

    In fast allen Fällen dürften die Dateien sowieso im selben Ordner wie

    die .epf Datei liegen. Wie schon erwähnt, handhaben das sehr viele

    integrierte Umgebungen so, und ich würde diese Dateien auch immer

    zusammen ablegen.

     

    "Weiter entfernte" Dateien relativ anzugeben, dürfte nicht ganz so

    einfach umzusetzen sein - mein Vorschlag zielte auf eine Detailänderung,

    die so winzig ist, daß sie kurzfristig kommen könnte, ohne für die

    Nutzer der bisherigen Methode etwas zu ändern.

     

    Wobei Pfade /unterhalb/ der .epf natürlich mühelos relativ angegeben

    werden könnten (auch aus Sicht der/des Programmierer/s).

     

    Tilmann

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • autodeskguest
    autodeskguest over 17 years ago in reply to autodeskguest

    Tilmann Reh schrieb:

    In fast allen Fällen dürften die Dateien sowieso im selben Ordner wie

     

    Nicht aber die Libraries.

     

    die .epf Datei liegen. Wie schon erwähnt, handhaben das sehr viele

    integrierte Umgebungen so, und ich würde diese Dateien auch immer

    zusammen ablegen.

     

    Meine Umgebungen handhaben die Pfade, wo möglich, relativ.

     

    "Weiter entfernte" Dateien relativ anzugeben, dürfte nicht ganz so

    einfach umzusetzen sein - mein Vorschlag zielte auf eine Detailänderung,

     

    So weit entfernt habe ich meine Dateien gar nicht liegen, finde ich.

     

    die so winzig ist, daß sie kurzfristig kommen könnte, ohne für die

    Nutzer der bisherigen Methode etwas zu ändern.

     

    Wobei Pfade /unterhalb/ der .epf natürlich mühelos relativ angegeben

    werden könnten (auch aus Sicht der/des Programmierer/s).

     

    Naja, unter Windows würde ich hier ganz einfach die Funktion

    PathRelativePathTo aufrufen. Das erschlägt Deinen und meinen/unseren

    Vorschlag gleichzeitig. Die QT wird da sicher etwas ähnliches anbieten.

     

    Schwierig handzuhaben sind relative Pfade also auf gar keinen Fall, egal

    ob der Ordner nun untergeordnet oder parallel ist. Man muss das nur

    wollen.  image

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • autodeskguest
    autodeskguest over 17 years ago in reply to autodeskguest

    René König schrieb:

     

    In fast allen Fällen dürften die Dateien sowieso im selben Ordner wie

    die .epf Datei liegen.

     

    Nicht aber die Libraries.

     

    Nein, und deswegen wäre es auch überhaupt nicht sinnvoll, den Pfad zu

    den Bibliotheken relativ zur Projektdatei anzugeben (schrieb ich schon

    vorher). Immerhin gibt es die Bibliotheken ja nur einmal für alle

    Projekte gemeinsam, und da ergibt ein fester Pfad durchaus Sinn (für

    verteiltes Arbeiten liegt der dann auf einem Netzlaufwerk, das von allen

    Arbeitsplätzen unter demselben Buchstaben bzw. Namen angesprochen wird).

     

    Es wäre völliger Krampf und extrem kontraproduktiv, die Pfade zu den

    Bibliotheken relativ anzugeben. Denk das einmal zu Ende... Da sind mir

    sogar die jetzigen absoluten Pfade zu Schaltung und Board noch lieber.

     

    Tilmann

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube