Schreibfehler, andere offensichtliche Fehler in der PB-Hilfe

[Kaeru Gaman]

> mit DOS hat das sowieso nichts zu tun, wenn ich mich nicht irre.

doch, die Erweiterung ist rein DOS-spezifisch, also diese codes 128-255 gab es nur unter DOS
und sie entsprechen nicht dem American Standard Code for Information Interchange.

da gibts aber noch nen anderen Ausdruck dafür, ts müßte den wissen...

[Little John]

> mit DOS hat das sowieso nichts zu tun, wenn ich mich nicht irre.

doch, die Erweiterung ist rein DOS-spezifisch, also diese codes 128-255 gab es nur unter DOS
und sie entsprechen nicht dem American Standard Code for Information Interchange.

Sorry, das entspricht nicht meinen Informationen, z.B.

Durch die Firma IBM wurde der zu stark begrenzte 7-Bit-ASCII-Zeichensatz (auch US-ASCII genannt) auf einen Adressraum von 8 Bit (0 bis 255) erweitert, um mehr Sonderzeichen wie Umlaute darstellen zu können. Dieser 8-Bit-ASCII-Code wird auch erweiterter ASCII-Zeichensatz genannt.

Andreas Voss:
Das große PC- & Internet-Lexikon 2009.
Düsseldorf: Data-Becker.
Stichwort ASCII, S. 65

Als das Zeitalter der PCs anbrach, war das Byte mit 8 Bit als "atomare Einheit" bei der Speicherung von Daten und Befehlscodes längst ein weltweiter Standard geworden. Theoretisch wäre die Erweiterung von 128 auf 256 Zeichencodes bereits zu den Zeiten des Apple II möglich gewesen -- die praktische Durchsetzung ist aber IBMs Verdienst: Der Video-Adapter des 1981 erschienenen PC-Urmodells enthielt in seinem ROM einen auf 256 Codes basierenden Zeichensatz, der schnell zu einem wesentlichen Bestandteil des Zauberwörtchens "IBM-kompatibel" wurde.

Dieser "erweiterte ASCII-Zeichensatz" umfaßte neben einigen Diakritika und den (in der Mathematik benötigten) griechischen Kleinbuchstaben diverse Blockgrafiksymbole [...].

Charles Petzold:
Windows-Programmierung.
Unterschleißheim: Microsoft Press Deutschland 2000
deutsche Übersetzung der 5. engl. Aufl., S. 26


Da das Betriebssystem DOS auf diesen IBM-kompatiblen PCs lief, unterstützte es natürlich auch den erweiterten ASCII-Zeichensatz -- trotzdem ist dieser nicht primär eine DOS-Angelegenheit oder DOS-spezifisch.

Gruß, Little John

[Kaeru Gaman]

... aber wie du der Tabelle darüber entnehmen kannst, entsprechen diese 128 Zeichen nicht den heute in Fonts üblichen Ascii-Zeichen 128-255.

letztens in irgendeinem Thread über Zeichenausgabe auf der Console hatte ts den korrekten Fachbegriff
für diese Codes verwendet, ich weiß jetzt aber weder den Begriff noch den Thread.

wenn wir diesen Fachbegriff wieder auftreiben, kann man den Satz in der Hilfe entsprechend anpassen,
dann spielt es keine Rolle mehr, wie sehr DOS- oder IBM-spezifisch diese Codierung war oder nicht.

btw: die IBM Großrechner haben noch länger eine EBCDIC codierung verwendet, da lief nie was mit ASCII.

[Little John]

... aber wie du der Tabelle darüber entnehmen kannst, entsprechen diese 128 Zeichen nicht den heute in Fonts üblichen Ascii-Zeichen 128-255.

Ich habe keine Ahnung, welche Zeichen heute üblicherweise im Bereich 128-255 verwendet werden. Früher war das je nach verwendeter sprach- bzw. länderspezifischer Codepage unterschiedlich. Ist das jetzt nicht mehr so?

Gruß, Little John

[Kaeru Gaman]

vergleiche doch bitte einfach mal die obere und die untere Tabelle in der PureBasic Help.

... außerdem sollte dieser thread hier nicht zum diskutieren sein!

[Little John]

vergleiche doch bitte einfach mal die obere und die untere Tabelle in der PureBasic Help.

Weder bei der oberen noch bei der unteren Tabelle steht, auf welche Codepage sich die dargestellten Zeichen 128-255 beziehen.

... außerdem sollte dieser thread hier nicht zum diskutieren sein!

Das tut mir leid. Dieser Thread ist aber ebenso auch nur für "offensichtliche Fehler " in der Hilfe, und nicht für vermutete Fehler o.Ä. Und da die Kritik an der Hilfe die Du hier geschrieben hast z.T. selbst nicht richtig war, wollte ich sie nicht unkommentiert stehen lassen.

Gruß, Little John

[Kaeru Gaman]

mir ging es nur darum, dass die eindeutig falsche Formulierung "DOS-erweitert" mal korrigiert wird.

[Andesdaf]

OpenWindow()

Alle möglichen Ereignisse innerhalb eines Fenster werden mit den Befehlen WindowEvent() und WaitWindowEvent() abgefragt.

Es heißt "innerhalb eines Fensters".

[Andre]

Von den Vorschlägen bis 21.04.09 habe ich folgendes bisher umgesetzt, d.h. also entsprechende Schreibfehler korrigiert, fehlende Angaben ergänzt, etc....

Einige kleine Fehler bei:
@OpenWindow
@FontID
@InlineASM chapter

********************************************
Geschichte

