Beiträge von Code-Jack

  • Datenbank dezentral erweitern [gelöst]

    Hmm, interessant, was man so heraus findet.

    Laut SQLite-Doku war mein bisheriges Autoincrement ohnehin gar nicht nötig:

    http://www.sqlitetutorial.net/sqlite-autoincrement/

    Habe es ausprobiert und beim Kreieren der Tabelle das Autoincrement einfach mal weg gelassen.

    Funzt wie eh und je. Jeder neue Eintrag bekommt automatisch eine neue, forlaufende ID, beginnend ab 1.

    SQLite tut tas einfach von sich aus, die Doku rät daher von der Verwendung von Autoincrement ab.

    Gut, habe es also raus genommen.

    Nun kann ich beim Hinzufügen von neuen Datensätzten ins ID-Feld statt "NULL" eine beliebige Zahl einsetzen. Solange die eindeutig ist, funzt das.

    AutoIt
    ;Bisher war es so (gekürzte Zeile):
_SQLite_Exec(-1, "INSERT INTO Mainboardverwaltung VALUES(NULL,'16-04-22', ...

;Neu, jetzt so: Statt NULL eindeutige und selbst vergebene ID (in diesem Beispiel "77"):
_SQLite_Exec(-1, "INSERT INTO Mainboardverwaltung VALUES(" & 77 & ",'16-04-22', ...

    Gut, das war schon der erste Schritt zum Erfolg.

    Nun mit GUID:

    AutoIt
    ;Tabelle jetzt so kreieren (gekürzt):
Global $sDBHeader = "CREATE TABLE IF NOT EXISTS [Mainboardverwaltung]" _
  & "([ID] TEXT PRIMARY KEY," ...

_SQLite_Exec(-1, "INSERT INTO Mainboardverwaltung VALUES('" & _WinAPI_CreateGUID() & "','16-03-27 16', ...

    Und das klappt tadellos! :)

    Die Tabelle muss also jetzt zuvor einfach "TEXT" als Primary Key bekommen, statt wie bisher INTEGER und AUTOINCREMENT.

    Denn Integer wäre auch in der 8 Byte Variante (64 Bit) zu kurz, um die GUID aufzunehmen, mit ihren 128 Bit.

    Da _WinAPI_CreateGUID() sowieso einen String liefert, passt das.

    Ich schalte den Thread mal auf "gelöst" und bedanke mich für die guten Anworten!

  • Datenbank dezentral erweitern [gelöst]

    Yeah, danke Bitnugger!

    Die AutoIt-Hilfe ist dazu ja etwas spärlich, aber hier wurde ich fündig:

    https://msdn.microsoft.com/de-de/library/bb979128.aspx

    Ich hatte schon mit dem Gedanken gespielt, selbst so eine irre lange ID zu erzeugen; wusste gar nicht, dass AutoIt das von sich aus kann.

    Dann würde ich in Zukunft diese ellenlange ID gar nicht mehr anzeigen.

    Beim Autoincrement war es noch naheliegend, die mit höchstens 5 Zeichen angenehm kurze ID in der Maske sichtbar darzustellen. Aber es ist ja viel eleganter, diese lange GUID gar nicht darzustellen, sondern bloß intern zu verwenden.

    Dem User steht ja immer noch seine editierbare "Eigene ID" zur Verfügung.

    Selbst wenn er da mal eine Dublette hinein setzt (und das Program das nicht abfängt), so würde das zumindest programmintern nichts ausmachen.

    - Im Gegenteil: Die Verwendung der GUID "unter der Haube" ermöglicht es dem User dann in für ihn nachvollziehbarer Weise, Kopien weitgehend identischer Datensätze anzulegen. Z. b. mit im Stamm identischer Bestellnummer, wo bloß die letzte Ziffer differiert.

    Im Moment geht es mir um die Verwaltung von Notebook-Mainboards.

    Später kommt noch ein Prüfgerät für Mainboards hinzu, das mit meinem Programm kommunizieren wird (ich repariere beruflich Notebooks und entwickle auch Geräte).

    Da kommt es oft vor, dass ein Mainboard anhand seiner aufgedruckten Mainboard-Bezeichnung nicht eindeutig identifiziert ist.

    Vielmehr gibt es noch unterschiedliche Bestückungsvarianten dieses Mainboards. Und davon wiederum mehrere Revisionsnummern.

    Da können durchaus schon mal 10 leicht unterschiedliche Mainboards existieren, die alle auf die selbe Bezeichnung hören ...

    Trotz identischem Notebook-Modell und identischer Mainboardbezeichnung, hätten die dann logischerweise abweichende elektrische Daten, die mein Testgerät natürlich allesamt im Detail kennen muss.

    Ergo legt man pro MB-Bezeichnung, pro Bestückungsvariante, pro Revisionsnummer, einen eigenen Datensatz an.

    Die können dann alle durchaus eine identische "Bestellnummer" haben, bzw. "Eigene ID", aber die elektrischen Daten weichen halt voneinander ab und da wird mein Testgerät penibel drauf reagieren.

    Es erscheint mir daher spontan sinnvoll, Deinem Vorschlag zu folgen und "unter der Haube" jedem Datensatz so eine GUID zu verpassen.

    - Auch wenn ich im Startposting noch darüber gejammert hatte, dass die ID möglichst nicht zu lang werden soll. Da hatte ich halt noch die "menschenlesbarkeit" im Visier.

    Istja sogar viel besser, die im Gegenteil heftig lang zu machen und auszublenden. Es würde die User eh nur überfordern, wenn jeder Datensatz mit zwei unterschiedlichen Arten von IDs daher käme, von denen eine sich ganz hartnäckig gegen jede Editierung sträubt. ;)

  • Datenbank dezentral erweitern [gelöst]

    Danke, das klingt schon mal nach einem brauchbaren Ansatz.

    Bisher hatte ich dafür ein Feld "Datensatz amtlich - Ja/Nein" vorgesehen, um die "offiziellen" Datensätze von denen zu trennen, die die User selbst erstellt haben.

    Aber ich denke, Dein Vorschlag ist besser: Vom User selbst angelegte Datensätze kriegen nicht bloß so ein "inoffiziell"-Flag verpasst, sondern sie fließen in eine eigene Tabelle ein.

    Dadurch kann ich die offiziellen/inoffiziellen Datensatz-IDs sauber voneinander trennen und weiterhin mit Autoincrement arbeiten.

    Lädt dann ein User seine "Datenspende" auf meinen Server hoch (wird wohl einfach auf mein Forum hinauslaufen, per Dateianhang), dann muss anschließend entweder meine Wenigkeit himself, oder einer meiner Moderatoren, sich darum kümmern, die Plausibilität zu beäugeln und die neuen Datensätze (sofern dem Anschein nach OK) in die offizielle Tabelle einfließen zu lassen, wobei sie dann eine offizielle ID verpasst bekommen.

    Lädt der "Spender" später sporadisch mal wieder die volle Datenbank herunter, dann würde im besten Fall eine Dublettenerkennung seine Tabelle mit selbst erstellten Datensätzen leeren, denn die sind ja nun eh in der offiziellen DB vorhanden.


    Ich spiele ohnehin mit dem Gedanken, Datensätze im Normalfall nicht zu löschen, sondern ein quasi unendliches "Undo/Redo" zu ermöglichen, indem der alte Stand editierter Datensätze, sowie auch gelöschte, lediglich ausgeblendet werden.

    Halt ähnlich wie der Windows-Papierkorb, aus dem man alten Müll wieder hervorkramen kann, bis er explizit geleert wird.

    Bei jedem Editieren eines Datensatzes wird dann eine vollständige Kopie erzeugt, die in diesem Recycling-Müll landet, versehen mit einer Timestamp.

    Wenn ein User Daten "spendet", dann sorgt seine Exportfunktion dafür, dass nur die jeweils aktuelle Version hochgeladen wird.

    Und dass schon einmal exportierte Datensätze dabeiausgeklammert werden.

    - Wobei das auch wieder doof ist, denn schusselige User könnten mehrfach exportieren, editieren, exportieren ... und am Ende doch nur einmal hochladen.

    Aber irgendwie muss ich ja verhindern, dass Heini Schusselmann immer und immer wieder seine Datenspende hochlädt, sich seine Tabelle aber nie leert, weil er niemals die offizielle DB herunter lädt.

    Ich befürchte da einen Fulltime-Job für meine Moderatoren, die die offizielle Datenbank pflegen. :/

    Dummerweise enthält die Datenbank auch nicht nur Text, den man problemlos auf den ersten Blick für plausibel/unplausibel erachten könnte.

    Sondern sie enthält später auch Binärdaten aus Messreihen, mit denen dann ein elektronisches Testgerät gefüttert wird.

    Eben aus diesem Grund will ich ein "unendliches Undo/Redo" ermöglichen,

    Hat sich dann mal jemand seinen funktionstüchtigen Parametersatz zerschossen, entweder per eigenem Edit, oder per Update durch Import von "offiziellen Daten", dann sind die alten Stände der Datensätze noch vorhanden und können im Bedarfsfall reaktiviert werden.

    Vor einigen Jahren habe ich mal an der Entwicklung eines Gerätes mitgearbeitet, zusammen mit einem räumlich getrennten Kollegen. Der hatte dann einen SVN-Server aufgesetzt worüber wir unsere Dateien synchron hielten.

    Etwas unheimlich war mir das aber schon, denn erstens habe ich das Ding nie ganz verstanden, zweitens musste ich dazu auf meinem Rechner einen speziellen Ordner einrichten, der sich dann irgendwie mit dem SVN-Server synchronisierte.

    - Also solche Dinge möchte ich meinen Usern lieber nicht zumuten.

    Ich mag es am liebsten, wenn man auch ganz ohne Online-Zugang alles machen kann und im Bedarfsfall Dateien klassisch altmodisch tauscht, per E-Mail, oder über ein Forum. Nix mit Cloud (die habe ich noch NIE benutzt!) und möglichst nix mit SVN - es sei denn, man überzeugt mich von dessen unverzichtbarem Nutzen.

    Also vorzugsweise klassisch.

    Es soll nur nicht in eine Arbeitsbeschaffungsmaßnahme ausarten, für denjenigen, der die offizielle Datensammlung pflegt.

    Es wird hier aber so sein, dass die Masse der neuen Daten von den Usern kommen wird.

  • Datenbank dezentral erweitern [gelöst]

    Mal eine rein konzeptionelle Frage:

    Ich habe mit AutoIt eine Datenverwaltung geschrieben.

    Die zugehörige, prall mit Inhalten gefüllte SQLite-Datenbank wird später mitgeliefert.

    Bisher arbeitete nur ich selbst mit Programm und Datenbank.

    Zu jedem neuen Eintrag erstellt SQLite bislang einfach eine fortlaufende Datensatz-ID, per Autoincrement.

    Zusätzlich zur automatisch generierten Datensatz-ID habe ich auch ein Feld "Eigene ID". Dort kann z. B. eine Art Bestellnummer eingetragen werden, die natürlich in der Praxis wiederum eindeutig ist und sich niemals wiederholt. Aber sie kann prinzipiell frei vergeben werden.

    Soweit der Ist-Stand (der so nicht unbedingt bleiben muss).

    Problem nun:

    Angenommen, rund um die Welt arbeiten künftig mehrere User mit meinem Programm und besagter Datenbank.

    Jeder User soll natürlich in seiner lokalen Datenbank (ohne Online-Verbindung) neue Datensätze hinzufügen können.

    Jeder spendierfreudige User soll seine Einträge aber auch mit den anderen Usern teilen können.

    - Also ein Export neu angelegter Datensätze, die andere User in ihren eigenen Datenbestand hinzu "mergen" können, ohne dass es dort zu Konflikten mit bereits bestehenden Einträgen kommen darf.

    Idealerweise sollte nach so einer Datensatz-Tausch-Aktion eine jede Datenbank eines jeden einzelnen Users die gleiche Anzahl Datensätze aufweisen (sofern jeder mitmacht).

    Und - das ist der Punkt - alle Datensätze sollten dann überall die gleiche ID haben (so jedenfalls meine hemmungslose Wunschvorstellung).

    Mir fällt als Lösungsansatz nur ein zentraler Server ein, der die Aktivitäten der User koordiniert und von sich aus überall eindeutige Datensatz-IDs vergibt.

    - Das möchte ich aber möglichst nicht! Aus folgenden drei Gründen:

    • Erstens empfinde ich das Verfahren als arg kompliziert (schwacher Grund, ich weiß).
    • Zweitens als nicht hinreichend ausfallsicher. Jeder Server kann schon morgen dicht machen.
    • Drittens mag ich es grundlegend nicht, wenn Software "nach Hause telefoniert".

    Die Frage lautet also, ob es einen irgendwie dezentralen Ansatz für diese Problemstellung gibt?

    Zum Beispiel der Art, dass jeder einzelne User "auf Antrag" einmalig eine (eindeutige) Art Namenskürzel zugeteilt bekommt, welches in die Datensatz-ID mit einfließt?

    Also nix mehr mit simplem Autoincrement in SQL, sondern komplexere IDs.

    Tatsächlich hätte so ein Namenskürzel was. Ich möchte es nämlich (pseudonymisiert) nachvollziehen können, welcher User welchen der untereinander geteilten Datensätze erstellt hat.

    Schon allein deshalb, um Vandalen ausklammern zu können, die den Datenbestand (den ich ja selbst nutze!)mit Murks-Einträgen voll müllen.

    Wirklich sicher vor Vandalen wäre man mit einer derart simplen Methode zwar nicht, aber es geht hier auch nicht um Hochsicherheitstechnik.

    Vorrangiges Ziel ist halt, dass User ihre selbst erstellten Datensätze "spenden" können und dass andere User solche "Spenden" zu ihrem lokalen Datenbestand hinzu "mergen" können, wobei die Datensatz-IDs überall, in jeder einzelnen Datenbank, gleich sein sollen.


    Mein Programm wird Freeware und mehrsprachig, es ist folglich kaum absehbar, wie viele User es weltweit mal geben wird.

    Ein Namenskürzel aus nur zwei Buchstaben/Zeichen könnte daher etwas kurz sein. Aber die Datensatz-ID soll ja auch nicht irre lang werden. Bei mehr als 10.000 Datensätzen ist sie ja jetzt schon fünf Zeichen lang.

    Es würde mich aber auch nerven, mich dauernd darum kümmern zu müssen, "auf Antrag" solche Kürzel an User schicken zu müssen. Zumal ich ja mal 'nen Unfall haben könnte etc. - die User sollen dann nicht im Regen stehen, sondern die Sache soll weiter laufen.

    Ich denke, für die geschilderte Problemstellung müsste es doch schon längst kluge Ansätze geben. Aber ich habe keine gute Idee, wie so ein Ansatz aussehen könnte.

    Wer weiß Rat?

  • GDI+ Spielerei

    Ah, das erinnert mich an die gute alte Zeit, in den 90ern, als ich noch Lasereffektgeräte baute.

    Damals programmierte ich dann auch Simulationen solcher Geräte, noch auf den Atari, in GFA-Basic (schwelg in Nostalgie) ...

    Erstaunlicherweise läuft Deine Routine auf dem PC nicht schneller, als meine, damals auf dem Atari.

    Spontan würde ich vermuten, dass einer der Gründe dafür der ist, dass Deine vorausberechneten Werte $x[$i] und $y[$i] Vom Typ her Fließkommazahlen sind. Möglicherweise bremst das die eigentliche Zeichenroutine unnötig aus.

    Probiere doch mal, dort in den vorausberechneten Arrays ganzzahlige Werte zu erzwingen.

    Weiterer Verbesserungsvorschlag:

    Mache den Hintergrund schwarz und zeichne die Figur in leuchtend grellem Rot. Dann kommt das einem Lasereffektgerät schon viel näher,

    Und dann kann man noch eine nette Sache machen:

    Vorausgesetzt, Du kriegst die Zeichnerei noch deutlich beschleunigt, müssen die von der Zeichenfunktion gesetzten Pixel "ausfaden", so ca. eine knappe halbe Sekunde nachdem sie gesetzt wurden.

    Für das Ausfaden müsste in einer Schleife jeder einzelne Pixel bei jedem Durchlauf ein kleines Stückchen dunkler gestellt werden, bis am Ende Schwarz erreicht ist, wie bei der von mir vorgeschlagenen Hintergrundfarbe.

    Ein echtes Lasereffektgerät brutzelt ja auch nicht seine Spur fest in die damit angestrahlte Wand. Sondern dort wird nur ein Laserpunkt bewegt und im Auge stellt sich so ein verblassender Nachleuchteffekt ein, der es überhaupt erst ermöglicht, solche schönen Muster wahrzunehmen.

    Wenn das mit dem Ausfaden umgesetzt ist, dann wird es denkbar, die Figur zur Laufzeit zu beeinflussen, indem man mit der Maus Schieber betätigt.

    Und noch ein Vorschlag:

    Was mir damals bei den echten Geräten irgendwie den "Kick" gab, das war dieses Surren der Motoren.

    Meine Geräte arbeiteten mit vier Motoren und das was man sah, war unmittelbar das, was man auch hörte. Abgefahren!

    Besonders effektvoll war der Effekt dadurch, dass die Motoren trotz aller Stabilisierung nie zu 100% eine eingestellte Geschwindigkeit hielten. Da war immer etwas "Leben" im Spiel, in Form von "Schwebungen", was sich natürlich unmittelbar auf die Muster auswirkte und den dabei produzierten Sound.

    Es wäre daher eine Überlegung wert, noch per Zufallsgenerator etwas wohldosierte Ungenauigkeit mit ins Spiel zu bringen und weiterhin diesen ganzen Sinuskram in Töne zu verwandeln und an die Soundkarte zu schicken.

  • Editbox nachträglich in TabControl verschieben

    Jetzt gibt es noch eine kleine Unelegantheit ...

    Ich wollte es erreichen, dass die aus dem sichtbaren Tab gelöschte InputBox dort auch tasächlich sofort verschwindet, ohne dass man dazu erst manuell die Tabreiter umschalten müsste.

    _GUICtrlTab_SetCurSel() ist hier mein Freund, dachte ich ...

    Doch da gibt es eine Sonderbarkeit:

    Die Zeile 57 ist erforderlich, damit Zeile 58 ihren erwarteten Dienst tut. Komisch.

    Aber noch komischer: Die umgekehrte Richtung funzt gar nicht.

    Die Zeilen 74 bis 76 kann ich vertauschen und auskommentieren wie ich will - Tab 1 wird nicht selektiert.

    Dabei liefert mir ein testweise als 78. Zeile hintendran gehängtes:

    ConsoleWrite("Current Selection: " & _GUICtrlTab_GetCurSel($idTabCtrl))

    erwartungsgemäß Das Resultat "1".

    Trotzdem erfolgt keine Umschaltung auf Tab 1, wenn zuletzt Tab 2 aktiv war.

  • Editbox nachträglich in TabControl verschieben

    Danke Bitnugger!

    Der Vollständigkeit halber, falls es anderen Usern hilft, hier noch der lauffähige Code:

  • Editbox nachträglich in TabControl verschieben

    Hmm, doch noch watt:

    Mir fehlt zum vollendeten Glück noch der Befehl zum Auslesen der Koordinaten der zu löschenden InputBox.

    Ich habe den Code mal entrümpelt und zwei Buttons plus Functions spendiert, um die InputBox gezielt in einen bestimmten Tab zu "verschieben".

    Das funktioniert auch, nur gehen mir die Koordinaten hops.

    Ich brauche das Gegenstück zu GUICtrlSetPos()

  • Editbox nachträglich in TabControl verschieben

    Danke für den superschnellen Rat, alpines! Allerdings klemmt es noch ...

    Ich kriege das Beispiel nicht so umgefrickelt, dass es das tut, was ich möchte. Also eine bereits existierende Inputbox innerhalb des selben Fensters in/aus einem Tab verschieben.

    Ich habe das Codebeispiel mal so geändert, dass es klarer wird, was ich vorhabe.

  • Editbox nachträglich in TabControl verschieben

    Frage: Ist es möglich, eine Editbox (oder Label, oder sonst ein Control) nachträglich in ein bereits kreiertes TabControl zu verfrachten?

    RTFM offenbarte mir dazu keine Möglichkeit.

    Wozu das gut sein soll?

    - Nun, der User soll das GUI zur Laufzeit umgestalten können. In gewissen Grenzen zumindest.

    Meine Oberfläche hat inzwischen so viele Inputboxen, dass ich gezwungen war, diese zum Teil (aber auch nur zum Teil) in TabControls zu verstauen.

    Deren Anordnung mag dem User aber nicht unbedingt schmecken. Er soll es daher selbst festlegen können, ob eine bestimmte Editbox in einem Tab sitzt, oder nicht. Und wenn ja, dann in welchem.

    Wer weiß Rat?

  • Alinas_SQLite_BuchVw

    Zitat von autoiter

    Ich bin sicher, dein Problem ist gar nicht so groß- Schau dir einfach mal SQLite-Tutorials an.

    Waah, dessen bin ich mir auch sicher! Und ich habe ausgiebig Tutorials gewälzt, trotzdem klappte es partout nicht.

    Nach ungefähr 15 Stunden kauen an diesem kleinen Problem war ich dann doch so weit, mal im Forum zu fragen.

    Aaaber - Tadaaa! - ich habe es inzwischen selbst geschaft! :party:

    Der User TheLaBu hat im folgenden Thread ein Beispiel gebracht, das ich erfolgreich abwandeln konnte:

    SQL-Ergebnis als Variable speichern

    Der aktualisierte Quelltext hängt noch einmal an, falls einem Anderen mal nützlich sein könnte.

    In dieser Form ist das Programm nämlich schon recht nahe an der ersten Brauchbarkeit (obwohl noch dick Baustelle).

    Trotzdem Danke für Deine Meldung. Ich habe schon viel aus Deinen anderen Postings gelernt!

  • Alinas_SQLite_BuchVw

    Nach zwei Jahren Abstinenz kramte ich den Quellcode endlich mal wieder hervor.

    Damals wuchs mir die Sache über den Kopf, dabei bräuchte ich das Programm eigentlich täglich ...

    - Jetzt brauche ich es aber wirklich definitiv und nicht mehr aufschiebbar!


    Aktuell scheitert es an einer simplen Sache:

    Ich möchte, wenn ein Datensatz editiert werden soll, die ganzen Inputboxen nicht mehr aus der ListView befüllen (wie einst im Ursprungs-Quelltext), sondern direkt aus der eigentlichen Quelle, also der SQLite-Datenbank.

    Grund: Die ListView soll später nur noch die relevanten Datenfelder darstellen. Der zu editierende Datensatz ist also umfangreicher, als das, was man in der ListView sieht.

    Es würde mir schon riesig helfen, wenn man mir auf die Sprünge helfen könnte, wie ich aus der Datenbanktabelle ein einzelnes Feld auslesen kann, anhand des Wertes in der Spalte "ID". Dann würde ich den Rest selbst schaffen.

    Seit gestern grase ich deswegen das Forum durch, probiere Beispiele aus, folge diversen Links auf SQL-Erklärbär-Seiten ... doch alle Beispiele bringen nicht das, was ich will, sind viel zu komplex und vergrößern meine Verwirrung nur.

    Anbei der gesamte Quelltext.

    Die Routine, die es bringen soll, ist in Zeile 659: "Func _Datensatz2Inputboxes"

    Wie man sieht, ist die Routine inzwischen vollständig zu Klump gemüllt, von den vielen dutzend erfolglosen Tests.

    Frage also: Wie kriege ich einen einzelnen Feldinhalt der Datenbank (definiert anhand der ID des in der ListView selektierten Datensatzes) ausgelesen, um ihn einer InputBox zuzuweisen?

  • Alinas_SQLite_BuchVw

    Boah, ist der Kanashius schnell!
    Man kann hier wirklich nur den Hut ziehen, vor den hoch kompetenten und überaus hilfsbereiten Usern, echt!
    Großartige Leute hier, beide Daumen hoch!

    stefanwue:
    Obige Version ist noch eine recht frühe Baustelle.
    Ich habe das Programm seither ein gutes Stück weiter entwickelt. wichtig war es mir, dass man die Maske jederzeit vom Programm aus, per Maus, umgestalten kann.
    Dass die Daten für die Maskengestaltung also nicht fest im Quelltext codiert sind, sondern aus einer Ini-Datei eingelesen werden.

    Ist nie ganz fertig geworden und die aktuelle Version ist noch immer nicht wirklich einsetzbar (hat auch noch Fehler), aber ich hänge dennoch mal meinen letzten Stand an, weil sich da doch sehr viel getan hat.



    Wie gesagt: Noch immer volle Baustelle, aber schon sehr viel weiter entwickelt, als die im weiter oben stehenden Posting enthaltene Version.

  • Programmier-Ideen?

    Was ich seit mindestens 15 Jahren vermisse, ist ein vernünftiges, mehrstufiges Clipboard!
    Eines das tatsächlich (nebenwirkungsfrei!) schlicht so funktioniert, wie man es erwartet, ohne blöde Einschränkungen, wie "Text only".
    Und WICHTIG: Ohne grafischer Oberfäche!!!

    Also nix mit "Bitte wählen sie aus, welchen Inhalt sie einfügen wollen".
    Sondern rein tastaturgesteuert und ausschließlich mit den üblichen Tastenkombinationen bedienbar.
    Man markiert irgendwo einen Inhalt und drückt Ctrl+c. Dann markiert man den zweiten Inhalt und drückt wieder Ctrl+c ... das wiederholt man so oft man mag.
    Und mit jedem Ctrl-v wird der jeweils zuerst ins Clipboard kopierte Inhalt gepastet und sogleich aus dem Cache entfernt.
    First in, first out.

    Ich habe im Laufe der Jahre bestimmt 20 Clipboard-Tools ausprobiert, doch keines tat diesen simplen Job so, wie ich es erwartete.

    Für den Psion Serie5 hatte ich vor vielen Jahren mal exakt so ein Tool geschrieben, das rundum perfekt seinen Dienst tut - bis heute. Doch für Win-Dosen traue ich mir das nicht zu, da funktioniert erstens das Clipboard ganz anders, zweitens könnte ich unter Windows kein Programm schreiben, dass sich permanent so tief im System einnistet und die entsprechenden drei Tastenkombinationen abfängt.
    Und - nein - es mag an einen Keylogger erinnern, aber ich wünsche mir tatsächlich nur ein mehrstufiges Clipboard, ganz ohne Hintergedanken (ein kompiliertes Programm würde mir völlig genügen).


    Ach ja, da wäre noch eine Programmidee:
    Als alter Atarianer vermisse ich seit dem Umstieg auf Windows den guten Tastenklick des Atari!
    Jaja, der Tastenklick war immer umstritten, bitte keine Diskussion deswegen; ich jedenfalls liebte ihn einfach und konnte durch ihn viel fehlerfreier schreiben.
    In meinen Augen ist ein Tastenklick eine Grundfnktion, die jeder Computer ganz selbstverständlich an Board haben sollte. Unbegreiflich, wieso PCs das partout nicht können. XP jedenfalls nicht - keine Ahnung, wie es bei Win 7/8/10 ist.

    Es gibt ein paar Tools, die vorgeblich einen Tastenklick realisieren sollen. Aber auch hier fand ich bislang keines, das immer und überall schlicht funktioniert, ohne blöde Nebenwirkungen zu entfalten

    Also wer für diese beiden Probleme eine Lösung herbei zaubert, der kann sich meiner Jubelsprünge und innigen Lobpreisungen sicher sein! :)

  • ERLEDIGT --> Raspberry Pi® 2 Model B Advanced-Set 1 GB

    @Xori, was gleubst du, was mit einem so hauchdünnen Hölzchen, in das Stege gesägt wurden, passiert, wenn man mit dem heißen Lötkolben ganz nah ran geht?
    - Die zarten Stege würden augenblicklich verkohlen.
    Aber wie ich schon schrieb, sägte und feilte ich mir bereits einen Kamm aus einem Reststück Platinen-Basismaterial. Das hält erstens die Hitze aus, zweitens ist es mechanisch wesentlich belastbarer.

    In der Praxis war ich mit dem Kamm aber nicht zufrieden. Ich bräuchte noch einen zweiten. Jedes Litzenende wird dann durch beide Kämme (die tiefe Schlitze haben) geführt und in der Mitte, zwischen den Kämmen, würde ich mit der Lötspitze rangehen.
    Nun sollen die Stege aber auf voller Länge (4-5mm) zwischen den Litzen sein, um Brückenbildung zu verhindern. Zwischen die beiden tief geschlitzten Kämme aus dünnem Material müsste daher noch ein dritter, weniger tief geschlitzter, aber breiterer Kamm.
    Also drei Kämme, in zwei unterschiedlichen Bauformen.

    Ist jetzt schwer zu erklären, aber wenn man es mal probiert hat, merkt man, wo es in der Praxis klemmt, was im theoretischen Geistesblitz so völlig plausibel und einfach erschien.
    Am besten mal selbt probieren, dann merkst du, wo es überall klemmt!


    @BugFix, ja, natürlich besitze ich eine Heißluftstation (ich repariere Notebook-Mainboards!). Aber die Isolierung der Adern würde bei Heißluftzufuhr unweigerlich verbrutzeln, da wird wohl auch Kapton nicht viel dran ändern.
    Gut, ich könnte mal probieren, die Flachkabel bis zur Abisolierung zwischen zwei Bleche einzuspannen, so dass nur die unisolierten Enden herausschauen.

    Es gibt aber ein Problem, das man erst dann auf dem Schirm hat, wenn man es wirklich mal probiert hat, zwei Flachbandkabel zusammenzulöten: Die abisolierten Enden stehen nicht kerzengerade in reih und Glied (sie bilden also keinen "Kamm"), sondern sie stehen trotz aller Sorgfald beim Abisolieren und Vorverzinnen leicht in unterschiedliche Richtung.
    Richtet man sie manuell aus, so "bewegen" sie sich, sobald Hitze zugeführt wird, weil dann die Isolierung weich wird und sich dort entspannt, wo sie zuvor den stärksten Druck hatte.

    Das mit den zwei kammartigen Alublechen hatte ich gestern übrigens auch schon probiert. Die musste ich nicht mal sägetechnisch herstellen, sondern ich hatte noch leere Trägerbleche für IC-Einzelkontakte (kennt nicht jeder). Die haben zwar das doppelte Rastermaß (100MIL), aber zwei Stück, um eine halbe Position versetzt, ergeben die gewünschten 50MIL, die ich für das Flachkabel brauche.

    Es ist richtig schwer zu erklären, warum es so ist, aber es funktionierte damit nicht gut. Dabei erschien es so plausibel!
    Ich konnte es selbst nicht glauben, dass das so nicht funzt und bog immer wieder an den Stegen herum, veränderte deren Winkel, probierte es von unten druntergelegt, wie von oben draufgesteckt - doch es geht einfach nicht gut.

    Ich glaube, eine weiche Silikonform wäre optimal.
    Die Herstellung ist auf mechanischem Wege aber praktisch unmöglich. Ich könnte mal versuchen, eine zu gießen. Also zuerst ein Negativ aus hartem Material sägen/feilen und dann 'nen Silikonabdruck davon machen.

    Hätte nie gedacht, dass das so ein Zirkus wird!
    Zwei Kabel zusammenlöten - Sache von 5 Minuten ... denkt man.

  • ERLEDIGT --> Raspberry Pi® 2 Model B Advanced-Set 1 GB

    Nee, geht nicht. Das Flachband ist 120cm lang.
    Daraus wird zunächst die Spule gelötet und dann kommt eine Falttechnik zum Einsatz.
    Die endgültige Spule ist flach, langgezogen, an beiden Enden der Strecke je zweifach gecknickt und in der Länge auch noch wie ein Bogen gewölbt.

    Die Knicke an den Enden will ich eigentlich gar nicht gerne haben, sie sind aber unvermeidbar.
    Noch ist der Aufbau sowieso nur experimentell, aber später sollen es dann 100 Stück werden.

    Da tut es richtig weh, jetzt schon aufwändige Montagevorrichtungen zu bauen, wenn noch gar nicht klar ist, ob die Spulen in der angestrebten Form überhaupt wie gewünscht funktionieren.
    Aber mit geringem Aufwand kriege ich hier partout keine Vorrichtung hin.
    Habe mir vorhin was per Laubsäge und Schlüsselfeilen aus 'nem Stück Platine gebastelt, aber funzt so alles nicht.

    Besser wäre eine Silikonform, denn die ist flexibel, so dass ich gut mit dem Lötkolben dazwischen komme.
    Habe darum (wiederum per Laubsäge) in die Kante einer Silikonmatte kurze Schlitze gesägt. Aber die sind viel zu schmal, eben weil das Material weich ist; da entspricht die Schnittbreite nicht wie gewünscht dem Durchmesser der Säge, sonden das Material reißt eher ein. Der Schitt ist also "unendlich" dünn. Da bekomme ich die Drähte nicht hinein gewürgt.

    Eine erste Spule habe ich inzwischen ganz von Hand gelötet. Hätte bald 'nen Wutanfall bekommen, dabei!
    Irgendwie nimmt die Litze das Lötzinn schon mal nicht sonderlich gut an. Das Vorverzinnen gelingt nur mäßig, trotz Flux. Und beim Versuch, die Enden zusammen zu löten, wird die Verbindung manchmal nicht gut, häufig bilden sich aber Brücken zur Nachbarlitze, die nur schwer wieder zu trennen sind, ohne die Isolierung zu verschmurgeln.

    Ich werde als nächstes dickere Druckbleistiftminen besorgen, in der Hoffnung, mir daraus eine Graphitfom basteln zu können.

  • ERLEDIGT --> Raspberry Pi® 2 Model B Advanced-Set 1 GB

    Jaaaa, Theorie und Praxis sind aber zwei Paar Schuhe! "Bau mal eben einen Kamm ..."
    Dass man ein Prinzip erfasst hat, heißt noch nicht, dass man es auch mit vertretbarem Aufwand und möglichst ohne Materialkäufe realisieren kann.

    Eben wähnte ich mich bereits auf einem sehr guten Weg:
    Ich nahm eine dünne Spiral-Zugfeder, zog sie auf die korrekte Länge und schraubte sie flach auf eine Holzleiste.
    Dann schmierte ich dort Moltofill hin, so dass sich links und recht der langgezogenen Feder eine kleine Rampe ergab und die Drahtfitzel nicht beliebig tief nach unten in die Feder rutschen können, weil darunter (also in der Feder) halt Moltofill ist.
    Dazu entfernte ich mit einem dünner geschnitzen Zahnstocher, per "Sägebewegung" gerade so viel von dem Moltofill aus den Federwindungen, dass die erste Litze vollständig dort eintaucht, die zweite, oben aufgelegt, aber so gerade eben nicht.
    Da konnte ich nun mit meinem Lötkolben zwar nicht entlang der Reihe ratschen (das würde die oberen Litzenenden doch aufspleißen, aber ich konnte zumindest relativ zügig einzeln verlöten.

    Die böse Überraschung kam, als die die Kabel aus der Feder nehmen wollte.
    Zwar benetzt und hält das Lötizinn nicht an der Feder, aber es wölbte sich gewissermaßen um den Federdraht ein Stück weit herum, so dass die verlöteten Kabel fest an der Feder klemmten.
    Am Ende riss mir die Feder aus dem Moltofill - Versuch gescheitert. :(

    Mit einigen weiteren Bastelversuchen werde ich sicher noch eine brauchbare Lösung finden, aber es ist halt wirklich nicht so einfach, wie man denkt.
    Auch mit 40 Jahren privater und beruflicher Löterfahrung ist man also noch nicht am endgültigen Ende der Lernkurve angelangt, wo man jede zunächst "einfach" erscheinende Lötaufgabe locker aus dem Handgelenk bewältigt!

  • ERLEDIGT --> Raspberry Pi® 2 Model B Advanced-Set 1 GB

    Sowas meinte ich, mit einer improvisierten Vorrichtung, Xori.
    Aber wenn schon, dann so, dass sich eine kammartige Barriere zwischen allen Adern befindet, so dass ich einfach mit dem Lötkolben a der ganzen Reihe entlang ratschen kann.

    Müsste ich die Adern einzeln fixieren und zusammenlöten, so wie Du es beschreibst, würde das viel zu lange dauern.

    Der "Kamm" müsste hitzefest sein (Silikon / Kapton / Graphit / Edelstahl / Gips), muss Lötzinn abweisen, darf nicht zu schnell verschleißen (nix Gips) und soll mir auch nicht die Lötspitze ruinieren (nix Edelstahl).

    Eine Grahiptplatte von ca. 4mm Stärke, die ich senkrecht fixiere und per Säge mit Kammschlitzen versehe, dürfte sehr gut geeignet sein. Habe ich natürlich nicht da, also muss mit vorhandenem Material improvisiert werden.
    Hauchdünnes Kaptonband habe ich da, mir fehlt aber eine zündende Idee, wie ich daraus mit vertretbarem Aufwand eine geeignete Vorrichtung basteln kann.

    Statt aus Flachbandkabel könnte ich auch eine Flexi-Platine anfertigen lassen, aber die kostet in den benötigten Dimensionen mindestens 60,- EUR. Bei hundert Stück ist das einfach zu teuer.
    Ein von Hand wickeln der Spulen kommt sowieso nicht in Frage, weil die letztlich benötigte Spulengeometrie dazu zu kompliziert ist (Details erspare ich mir mal). Das mit dem Flachbandkabel erschien mir daher als preiswerte und akzeptable Alternative. Aber wenn ich pro Exemplar eine Stunde am Basteln bin, dann sind 100 Stunden futsch. Also 10-12 Tage stramme Idiotenarbeit. Das muss schon irgendwie rationeller bleiben.

    Wenn man in den von mir verlinkten Videos sieht, wie dort vielpolige ICs durch Entlangziehen des Lötkolbens an den Pins ruckzuck verlötet werden, dann entspricht das meiner Idealvorstellung. Das geht aber mit feiner Litze so einfach nicht; oder ich stelle mich zu dumm an. Also muss ich wohl eine Hilfsvorrichtung basteln. doch an der möchte ich auch nicht unbedingt erst erst zwei Tage werkeln müssen.

    Experimentierplatine, so entlang an den Löchern abgesägt, dass sich ein kurzer Kamm ergibt, würde ja theoretisch einigermaßen gehen, wenn das Flachbandkabel nur halb so viele und doppelt so breite Adern hätte.
    Realistisch ist es kaum machbar, da noch jeweils einen Zwischensteg einzusägen.

    Vielleicht kann ich eine kleine Spiralfeder wickeln und auf passende Breite ziehen. Wenn die beim Löten nicht zuviel Hitze wegzieht, könnte das klappen.
    Elegant wäre der Ansatz, nach dem Ausrichten eine stark, aber sorgfältig definiert erhitze Schraube in die Spiralfeder zu stecken, so dass von deren abklingender Restwärme die vorverzinnten (oder mit Lötpaste versehenen) Litzen auf einen Schlag zusammenschmelzen, so dass der Lötkolben gar nicht mehr zum Einsatz kommen muss.

    Ist schon anspruchsvoll!
    Man merkt hier hoffentlich den Unterschied, zu: "ich habe schon mal auf dem Labortisch ein Kabel an 'nen Arduino gelötet - Löten ist einfach!"