Seite 33 von 34

Re: Schreibfehler, andere offensichtliche Fehler in der PB-H

Verfasst: 13.08.2016 13:41
von Kiffi
Power P hat geschrieben:In der Hilfe und in der PDF sind in dem Kapitel "Vehicle" sämtliche Umlaute falsch dargestellt.
ebenso online: http://www.purebasic.com/german/documen ... index.html

und im Hilfe-Index: http://www.purebasic.com/german/documen ... index.html

Grüße ... Peter

Re: Schreibfehler, andere offensichtliche Fehler in der PB-H

Verfasst: 25.08.2016 18:26
von Rudi
Das ListIconGadget unterstützt auch, mit einem Aufruf, das Setzen der Häkchen aller Checkboxen mittels #PB_All (-1).

Code: Alles auswählen

If OpenWindow(0, 100, 100, 300, 300, "ListIcon Example", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
	ListIconGadget(0, 5, 5, 290, 190, "Name", 100, #PB_ListIcon_FullRowSelect|#PB_ListIcon_AlwaysShowSelection|#PB_ListIcon_CheckBoxes)
	AddGadgetColumn(0, 1, "Address", 150)
	For i=0 To 8
		AddGadgetItem(0, -1, "Ginger Brokeit"+Chr(10)+"130 PureBasic Road")
	Next
	ButtonGadget(1, 5, 200, 100, 25, "Check all")
	
	Repeat
		Event = WaitWindowEvent()
		Select Event
			Case #PB_Event_Gadget
				Select EventGadget()
					Case 1
						SetGadgetItemState(0, #PB_All, #PB_ListIcon_Checked)
				EndSelect
		EndSelect
	Until Event = #PB_Event_CloseWindow
EndIf
Das ListViewGadget unterstützt auch, mit einem Aufruf, das Markieren aller Items mittels #PB_All (-1).

Code: Alles auswählen

If OpenWindow(0, 100, 100, 300, 300, "ListIcon Example", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
	ListViewGadget(0, 5, 5, 290, 190, #PB_ListView_MultiSelect)
	AddGadgetColumn(0, 1, "Address", 150)
	For i=0 To 8
		AddGadgetItem(0, -1, "Ginger Brokeit"+Chr(10)+"130 PureBasic Road")
	Next
	ButtonGadget(1, 5, 200, 100, 25, "Check all")
	
	Repeat
		Event = WaitWindowEvent()
		Select Event
			Case #PB_Event_Gadget
				Select EventGadget()
					Case 1
						SetGadgetItemState(0, #PB_All, 1)
				EndSelect
		EndSelect
	Until Event = #PB_Event_CloseWindow
EndIf
Schließlich unterstützt das die upgestreamte API-Funktion ja auch. Das sollte man vielleicht in der Hilfe mit angeben... <)

Edit: Code etwas verkleinert.

Re: Schreibfehler, andere offensichtliche Fehler in der PB-H

Verfasst: 25.08.2016 19:32
von ts-soft
Rudi hat geschrieben:Das ListIconGadget unterstützt auch, mit einem Aufruf, das setzen der Häkchen aller Checkboxen mittels #PB_All (-1).
Dies ist aber kein unterstütztes Feature. Man könnte lediglich erwähnen, das es von der WinAPI zur Zeit so interpretiert wird. Unter Linux
kann ich keine Veränderung feststellen!

Re: Schreibfehler, andere offensichtliche Fehler in der PB-H

Verfasst: 25.08.2016 23:13
von Rudi
Oh je, an was man da alles denken muss... :(

Aber noch was Anderes: Die Funktionseinträge im Referenz-Handbuch sind ja schon recht umfangreich. Darum möchte ich anregen, die "3D Spiele & Multimedia Libraries" in ein separates Unterverzeichnis zu verschieben, um sich besser zurechtfinden zu können. Das sind ja immerhin schon diese: Billboard, Camera, Engine3D, EntityAnimation, Gadget3D, Joint, Light, Material, Mesh, Node, NodeAnimation, Particle, Screen, Sound3D, SpecialEffect, Spline, Sprite, StaticGeometry, Terrain, Text3D, Texture, VertexAnimation und Window3D.

Wie lautet die zustimmende Antwort? :)

Re: Schreibfehler, andere offensichtliche Fehler in der PB-H

Verfasst: 30.10.2016 17:59
von Kurzer
Hallo,

mir fällt gerade auf, dass man unter der Hilfe zu BindEvent() noch etwas zufügen sollte.
Momentan steht dort als Beschreibung des optionalen Parameters "Objekt" folgendes:

Code: Alles auswählen

Objekt (optional) Die Objekt-Nummer, mit der das Ereignis verknüpft werden soll. Dies kann ein Gadget, ein Menüeintrag oder eine Systray Statusleisten-Nummer sein. #PB_All kann verwendet werden, um das Ereignis mit allen Objekten zu verknüpfen (falls angegeben, muß der 'EventType' Parameter ebenso als #PB_All gesetzt werden).  
Man kann dort noch hinzufügen, dass im Falle des Events #PB_Event_Timer damit die Nummer des Timers angegeben wird.

Gruß Kurzer

Re: Schreibfehler, andere offensichtliche Fehler in der PB-H

Verfasst: 06.06.2017 00:16
von Kurzer
Ist in der Hilfe irgendwo erklärt, dass man bei einer IF Bedingung auch ohne Vergleichsoperator arbeiten kann, die Wahr/Falsch Logik dann aber nicht so arbeitet wie im Bereich des "If" Befehls erklärt (bzw. einem die Konstanten #True und False vorgaukeln)?

Es wird ja z.B. oft folgendes geschrieben (also ohne "<> 0" bzw. "<> #False"):

Code: Alles auswählen

If CreateImage(...)
  Debug "CreateImage() war erfolgreich"
  ; Mach was mit dem Image
Endif
Hier gibt CreateImage entweder 0 zurück, wenn etwas schief gelaufen ist (If Block wird nicht ausgeführt) oder eine Objektnummer <> 0 (If Block wird ausgeführt).
Wird kein Vergleichsoperator (< = > ! usw) benutzt, dann wird bei obigem If Befehl also alles was nicht 0 ist als "wahr" interpretiert.

Kann man hiermit auch kurz gegenprüfen:

Code: Alles auswählen

Debug #False
Debug #True

If 4861233
	Debug "0: 4861233 ist wahr"
EndIf

If 300
	Debug "1: 300 ist wahr"
EndIf

If 0
	Debug "2: 0 ist wahr"
Else	
	Debug "2: 0 muss daher falsch sein"
EndIf

If 300 = #True
	Debug "3: 300 ist wahr"
EndIf

If 300 = #False
	Debug "4: 300 ist falsch"
EndIf

If 0 = #False
	Debug "5: 0 ist falsch"
EndIf
Heraus kommt dabei:

Code: Alles auswählen

[Debug] 0
[Debug] 1
[Debug] 0: 4861233 ist wahr
[Debug] 1: 300 ist wahr
[Debug] 2: 0 muss daher falsch sein
[Debug] 5: 0 ist falsch
Die Beschreibung des IF Befehls sagt folgendes dazu:
Die If Struktur wird zu Testzwecken benutzt und/oder um die Richtung der weiteren Programmausführung zu ändern - abhängig davon, ob der Test 'wahr' oder 'falsch' ergibt.

Lt. Konstantendefinition ist #False = 0 und #True = 1, weshalb in dem obigen Code "If 300 = #True" auch nicht ausgeführt wird - wohl aber "If 300" als #True bzw. "nicht #False" interpretiert wird.

Arbeitet nun der IF Befehl absichtlich "unschärfer", um solche netten Sachen wie "If CreateImage()" schreiben zu können oder ist die Definition von #True nicht korrekt, weil es eigentlich nicht mit "1" definiert sein dürfte, sondern mit der Menge aller Zahlen <> 0 ?

Ich selbst mache mir da ja keine Gedanken mehr drüber und benutzte das alles einfach so. Jetzt bin ich aber dabei Jemand anderem PureBasic zu erklären und werde an genau diesem Punkt konkret auf "Unstimmigkeiten" aufmerksam gemacht. :-) Leider finde ich nichts Zufriedenstellendes in der Anleitung dazu, was das "#True/#False/If Phänomen" eindeutig erklären würde.

Habe ich nur was übersehen?

Gruß Kurzer

Re: Schreibfehler, andere offensichtliche Fehler in der PB-H

Verfasst: 06.06.2017 17:04
von Nino
Kurzer hat geschrieben:Habe ich nur was übersehen?
Hi,

ich habe nicht den Eindruck, dass Du hier etwas übersehen hast. :-)

Rein logisch kann/sollte man in diesem Zusammenhang 2 verschiedene Situationen unterscheiden:
  1. Prüfung auf True/False:
    ... mit If, While usw. Hier wird nur 0 als False interpretiert, und alles <> 0 als True (so wie Du es auch geschrieben hast).
  2. Zuweisung der Werte True/False zu Variablen oder benannten Konstanten:
    Hier wird für False der Wert 0 verwendet (Das ist logisch konsistent zu a.) und für True der Wert 1 (Das ist nur ein Wert <> 0 von vielen möglichen. Daher ist dies nicht vollständig logisch konsistent zu a.)
Letztlich resultiert das Problem daraus, dass PureBasic (ebenso wie alle anderen Basic-Dialekte die ich kenne) keinen eigenen Datentyp "Bool" hat, sondern zwei Werte des Integer-Datentyps quasi für diesen Zweck missbraucht. Und das gelingt eben nicht absolut logisch sauber.

Diese Situation hat in der Vergangenheit schon öfter für Probleme und Verwirrung gesorgt. In PowerBasic wurden aus diesem Grund bereits vor längerer Zeit zwei Funktionen namens IsTrue() und IsFalse() eingeführt. Als PB-Macro sehen diese etwa so aus:

Code: Alles auswählen

Macro IsTrue(x)
   Bool(x <> 0)
EndMacro

Macro IsFalse(x)
   Bool(x = 0)
EndMacro


;-- Demo
If IsTrue(0)
   Debug "True"
EndIf
If IsTrue(1)
   Debug "True"
EndIf
If IsTrue(2)
   Debug "True"
EndIf

Debug "-------"

If IsFalse(0)
   Debug "False"
EndIf
If IsFalse(1)
   Debug "False"
EndIf
If IsFalse(2)
   Debug "False"
EndIf
Ich denke wenn Dein/e Schüler/in "logisch sauber lesbaren" Code schreiben will, sollte er/sie entweder immer den vollständigen Vergleich hinschreiben, z.B.

Code: Alles auswählen

If x <> 0
oder die o.g. Makros verwenden (die letztlich das gleiche machen) oder PureBasics eingebaute Funftion Bool() direkt verwenden, z.B.:

Code: Alles auswählen

If Bool(x)

If Not Bool(x)
Ich meine auch dass dieses Thema in der PB-Dokumentation behandelt werden sollte, gerade für Anfänger.

Re: Schreibfehler, andere offensichtliche Fehler in der PB-H

Verfasst: 06.06.2017 21:55
von GPI
Ist irgendwie witzig, wenn man feststellt, dass man das ganze eher unbewusst richtig macht. Wobei ich da wohl eher das Glück hatte, das meine Basic-Varianten vor Purebasic (Omicron-Basic auf den Atari ST) eben keine Konstanten kannten :)
Ist meines Wissens nach auch in vielen anderen Sprachen so, das alles ungleich Null als "wahr" angesehen wird. Dementsprechend schreibt man nicht "IF blabla=#true" sondern nur "if Blabla". Die Konstante #True sollte man nur zur Zuweisung benutzen, damit es erkenntlich ist, das man hier was binär setzt (und nicht später fragt, warum man ausgerechnet hier eine 1 setzt). Zum Vergleich taugt sie nicht. #False wiederum kann man immer verwenden.

Achja, wie war das noch, will man Strings überprüfen (ob leer, ob gefüllt), sollte man immer a$="" bzw. a$<>"" schreiben.

Übrigens kenn ich das so, das viele Programmiersprachen -1 (also das binärische Negativ von 0) als #True definieren. Man sollte hier auch nicht ein "NOT" mit den binärischen Operator ~ verwechseln. Weil ein "~1" ergibt nicht 0, ein "not 1" müsste 0 ergeben. Ist auch einer der Gründe, warum es die Compilerfunktion "Bool()" gibt.

Re: Schreibfehler, andere offensichtliche Fehler in der PB-H

Verfasst: 08.06.2017 13:20
von Nino
GPI hat geschrieben:Die Konstante #True sollte man nur zur Zuweisung benutzen, damit es erkenntlich ist, das man hier was binär setzt (und nicht später fragt, warum man ausgerechnet hier eine 1 setzt). Zum Vergleich taugt sie nicht. #False wiederum kann man immer verwenden.
Schön auf den Punkt gebracht. :allright: Ich finde, so in etwa sollte es in der Hilfe stehen.

Re: Schreibfehler, andere offensichtliche Fehler in der PB-H

Verfasst: 07.10.2020 19:54
von Nino
Die Erklärung, wie Kurzschlussauswertungen funktionieren, ist falsch -- sowohl in der deutschen als auch in der englischen Hilfe.

Ich erläutere das hier anhand der deutschen Hilfe. Dort steht (rote Schriftfarbe von mir):
"Kurzschluss"-Auswertungen (englisch "short-circuit evaluations") für Ausdrücke werden unterstützt - was bedeutet, dass 'wenn' ein Test 'wahr' ist, alle danach folgenden Tests ignoriert und nicht einmal ablaufen werden.
Nein, das bedeutet es nicht generell, sondern das gilt nur für Verknüpfungen mit Or.

Kurzschlussauswertung bedeutet, dass
  • wenn mehrere Ausdrücke jeweils mit Or verknüpft sind, die Auswertung abgebrochen wird sobald ein Ausdruck 'wahr' ist (weil dann bereits feststeht, dass der Gesamtausdruck nicht mehr den Wert 'falsch' annehmen kann).
  • wenn mehrere Ausdrücke jeweils mit And verknüpft sind, die Auswertung abgebrochen wird sobald ein Ausdruck 'falsch' ist (weil dann bereits feststeht, dass der Gesamtausdruck nicht mehr den Wert 'wahr' annehmen kann).