Startverz�gerung

"A. Zaffran" schrieb:

Der "read only" mode wäre eine sinnvolle Anwendung für Arbeitsplätze,

die Eagle nur als Viewer benutzen - dann können die Anwender nicht

versehentlich etwas verändern.

 

Warum dann den Anwendern die Eagle nur als Viewer benutzen auch

nur das Lese-Recht auf die Ordner vergeben?

sicher gibt es noch mehr Gründe, aber zwei fallen mir sofort ein:

- weil die dann in dem Verzeichnis gar nichts mehr ändern können

- weil es viel aufwendiger zu verwalten ist

Grüße

Oliver Betz

Oliver Betz schrieb:

Matthias Weingart schrieb:

Der "read only" mode wäre eine sinnvolle Anwendung für Arbeitsplätze,

die Eagle nur als Viewer benutzen - dann können die Anwender nicht

versehentlich etwas verändern.

Warum dann den Anwendern die Eagle nur als Viewer benutzen auch

nur das Lese-Recht auf die Ordner vergeben?

--

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

Matthias Weingart schrieb:

Also, mit ein paar Workarounds (ist man ja gewöhnt) kann man das schon

ganz komfortabel gestalten, oder?

 

Danke für den Tipp. So sieht das dann schon viel besser aus.

gerne. Und Cadsoft setzt doch nach und nach viele Vorschläge um, die

die Arbeit weiter erleichtern. Leider gibt's dann auch wieder

Rückschläge (keine beliebigen epf-Namen seit 4., seit 4.9

verschwindet Highlighting und werden Wires über Pads unsichtbar...).

Da fällt mir noch ein Vorschlag für eine Kommandozeilenoption ein:

"open file in read only mode" - soll auch die epf unangetastet lassen.

 

Setzt doch das Read-Only-Flag des EPF-Files bevor Du Eagle 5 aufmachst und

nimm es wieder weg, wenn es zugemacht wird (in der Batchdatei).

Die Idee hatte ich auch schon, aber es ist klapprig und häßlich. Z.B.

muß die Batchdatei auf Eagle warten => zusätzlicher Eintrag in der

Taskleiste. Es ist auch nicht die gleiche Funktionalität, weil in der

Zeit auch eine andere Instanz von Eagle die Datei(en) nicht schreiben

kann (z.B. über's Netzwerk). Und man müßte letztlich die epf parsen,

um die Dateinamen von brd/sch und ggf. lbr zu erhalten.

Der "read only" mode wäre eine sinnvolle Anwendung für Arbeitsplätze,

die Eagle nur als Viewer benutzen - dann können die Anwender nicht

versehentlich etwas verändern.

Servus

Oliver

Oliver Betz <obetz@despammed.com>:

Also, mit ein paar Workarounds (ist man ja gewöhnt) kann man das schon

ganz komfortabel gestalten, oder?

Danke für den Tipp. So sieht das dann schon viel besser aus.

Da fällt mir noch ein Vorschlag für eine Kommandozeilenoption ein:

"open file in read only mode" - soll auch die epf unangetastet lassen.

Setzt doch das Read-Only-Flag des EPF-Files bevor Du Eagle 5 aufmachst und

nimm es wieder weg, wenn es zugemacht wird (in der Batchdatei).

M.

Matthias Weingart schrieb:

Ich meinte es anders. Eigentlich hat man alle Dateien eines Projektes gern

unter einem Verzeichnis. Dazu gehören dann nicht nur die Eagledateien,

sondern auch Datenblätterpdf's, Quellcode, Dokumentationen, Fotos, usw. usf.

genau.

Der Eaglekram macht dann grad mal so 2% aus. Nun stelle man sich vor, dass

man etliche solcher Komplettprojekte unter einem Pfad "projekte" verwaltet

und in Eagle diesen Hauptpfad als Projektpfad konfiguriert. Eagles Verhalten,

ja, das ist das, worüber sich einige Benutzer beschweren, das mich

aber nicht betrifft, weil ich eben nicht ein bestimmtes Verzeichnis

als "Wurzel aller Eagle-Projekte" definiere, sondern ".".

Dann rufe ich Eagle aus dem die epf enthaltenden Verzeichnis heraus

auf und habe keinerlei Problem mit Startzeiten und unübersichtlichem

Projektbaum.

Außerdem verwende ich eine cmd-Datei, um die zum EPF passende Version

von Eagle zu starten:

- schnipp -

@echo off

find "Version=""03 5" %1 >nul

if NOT errorlevel 1 (

     start X:\pfadzuEagle3\eagle.exe %1

     exit /b

)

find "Version=""04 1" %1 >nul

if NOT errorlevel 1 (

     start X:\pfadzuEagle4\eagle.exe %1

     exit /b

)

find "Version=""05 0" %1 >nul

if NOT errorlevel 1 (

        start X:\pfadzuEagle5\eagle.exe %1

     exit /b

)

echo Unknown epf version

pause

- schnipp -

Diese Batchdatei ist im Kontextmenü mit *.epf verknüpft.

Also, mit ein paar Workarounds (ist man ja gewöhnt) kann man das schon

ganz komfortabel gestalten, oder?

Seit "kurz vor Version 5" ist Eagle aber so nett, alte EPFs nicht ohne

Rückfrage zu verstümmeln, so daß ich mir noch einen weiteren Eintrag

für's Kontextmenü überlege: "Öffne mit Eagle 5". Denn in V5 ist die

Benutzung effizienter, zum "nur Anschauen" möchte ich das auch für

alte Projekte nutzen können. Die Sicherheitsabfrage am Ende muß man

natürlich passend beantworten...

Da fällt mir noch ein Vorschlag für eine Kommandozeilenoption ein:

"open file in read only mode" - soll auch die epf unangetastet lassen.

Servus

Oliver

Oliver Betz <obetz@despammed.com>:

Dateien durchsucht? (nur diesmal noch versch„rfter?). Vermutlich ist es

wirklich besser, alle Eagle-Projekte in einem eigenen Pfad abzulegen und

nicht unter dem Pfad des Projektes und in dem Pfad nix ausser den Eagle-

Dateien zu lassen. Fr die zum Projekt geh”rende Software mach ich das

 

Ob ich das richtig verstanden habe? Also ich lege ein Verzeichnis fr

ein Projekt an. Darin liegen dann projektspezifischen Eagle-Dateien.

Bei Projekten, die unter Versionsverwaltung stehen, ist das

Verzeichnis eine "working copy".

Ich meinte es anders. Eigentlich hat man alle Dateien eines Projektes gern

unter einem Verzeichnis. Dazu gehören dann nicht nur die Eagledateien,

sondern auch Datenblätterpdf's, Quellcode, Dokumentationen, Fotos, usw. usf.

Der Eaglekram macht dann grad mal so 2% aus. Nun stelle man sich vor, dass

man etliche solcher Komplettprojekte unter einem Pfad "projekte" verwaltet

und in Eagle diesen Hauptpfad als Projektpfad konfiguriert. Eagles Verhalten,

den gesamten Verzeichnisbaum komplett einzulesen, kann dann selbst auf

schnellen Rechnern schon ziemlich nervig werden. Naja es hat auch Vorteile.

Es führt auch dazu, den Projektpfad ab und an mal von alten Projekten zu

säubern :).

