OpenFile Bug?

[Kaeru Gaman]

hey, leute...

es geht hier um OpenFile(), nich um sonstwas für scherze,
und ich gehe davon aus das die frage ernstgemeint war.

[Thorium]

Also der Bug ist nicht reproduzierbar. Da scheint einfach was in PureBasic durcheinandergeraten zu sein. Der Bug von gestern Abend ist heute bei gleichem Source nicht mehr aufgetreten. Hät ich eigentlich auch schon gestern ausprobieren können, PureBasic einfach neustarten.

Naja für die Akten: Problem trat bei jedem zweiten Aufruf von OpenFile() mit gleichen Parametern auf. #PB_Any habe ich nicht verwendet.

[Kaeru Gaman]

> Problem trat bei jedem zweiten Aufruf von OpenFile() mit gleichen Parametern auf.

war das File noch offen?
also, war evtl dein system verlangsamt durch einen anderen dienst,
sodass dein prog erneut zu öffnen versucht hat,
bevor das OS das File als geschlossen registrieren konnte?

[Thorium]

> Problem trat bei jedem zweiten Aufruf von OpenFile() mit gleichen Parametern auf.

war das File noch offen?
also, war evtl dein system verlangsamt durch einen anderen dienst,
sodass dein prog erneut zu öffnen versucht hat,
bevor das OS das File als geschlossen registrieren konnte?

Eigentlich nicht, es liefen genau die Dienste und Prozesse wie heute. Zumal das Öffnen ja funktioniert hat. Heißt ich bekomme 0 zurückgeliefert, kann aber aus der Datei lesen und auch in die Datei schreiben bis ich sie wieder schließe.

[Kaeru Gaman]

ja, das ist insgesamt sehr merkwürdig.

mit "open readonly" und "not yet closed" habe ich eigentlich die möglichen logischen erklärungen für dieses phänomen erschöpft.

PS:
bei "open readonly" kann das file geöffnet werden, aber erlaubt keinen vollzugriff.
deswegen offen aber fehler.

bei "not yet closed" hängt das system minimal hinterher,
die erste anfrage ergibt ein "bereits geöffnet",
aber da das file eigentlich doch schon geschlossen ist,
funktioniert es trotzdem.

[#NULL]

Bei #PB_Any wird der benötigte Speicher für die GadgetStructure extra allociert, der zurückgegebene Pointer dürfte also niemals auf 0 verweisen
Ich hoffe das hast auch Du jetzt verstanden

wenn du dir sicher bist, dass eine funktion mit #PB_ANY niemals 0 zurückgibt.. kann ja sein, aber diese begründung dafür leuchtet mir nicht ein.
wenn du -1 / PB_ANY als PB-ID benutzt, wird ja kein (System-)handle, sondern die PB-ID zurückgegeben, und die stellt doch keinen pointer dar. warum sollte sie also nicht 0 sein können?

[ts-soft]

@#Null
Hier der Beweis, obwohl ich bezweifle, das Du es verstehst

Auf jedenfall kann ein Pointer niemals 0 sein, also in diesem Falle auch nicht

Code: Alles auswählen

; Structure laut PB Library SDK
Structure PB_GadgetStructure
  Gadget.l
  *VT.l
  UserData.l
  OldCallback.l
  Data.l[4]
EndStructure

Define.PB_GadgetStructure *Button

If OpenWindow(0, #PB_Ignore, 0, 100, 100, "")
  If CreateGadgetList(WindowID(0))
    *Button = ButtonGadget(#PB_Any, 10, 10, 60, 30, "")
  EndIf 
EndIf

Debug "PBID für Button: " + Str(*Button)

Debug "hWnd = " + Str(GadgetID(*Button))

Debug "Über Strukture:"
Debug "hWnd = " + Str(*Button\Gadget)

While Not WaitWindowEvent() = #PB_Event_CloseWindow : Wend 

[MVXA]

Wenn man an eine Create Funktion #PB_Any übergibt, bekommt man
natürlich ein Pointer zurück o_O.

[#NULL]

der aufruf einer create-funktion mit #PB_ANY gibt also einen zeiger auf eine (pb-interne?) struktur zurück, welche unter anderem das OS-handle enthält. dieser pointer ist die PB-ID.

wenn ich die PB-ID selbst bestimme, durch angabe einer konstante, ist diese PB-ID doch aber kein pointer, sondern irgendeine 'nummer', die keinen speicher addressiert, denn die 'nummer' kann ja auch 0 sein, bzw objekte verschiedenen typs (gadget oder sound) können ja auch dieselbe 'nummer' haben.

[bis jetzt alles richtig?]

dann wären PB-IDs ja manchmal speicheradressen und manchmal nicht.
wie weiß denn eine funktion wie z.b. GadgetID(GadgetNr) ob der parameter als pointer oder als Nr zu handhaben ist. einfach nur anhand der größe seines wertes?

[das ein gültiger pointer niemals 0 sein kann, ist mir klar. nur ich dachte bisher PB-IDs seien niemals pointer]

vielleicht verweist ja auch einfach eine meiner synapsen auf 0. wäre nett wenn ihr trotzdem noch versucht mir die richtige addresse zu zeigen

[ts-soft]

Anhand der größe ist richtig. Mehr als 10000 Gadgets sind nicht möglich, also
können die mit Konstanten erstellten Gadgets, nur von 0 - 9999 sein, was
niemals mit einer Speicheradresse kollidieren sollte. Für alle so erzeugten
Gadgets wird der Speicher automatisch erzeugt, 0 bis größte Konstante *
benötigter Speicher, deshalb ist es wichtig, das die Nummern keine Lücken
aufweisen und bei 0 anfangen, um unnötigen Speicherverbrauch zu
vermeiden.