Seite 1 von 1

Schon wieder Strings

Verfasst: 09.04.2009 12:09
von Josef Sniatecki
Bin mir nicht sicher ob man das als Bug oder Fehler von mir anerkennen
kann. Jedoch bin ich mir sicher, dass man wenigstens in der Hilfe darauf
hinweisen soll:

Code: Alles auswählen

Procedure.i CallError()
  Protected Title.String,Text.String,Flags.i
  
  MessageRequester(Title\S,Text\S,Flags)
EndProcedure

CallError()
Ist nur ein Beispiel

Dieser Code öffnet mir eine MessageBox mit dem Titel "Fehler". Doch wieso? Wenn ich "Debug Title\S" eingebe, so wird mir ein Leerer
String ausgegeben.

Kann es etwa damit zusammenhängen, dass Strings als Protected am
Anfang immer auf eine Zeichenkette mit der Adresse NULL zeigen?
Wobei ich mir das kaum vorstellen kann, da doch PureBasic kein
"Call-By-Reference" erlaubt, oder?

Könnt ihr dieses ungewöhnliche Verhalten von PureBasic bestätigen?
Danke im Voraus

Gruß Josef

Verfasst: 09.04.2009 12:19
von STARGÅTE
jo bestätigt,

liegt aber daran, das Windows keine "echt leeren" Fenstertitel haben will, denn wenn ich beide Variablen tausche, erhalte ich das selbe.

leite ich sie vorher mit Defaultwerten ein (was sowieso ratsam ist)
erhalte ich leere Fenster:

Fehler steht nur im Titel

Code: Alles auswählen

Procedure.i CallError() 
  Protected Title.String,Text.String,Flags.i 
  
  MessageRequester(Title\S,Title\S,Flags) 
EndProcedure
CallError()
leeres:

Code: Alles auswählen

Procedure.i CallError() 
  Protected Title.String\s="",Text.String\s="",Flags.i 
  
  MessageRequester(Title\S,Title\S,Flags) 
EndProcedure 

CallError()

Verfasst: 09.04.2009 13:03
von Josef Sniatecki
Danke Stargate.

Die Methode mit den Defaultwerten war mir bewusst, jedoch nicht, dass
Windows "leere" Strings für den Titel nicht mag. :mrgreen:

Nun bleibt die Frage, ob es sich lohnt, auf dieses Problem in der Hilfe zu
verweisen. Am besten auf der Seite des MessageRequesters oder gleich
allgemeiner: bei Strings.

Ansonsten ist ja das Problem geklärt - Also für mich auf jeden fall.

Verfasst: 09.04.2009 13:08
von Kaeru Gaman
ein leerer String ist für mich ein valider pointer der auf einen terminator zeigt.

SG, mit "echt leerer String" meinst du dann wohl einen "void pointer",
also pointer existent zeigt aber auf nichts, nicht einmal auf etwas leeres.

JS, genau das tust du hier, du erzeugst nur einen pointer,
richtest ihn aber nicht auf einen gültigen speicherbereich der einen leeren string enthält.

dass es Probleme bereitet, ein Objekt mit einer inexistenten Property zu erzeugen, hört sich nachvollziehbar an.

also, das ist ein Bedienfehler, kein Bug, nicht in PB und nicht im OS.

... wird später verschoben ... nach Allgemein?

Verfasst: 09.04.2009 14:52
von STARGÅTE
dieses Problem gibs aber auch noch bei DrawText wenn man eine Variablen verwendet, die nicht "inizialisiert" ist.

zumindest habe ich früher daduch öffters mal n IMA bekommen, weil ich
DrawText(x,y,Text$)
geschrieben habe ohne das Text$ zuvor inhalt hatte.

@KG, keine Ahnung was ich das meine was du denkst was ich meinen könnte, aber ich kenne mich mit den "Fachbegriffen" nicht so ganz aus ... :oops:

Verfasst: 09.04.2009 16:33
von Kaeru Gaman
also wenn
DrawText(x,y,Text$)
einen IMA verursachte, wäre das ein Bug, denn per Definition können Variablen on-the-fly deklariert werden.
Text$ ist hier eine Variable, und wenn undefiniert,
müßte sie on-the-fly auf einen gültigen pointer auf einen leeren string initialisiert werden.

wenn man aber nur einen pointer benennt, sei er nun strukturiert (einem Typ zugeordnet) oder nicht,
zeigt der nicht auf eine gültige Variable (egal ob leer oder besetzt),
solange man das nicht ausdrücklich tut, also ihn auf einen speicherbereich zeigen läßt wo zumindest ein string-ende-zeichen drin ist.
dass das nicht funktionieren kann ist einleuchtend.