M.

Klaus Schmidinger schrieb:

Wenn in EAGLE ein Projekt geöffnet ist, dann ist das Standard-Verzeichnis

das Projektverzeichnis. Ist kein Projekt offen, dann ist es das

aktuelle Verzeichnis ("current directory").

danke für die Information.

Und wenn ich das richtig verstehe, ist "kein Projekt offen" erst seit

dem neuen Schalter -C überhaupt erzwingbar.

Leider gibt es aber wohl noch einige Ungereimtheiten, was die Erzeugung

von Ausgabedateien betrifft. So erzeugt z.B.

 

  export image x.png;

 

die Datei "x.png" im Standard-Verzeichnis, auch wenn z.B. die Board-Datei

in einem völlig anderen Verzeichnis liegt, während

 

  print file x.pdf;

 

die Datei in dem Verzeichnis erzeugt, in dem die Board-Datei liegt.

Es kann wohl bloß eine von beiden Varianten richtig sein. Bevor wir

jetzt aber die falsche wählen, mal die Frage an die Runde hier: welche

soll's denn sein?

Impulsiv aus dem Bauch heraus: das "aktuelle" Verzeichnis sollte den

Vorzug erhalten. Mir fällt gerade kein Programm ein, das sich anders

verhält.

Man kann ja auch immer absolute Pfade verwenden.

Mit den erwähnten Platzhaltern ($epfdir $brddir...) könnte man jedes

gewünschte Verhalten erzielen. Aber will man Platzhalter auch in

Kommandozeilen auflösen?

Grüße,

Oliver Betz

On 07/22/08 12:55, Oliver Betz wrote:

Klaus Schmidinger schrieb:

 

 

Interessant: Übergebe ich mit der Sendto-Methode eine epf-Datei,

stellt der Fileselect-Dialog nach "edit" in brd und sch das

Verzeichnis der epf-Datei ein. Übergebe ich ein brd oder sch, bietet

er mein USERPROFILE-Verzeichnis an. Das ist für mich etwas unerwartet.

 

Die Voreinstellung der Suchpfade sollte irgendwo umfassend

dokumentiert sein.

Das ist wohl eher etwas, das von Windows so herkommt...

 

als Anwender würde ich halt gerne wissen, unter welchen Umständen

Eagle welche Pfade woher nimmt.

 

Der o.g. Unterschied rührt sicher von Eagle her, Windows wird sich