Bei 17. Mai 2001: Version 2.30
Der fünfte Eintrag von oben ist noch englisch.
Zitat:
- Hinzugefügt a build-in ICON linker (no more need GoRC)

********************************************
Hilfe zur Mail-Library

Sobald E-Mails verschickt werden MÜSSEN sie dem in RFC 2822 definierten Standard entsprechen. RFC 2822 legt u.a. fest, dass als Zeilenumbruch in E-Mails nur CRLF zulässig ist.

********************************************
Fehler im Kapitel "Handles und Nummern" hinweisen, wo die Begriffe "ID", "Nummer" und "Handle" durcheinandergewürfelt werden.

********************************************
FTP Lib auf ExamineFTPDirectory und dann in der Beschreibung auf FTPDirectorySize() drücke.
Fehler ist wohl, es müßte FTPDirectoryEntrySize() heissen, derselbe Fehler mit FTPDirectory(Entry)Date()

********************************************
am Ende der "SysTray.pb" steht ein überflüssiges Prozentzeichen:

********************************************
Die Hilfe zu StatusBarImage() wiederspricht sich:

********************************************
GetXMLAttribute()
Nur Knoten vom Typ #PB_XML_Normal können Attribute haben. Für alle anderen Knoten-Typen gibt diese Funktion leere Strings zurück.
=> Das stimmt nicht: Bei anderen Knoten-Typen erzeugt PB einen Fehler ...

********************************************
Hex() optional einen zweiten Parameter haben kann

********************************************
ReceiveHTTPFile()
In der Hilfe dazu ist eine seltsame Formulierung:

********************************************
ReceiveFTPFile()
SendFTPFile()

Hier wird zwar der Asynchron-Parameter erwähnt, jedoch nicht welchen wert
dieser enthalten muß. Vielleicht sollte man hier doch besser mit bei schreiben
das man #True oder #False angeben kann.

********************************************
deutschen Hilfe bei CreatePack():
Dateien sollte durch Funktionen ersetzt werden

********************************************
nochmal Window.pb
am Ende befindet sich ein Gleichheitszeichen.

********************************************
SortStructedArray()
Animals(2)\Name$ = "Zebre"

********************************************
Kapitel "Prozeduren Unterstützung" sollte zumindest einen Bindestrich verdient haben

********************************************
Im Kapitel CreateSprite fehlt die Beschreibung der neuen Konstante #PB_Sprite_AlphaBlending.

********************************************

Einiges weitere ist auch noch offen, weil ggf. die Programmierer Fred bzw. freak hier etwas beisteuern/überprüfen müssten.

********************************************
Fehler in der Hilfe zu GetGadgetItemText ist immer noch da.
....bzgl. ListIcon

Hier kann ich beim besten Willen keinen Fehler entdecken. Die Beschreibung bei GetGadgetItemText als auch ListIcon ist zwar unterschiedlich formuliert, inhaltlich jedoch m.E. absolut korrekt.

Nun weiter im Text...

[Andre]

.... und noch weitere erledigte Fixes:

********************************************
- PureBasic x86 erstellt keine 64 Bit Executables. Für damit kompilierte Programme gewährt das Betriebssystem nur eine Adressierung mit 32 Bit Pointern.

********************************************
Letzte Zeile Terrain.pb hat Folgendes geschrieben:
End-
bitte das ungezogene Minus entfernen.

********************************************
Letzte Zeile XML.pb hat Folgendes geschrieben:
EndIf"
Bitte das Anführungszeichen entfernen.

********************************************
Packer.pb
Letzte Zeile Packer.pb hat Folgendes geschrieben:
End +

Bitte Plus entfernen

File.pb
Letzte Zeile File.pb hat Folgendes geschrieben:
End ,

Bitte Komma entfernen

Enity.pb
Letzte Zeile Enity.pb hat Folgendes geschrieben:
End¿

Bitte spanisch entfernen

********************************************
Kommandozeilenoptionen hat Folgendes geschrieben:
[...] verschiedene verknüpfungen zu erstellen, [...]
Bitte Verknüpfung groß schreiben.

********************************************
PureBasic-Node hat Folgendes geschrieben:
Nodes ("Knoten") sind Container, welche verwendet werden können, um Objekte wie Entities, Sound, Camera, Billboard" und sogar Nodes selbst zusammen zu gruppieren.
Bitte die doppelten Hochkommas entfernen.

********************************************
FontRequester bzw. ColorRequester bzw. OpenFileRequester bzw. SaveFileRequester
Jeder oben genannte Requester hat Folgendes geschrieben:
Öffnet einen Standard Requester [...]

Standard Requester bitte entweder mit Bindestrich oder ganz zusammen
schreiben.

********************************************
In jedem Fall sollte Null groß geschreiben werden.
Dieser Fehler tritt bei folgenden Hilfeseiten auf...

********************************************
Enthaltene Debugging-Werkzeuge hat Folgendes geschrieben:
"Alle Einträge anzeigen" zeigt einfach alles an. "Nur Nicht-Null Einträge anzeigen" wird nur die Einträge anzeigen, die nicht den Wert 0 oder einen leeren String enthalten.

********************************************
Erstellung einer DLL hat Folgendes geschrieben:
- Die Deklaration von Arrays und LinkedLists mittels Dim bzw. NewList muss stets innerhalb der Prozedure AttachProcess erfolgen.
Bitte zu 'Procedure' oder 'Prozedur' ändern.

********************************************
Unter SysTray - SysTray Beispiel gibt es ganz unten als letztes Zeichen ein "%"

********************************************
SendNetworkString()
Die Bytes des Strings werden als Roh-Daten (ohne das abschließende NULL-Zeichen) versandt und können mittels ReceiveNetworkData() empfangen werden

********************************************