Posts by detlef

    Noch eine Frage: Früher stand der Cursor (abwechseln invertierend) auf einem Zeichen, heutzutage hat man üblicherweise eine strichförmige Schreibmarke zwischen den Zeichen. Gäbe es aus eurer Sicht einen Grund, weiterhin auf den alten Cursor zu setzen?

    Bei den meisten moderneren Editoren, die ich kenne, steht der blinkende Strich für Insert-Modus und der invertierende Cursor für Overwrite.

    Messungen in einer Schaltung, die potentialfrei ist, wie üblicherweise sekundärseitig im Schutzkleinspannungsbereich der Fall, werden durch die Oszi-Masseklemme an einer Stelle geerdet, eine Schleife entsteht da nicht.

    Hallo,

    nur eine kleine Zwischenfrage: Oft wird ja das Gehäuse und damit oft auch die Schaltung geerdet (Schuko Stecker). Kann es da nicht zu einer Schleife kommen?

    Nicht nur zu Schleifen sondern auch zu satten Kurzschlüssen. Wie in diesem EEVBlog-Video noch mal schön erklärt wird (ab 10:20 Scenario #3):

    Solange du nur den Tastkopf in die Steckdose steckst und nicht den Masseanschluß anklemmst, wird nichts kaputt gehen und keine Sicherung auslösen. Vorausgesetzt, dein Messquipment verträgt die 230 Volt. Die Messung erfolgt dann gegen Erdpotential.


    Das mit der Gefährung ist dabei aber ein ganz anderes Thema.


    Aber wenn die Frage wirklich ernst gemeint ist, dann würde ich das sein lassen.

    In Bezug auf Formatvorlagen:

    Hatte Word (also die DOS-Version) sowas schon?

    Ja, hatte es. IMHO mindestens schon seit Word 4.0 (die erste, die ich kannte - Screenshots unter https://winworldpc.com/product/microsoft-word/40-dos). Leider ist mein Buch zu Word 5.0 bei meinem Vater, so dass ich nicht nachschauen kann.


    Laut https://docplayer.org/7638127-Word-4-0-kurz-und-buendig.html scheint meine Erinnerung zu stimmen, es redet im Inhaltsverzeichnis von Druckformatvorlagen. Insbesondere wird auch auf solche von älteren Versionen eingegangen, das scheint es also auch schon gegeben zu haben.

    Formatvorlagen in Word habe ich intensiv genutzt für die Erstellung von umfangreichen Dokumentationen. Allerdings sicher erst ab Word 6. Bei Word 5 weiß ich auch nicht mehr genau.


    Auch die automatische Erstellung von Inhaltsverzeichnissen und zum Beispiel Bildverzeichnissen ist ein wichtiges Feature für umfangreichere Texte.


    EDIT: Ich habe gerade nochmal nachgeschaut. Word 4 kam laut Wikipedia 1989. Zu der Zeit habe ich damals schon die Dokumentationen erstellt. Müsste demnach also schon Word 4 gewesen sein. Und ich habe definitiv vor 1989 einem Bekannten geholfen, seine Diplomarbeit mit Word zu schreiben. Da haben wir diese Features auch alle schon genutzt. Inkl. der Fußnotenfunktion.


    Wir hatten damals einen Postscript-Drucker in der Firma (15.000 DM). Die Ausdrucke hatten also schon Buch-Qualität. Ob Word für DOS schon Postscript-Drucker direkt unterstützt, weiß ich nicht mehr. Kann auch sein, dass ich mit Word eine andere Emulation genutzt habe.

    Eigentlich wollte ich mich ja nicht mit diesem neumodischen Web-Krams auseinandersetzten aber das Electron-Framework sieht echt sehr interessant aus.

    Es lassen sich auch "normale" Desktop-Anwendungen damit erstellen. Allerdings wird mit jedem Programm, egal wie gross, immer eine Chromium-Instanz mit ausgeliefert.

    Es gibt scheinbar keine Restriktionen wie man sie u.U. bei einer reinen Webanwendung hätte. Aber es ist ein Zusammenspiel mehrerer Sprachen (CSS, HTML, JavaScript, und vielleicht noch mehr). Ich schaue es mir auf jeden Fall mal an.

    Sehe ich das richtig, dass Electron nicht die eigentlich Programmierumgebung ist, sondern dass das am Ende die Webanwendung zusammen mit Chromium in eine Desktop-App packt?


    Programmierung in purem HTML und JavaScript empfinde ich als ziemlichen Fummelkram und schwer zu debuggen.

    Dann würde ich das gleich mit React oder Angular oder sowas machen. Damit kann man dann richtig programmieren und vor allem dank JSX direkt Html in den Code reinschreiben. Und dann noch Typescript nehmen statt Javascript. Dann hat man insgesamt eine brauchbare Programmierumgebung.


    Aber damit wird es natürlich nochmal aufwendiger mit der Einarbeitung.

    cross-platform. Windows (only) sucks.

    Das sehe ich, ganz eigennützig, auch so. Für Windows gibt es ohnehin schon Char/Sprite-Editoren wie Sand am Meer – da könnte man mit einer Cross-Platform-Entwicklung (wenigstens Win/Mac/Linux) wirklich noch punkten. Ich werfe mal so ein Buzzword, wie Xamarin in den Raum, wenn es unter Windows passieren soll.

    Xamarin kann unter Linux keine GUI. Nur unter MacOS, iOS, Android und natürlich Windows.

    Sonst hätte ich das auch schon empfohlen.

    Die UI-Programmierung ist WPF-ähnlich, also nicht so ganz trivial mit MVC und Bindings und so. Aber halt nicht unter Linux.


    Achso, und MacOS oder iOS Apps unter Windows bauen, das geht natürlich nicht. Da hat Apple was dagegen. Man braucht also zusätzlich noch einen Mac mit Xcode. Oder man entwickelt gleich mit Xamarin für MacOS. Wir sind in der Firma dann irgendwann mit der Entwicklung von Windows nach MacOS umgestiegen, weil es besser funktionierte. Wobei Visual Studio für MacOS grottenschlecht ist. Und MacOS selber ... naja, anderes Thema. ;)

    Soll es aber bei einer reinen Windows Forms oder WPF Anwendung bleiben ist es eigentlich egal ob man nun C# oder VB nimmt, wobei man in VB deutlich mehr tippen muss und ich finde der Code ist auch nicht so übersichtlich wie in C#, aber das kann auch nur mein Eindruck sein.

    C# ist eben näher an C und von daher deutlich kompakter als BASIC.

    Aber seit ich beruflich Java- und Typescipt machen machen muss, empfinde ich auch C# als extrem umständlich. ;)

    Das ist alles eine Frage der Gewöhnung.

    • Ich möchte mich mehr mit der Problemstellung meines Projektes beschäftigen als mit den Eigenheiten von Klassen & Merkmalen. Programmieren kommt vor Recherchieren.

    Auf Grund dieser Vorgabe würde ich auch zu einer Windows Forms Applikation in C# raten. Mit Visual Studio.

    WPF-Anwendungen sind mit ihrem MFC-Komzept (Model-View-Controller) deutlich komplizierter.


    Unter Linux läuft es dann nativ natürlich nicht. Das braucht dann eben Wine.

    na ja, woher weiss man, ob die Datenübertragung besser sein könnte?

    Es gibt doch nur die Möglichkeit: Programm wird gelesen ja oder nein (und bei nein kann's ja auch am Tape liegen).

    Aber ich will das gar nicht weiter vertiefen, bevor ich nicht einige Ladeversuche unternommen habe.

    An der „Lautstärke“ des Signals. Je lauter, desto besser.

    Ernst gemeint? :gruebel

    Das schließt man an Erde an, um den Schirm zu erden. Wenn der nicht geerdet ist, schwebt er. Am C64, VC20 wird das allerdings etwas schwierig, da das für die Commodore-Geräte gedacht ist, die ein Metallgehäuse haben. Wenn der Schirm korrekt geerdet ist, funktioniert die Übertragung besser, wenn Du Störungen in der Umgebung hast, die in das Kabel einstrahlen und und die Datenübertragung stören oder gar verfälschen.

    Wobei die CBM-Geräte keinen Anschluß zum Erden einer externen Datasse hatte.

    Die interne Datasette beim PET 2001 hätte man damit erden können, aber die oben gepostete Datasette passt nicht in den PET. Ich glaube die alten Datasetten der CBMs hatte diesen Erdanschluss auch gar nicht.

    Außerdem überträgte die Datasette ein 5V-Digitalsignal. So leicht wird sich das auf dem kurzen Kabelstück nicht stören lassen. Ist ja kein Audio-Signal.


    Passt also irgendwie alles nicht zusammen. :gruebel

    In Deinem Link haben die Stifte mit mehr als zwei Kontakten einen weißen. Das könnte Pin 1 jeweils sein.

    Ich denke eher, dass die schwarzen die Default-Belegung sind.


    Ok, über die Default-Einstellung in den Tabellen und die Kennzeichnung der Default-Belegung in der Grafik kann man dann Pin 1 ermitteln (wenn die Theorie stimmt).

    Das ist keine Anleitung, das ist ein Intelligenztest. :D