kaum darum kümmern,wie der übergebene Parameter lautet.

Sorry, da hatte ich wohl was durcheinandergebracht. Ich war der

Meinung, daß sich da "Send to" und "Doppelklick" vielleicht

unterschiedlich verhalten.

Wenn in EAGLE ein Projekt geöffnet ist, dann ist das Standard-Verzeichnis

das Projektverzeichnis. Ist kein Projekt offen, dann ist es das

aktuelle Verzeichnis ("current directory").

Leider gibt es aber wohl noch einige Ungereimtheiten, was die Erzeugung

von Ausgabedateien betrifft. So erzeugt z.B.

   export image x.png;

die Datei "x.png" im Standard-Verzeichnis, auch wenn z.B. die Board-Datei

in einem völlig anderen Verzeichnis liegt, während

   print file x.pdf;

die Datei in dem Verzeichnis erzeugt, in dem die Board-Datei liegt.

Es kann wohl bloß eine von beiden Varianten richtig sein. Bevor wir

jetzt aber die falsche wählen, mal die Frage an die Runde hier: welche

soll's denn sein?

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Hofmark 2                               Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

Klaus Schmidinger schrieb:

Interessant: Übergebe ich mit der Sendto-Methode eine epf-Datei,

stellt der Fileselect-Dialog nach "edit" in brd und sch das

Verzeichnis der epf-Datei ein. Übergebe ich ein brd oder sch, bietet

er mein USERPROFILE-Verzeichnis an. Das ist für mich etwas unerwartet.

 

Die Voreinstellung der Suchpfade sollte irgendwo umfassend

dokumentiert sein.

 

Das ist wohl eher etwas, das von Windows so herkommt...

als Anwender würde ich halt gerne wissen, unter welchen Umständen

Eagle welche Pfade woher nimmt.

Der o.g. Unterschied rührt sicher von Eagle her, Windows wird sich

kaum darum kümmern,wie der übergebene Parameter lautet.

Grüße,

Oliver Betz

On 07/22/08 09:24, Oliver Betz wrote:

Klaus Schmidinger schrieb:

 

Außerdem habe ich die verschiedenen Eagle-Versionen noch im

Sendto-Ordner verlinkt. Dann kann ich auch .brd oder .sch explizit mit

der gewünschtne Version öffnen. Kleiner Schönheitsfehler dabei ist,

daß Eagle dann eine nicht zugehörige epf-Datei öffnet...

Wenn Sie bei der Verknüpfung die Option

 

  -C";"

 

angeben (seit Version 5.0), dann wird keine Projektdatei eingelesen.

Allerdings wird dann auch nicht die eaglerc-Datei zurückgeschrieben beim

Beenden.

 

-C war mir schon aufgefallen (bietet noch mehr interessante

Möglichkeiten), aber ich hatte es bisher noch nicht versucht.

 

In der Beschreibung der Option ist nicht erwähnt, daß ich bei -C auch

eine epf-Datei als Parameter übergeben kann - "Board, Schaltplan oder

Library" wird als Voraussetzung genannt. Es scheint aber trotzdem zu

funktionieren - vielleicht können Sie die Doku diesbezüglich klarer

formulieren?

Sicher kann auch eine eagle.epf-Datei angegeben werden. Es wird dann

dieses Projekt geladen, aber es ist nicht sicher, ob dann ein Board-,

Schematic- oder Library-Fenster den Focus hat, so daß die mit -C übergebenen

Befehle u.U. nicht in dem Fenster landen, für das sie gedacht sind.

Es ist daher besser, explizit die Datei anzugeben, die geladen werden soll.

Ferner müßte ich wohl "scr eagle.scr" als Kommando angeben, um das

Verhalten des "normalen" Aufrufes weiter anzunähern?

Wenn Sie wollen, daß es ausgeführt wird, dann ja.

Noch ein kleiner Schönheitsfehler: Bei Aufruf aus dem Sendto-Ordner

setzt Windows das aktuelle Verzeichnis nicht auf das Verzeichnis der

übergebenen Datei, wie das bei einer Verknüpfung über das Kontextmenü

der Fall ist. Hier müßte man wohl wieder eine Batchdatei vorschalten.

Wenn Windows diese Fälle unterschiedlich handhabt, ist wohl eine Batch-

Datei angebracht.

Interessant: Übergebe ich mit der Sendto-Methode eine epf-Datei,

stellt der Fileselect-Dialog nach "edit" in brd und sch das

Verzeichnis der epf-Datei ein. Übergebe ich ein brd oder sch, bietet

er mein USERPROFILE-Verzeichnis an. Das ist für mich etwas unerwartet.

 

Die Voreinstellung der Suchpfade sollte irgendwo umfassend

dokumentiert sein.

Das ist wohl eher etwas, das von Windows so herkommt...

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Hofmark 2                               Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________