Jetzt gibts das Programm schon in der x-ten Version über Jahrzehnte und noch immer schaffens die nicht, die Bauteilebibliothek zu programmieren.
Jedesmal brauch ich 20 Minuten um das GROUND Symbol zu finden, und die 9 Volt battery.
Dann gehst in ADD Menü, tippst irgenwas, EAGLE findet irgendwas, und dann stehste da, und kannst nicht mehr zurück zur Bauteileliste. Es gibt keinen BACK Button und ich komm nicht raus, nur nach Programmneustart. Ich habe "Ground" einegeben, er findet was von Würth Elektronik, was überhaupt nichts damit zu tun hat, und das Fenster bleibt wie's ist. Zumachen und ADD aufrufen hilft nix, nur Neustart.
Das hat bei Eagle schon bei V4 nicht gescheit funktioniert. Gewoehnt man sich dran, aehnlich wie das Haemmerchen im frueheren Opel Kadett um ab und zu mal den Anlasser per Hieb zum Einruecken zu bewegen.
Hint: Spickzettel nehmen, oder wichtige Sachen in eigene Libs rueberholen (so mache ich das). Wenn es ganz schlimm kommt, Wutzettel abreissen, zerknuellen und in die Ecke schmeissen :-)
Prima, wieder was gelernt. Hatte bisher immer gedacht, das x wäre nur dafür da, um das Suchfeld optisch hervorzuheben, da es auch nicht wirklich wie was zum draufklicken aussieht. Vielleicht sollte ich doch mal das Handbuch lesen :-)
--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
Das liegt sicher nicht an CADSoft. Ich jedenfalls finde z.B. _alle_ vorhandenen GND-Symbole in weniger als einer Sekunde.
Tja, und wenn es offensichtlich nicht an CADSoft liegt, dann wird die Wahl für die Ursache deines Problems doch etwas eng, findest du nicht?
RTFM
Wie wär's denn mal mit "*gnd*" oder notfalls "g*d"? Jokerzeichen? Noch nie was von gehört oder gelesen? Steht ja auch bloß im Hilfetext wenige Zentimeter weiter. Aber wer liest denn sowas schon?
Wie wär's mit einem kleinen Klick auf das Symbol mit dem kleinen Kreuzchen links neben dem Textfeld? Selbst wenn User Dumm-DAU nur hilflos mit dem Mauszeiger rudert, müßte ihm irgendwann der Hint auffallen, der erscheint, wenn der Mauszeiger über den Button rutscht...
Der Teufel soll User holen, die sogar zu bescheuert sind, in eine Kloschüssel zu scheißen. Warum werden wir Programmierer nur immer wieder mit solchem Pack gestraft? Zum Glück bin ich nicht bei CADSoft, sonst hätte ich dich am Hals.
Verglichen mit dir sind meine User ja sogar noch hochintelligent. Zumindest auf "GND" als Suchbegriff wären die ganz sicher von ganz allein gekommen und das hätte immerhin schon ein Drittel der möglichen Treffer gebracht (und der Rest wäre in den Bibliotheken, die sie mit dem einfachen GND gefunden haben).
Und das Icon zum Reset der Eingabe hätten sie sicher auch irgendwann in den letzten zehn Jahren gefunden, und sei es durch hilfloses Rumgeklicke. Es gibt aber offensichtlich Leute, die sogar dazu noch zu blöd sind...
User haben das Privileg, blöd zu sein. Als User soll man nie in den Gedanken verfallen, was mach ich denn falsch, weil man den Fehler bei sich selber sucht und eine Panik kriegt. Programmierer sollten aber mit-und vorausdenken um genau solche Situationen zu verhindern.
Habe grad was aus Chinaland bekommen, hat mir nicht gepaßt und habe rumgemeckert weil etwas ungewöhnlich mir vorkam.
6 Emails haben sie mir geschrieben mit Entschuldigungen und ich möge doch dieses und jenes...aber keine Rede von blöd oder Handbuch lesen. Es steht schon drin, aber verklausuliert und ich hatte 1/2 Unrecht. Siehste, das ist der Chinese und ich kauf auch gerne dort.
Bei mir hat ca. jedes Board/Projekt eine eigene zugehörige Library für die dort verwendeten Bauteile. Teilweise schon deshalb weil das was von Eagle mitgeliefert wird guter Ausgangspunkt aber oft nicht direkt verwendbar ist. Z.B. weil ich für selbstgeätzte Leiterplatten grössere Lötaugen benötige.
Weil Ihr Eure Kunden als Eure Bestrafung anseht? Warum holt Ihr Euch für die Tests nicht Leute, die das Programm nicht kennen, aber sich einarbeiten und es dann wirklich nutzen müssen? Die sollten auch die Handbücher schreiben.
Das Musterbeispiel ist für mich immer noch Lotus-1-2-3. Das war so selbsterklärend, daß man das schöne dicke Handbuch garnicht brauchte.
Ich glaube nicht daß Lötauge das für durchkontaktierte Bohrung & maschinelle Lötung gedacht war für nichtdurchkontaktierte Bohrung & Handlötung ideal ist.
Der Unterschied ist allerdings bei DIL-ICs bei mir auch nicht nicht sonderlich groß, hauptsächlich weil da meist der Platz fehlt:
formatting link
Grosses Lötauge ist für Handlötung jedenfalls bequemer. Mehr Unterschied sind z.B. Schraubklemmleisten, Lötnägel die im Gebrauch mechanisch belastet werden. Da will man ohne Durchkontaktierung entsprechend hohen Durchmesser des Lötauges weil man die Haftfestigkeit des Kupfers benötigt daß das Lötauge dann nicht abreisst.
... aber sie sollten sich gut ueberlegen, ob sie alleine deswegen gleich alle Mitarbeiter einer Firma in die Hoelle stecken wollen (ich halte das fuer nicht gerechtfertigt)
Gruss, Matthias Dingeldein
--
"Warum soll ich mich stundenlang mit jemand abgeben, der mich ankotzt?
Ich meine, von Usenet mal abgesehen?"
David Kastrup
Das gilt nicht nur fuer Software-Schmieden. Selbst die tolle Smart Grid Gemeinde hat es voll verpennt den Kunden vorher einzubeziehen, und jetzt haben sie den Salat.
Wobei Eagle das recht vorbildlich tut, nur dass sie nicht immer erkennen was von den Rueckmeldungen wirklich wichtig gewesen waere. Auch dass "cut" nicht "copy" heisst und eine Schere als Symbol ungeegnet dafuer ist :-)
Das ist v=F6llig falsch gedacht! Von vorn bis hinten! Wenn Kunstgriffe, m=F6gen sie f=FCr den Wissenden auch noch so einfach = und=20 primitiv sein, erforderlich sind, um auch nur Zugriff auf diese oder je= ne=20 Funktion oder gar die Hilfe zu bekommen, so waren die Programmierer die= ses=20 Machwerks schlicht und einfach unf=E4hig. Ein Softwareprojekt hat so ge= staltet=20 zu sein, da=DF nicht nur gelernte Programmierer oder gar Informatiker d= amit=20 einigerma=DFen zurechtkommen k=F6nnen, sondern es mu=DF dem Menschen be= i seiner=20 T=E4tigkeit eine Hilfe sein. Dazu geh=F6rt vor allem auch, da=DF man we= der=20 vierw=F6chige Schulungen ben=F6tigt oder ausgiebige Studien oftmals=20 unverst=E4ndlicher Handb=FCcher betreiben mu=DF, um das Programm blo=DF= mal zu=20 starten. Programmierer, noch viel mehr aber die Projektleiter/Chefs derselben, m= =FCssen=20 einfach nur an den Anwender denken, f=FCr den Anwender entwickeln, stat= t zu=20 glauben, es gen=FCge, die geforderte Funktionalit=E4t irgendwie zu real= isieren.=20 Wenn jemand eine Benutzerschnittstelle realisieren m=F6chte, dann mu=DF= er=20 erstmal mit dem k=FCnftigen Anwender reden, dessen Bed=FCrfnisse und Er= wartungen=20 ermitteln und sich dann =FCberlegen, wie man diese bestm=F6glich realis= ieren=20 kann. Und er mu=DF davon ausgehen, da=DF nicht jeder Mensch Informatikk= enntnisse=20 in die Wiege gelegt bekam. Wer das nicht kann, der ist f=FCr solche=20 T=E4tigkeiten eine Fehlbesetzung.=20
SAP hat mit einem frontal entgegengesetzten Ansatz guten gesch=C3=A4ftl= ichen Erfolg. Merke: Das Unternehmensziel einer Softwareschmiede ist nicht ein optima= les Produkt, sondern eine optimale Quartalsbilanz.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.