ungültiger Speicherzugriff bei waitwindowevent() auf macosx
ungültiger Speicherzugriff bei waitwindowevent() auf macosx
was kann das sein? unter linux und windows habe ich das Problem nicht?
gibt es auser der Threadeinschränkung weitere???
"Hinweise:
Eine Fenster-Ereignisschleife sollte nicht in einem Thread verarbeitet werden, da es auf OS X und Linux einige Einschränkungen gibt. Ein Debugger-Fehler wird ausgelöst."
screenshot gibts auch noch:
https://picasaweb.google.com/1074480736 ... 9529532002
gibt es auser der Threadeinschränkung weitere???
"Hinweise:
Eine Fenster-Ereignisschleife sollte nicht in einem Thread verarbeitet werden, da es auf OS X und Linux einige Einschränkungen gibt. Ein Debugger-Fehler wird ausgelöst."
screenshot gibts auch noch:
https://picasaweb.google.com/1074480736 ... 9529532002
Re: ungültiger Speicherzugriff bei waitwindowevent() auf mac
Schalte mal den Purifier ein, u.U. schreibst du irgendwo illegal in einen Speicherbereich und "zerstörst" dabei den Puffer von (Wait-)WindowEvent()
Ansonsten wäre ein reproduzierbarer kleiner Code von nöten, nur durch den Screen kann man nicht helfen.
Ansonsten wäre ein reproduzierbarer kleiner Code von nöten, nur durch den Screen kann man nicht helfen.
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Re: ungültiger Speicherzugriff bei waitwindowevent() auf mac
was muss ich mit dem Purifier machen? hab ihn noch nie sinnvoll genutzt?STARGÅTE hat geschrieben:Schalte mal den Purifier ein, u.U. schreibst du irgendwo illegal in einen Speicherbereich und "zerstörst" dabei den Puffer von (Wait-)WindowEvent()
Ansonsten wäre ein reproduzierbarer kleiner Code von nöten, nur durch den Screen kann man nicht helfen.
Re: ungültiger Speicherzugriff bei waitwindowevent() auf mac
nur (unter Compilieroptionen) so wie den Debugger anschalten.
Dieser meldet dann, wenn du irgendwo illegal über einen Speicher hinausschreibst oder ein String "kaputt" ist, sowas halt.
Dieses Beispiel funktioniert zB ohne Probleme (richtiges Ergebnis, kein fehler vom Debugger), aber der Purifier wird aufschreien, weil du in einen Bereich schreibst, der dir nicht gehört, was zu einem später auftauchenden Fehler in einer anderen Funktion führen kann.
Dieser meldet dann, wenn du irgendwo illegal über einen Speicher hinausschreibst oder ein String "kaputt" ist, sowas halt.
Dieses Beispiel funktioniert zB ohne Probleme (richtiges Ergebnis, kein fehler vom Debugger), aber der Purifier wird aufschreien, weil du in einen Bereich schreibst, der dir nicht gehört, was zu einem später auftauchenden Fehler in einer anderen Funktion führen kann.
Code: Alles auswählen
*Buffer = AllocateMemory(100)
PokeL(*Buffer+100, 123)
Debug PeekL(*Buffer+100)
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Re: ungültiger Speicherzugriff bei waitwindowevent() auf mac
ich danke dir vielmals jetzt hab ichs kapiert, werdes testen evt. kann ich damit den fehler schon aufindig machenSTARGÅTE hat geschrieben:nur (unter Compilieroptionen) so wie den Debugger anschalten.
Dieser meldet dann, wenn du irgendwo illegal über einen Speicher hinausschreibst oder ein String "kaputt" ist, sowas halt.
Dieses Beispiel funktioniert zB ohne Probleme (richtiges Ergebnis, kein fehler vom Debugger), aber der Purifier wird aufschreien, weil du in einen Bereich schreibst, der dir nicht gehört, was zu einem später auftauchenden Fehler in einer anderen Funktion führen kann.Code: Alles auswählen
*Buffer = AllocateMemory(100) PokeL(*Buffer+100, 123) Debug PeekL(*Buffer+100)
Re: ungültiger Speicherzugriff bei waitwindowevent() auf mac
der Purifier hat leider nichts gemeldet, aber hinter dem event waren nicht altzuviele funktionen, so konnten wir stück für stück probieren... das Problem lag bei einem HyperLinkGadget und dem darauf folgenden setgadgetcolor()Rothammel hat geschrieben:ich danke dir vielmals jetzt hab ichs kapiert, werdes testen evt. kann ich damit den fehler schon aufindig machenSTARGÅTE hat geschrieben:nur (unter Compilieroptionen) so wie den Debugger anschalten.
Dieser meldet dann, wenn du irgendwo illegal über einen Speicher hinausschreibst oder ein String "kaputt" ist, sowas halt.
Dieses Beispiel funktioniert zB ohne Probleme (richtiges Ergebnis, kein fehler vom Debugger), aber der Purifier wird aufschreien, weil du in einen Bereich schreibst, der dir nicht gehört, was zu einem später auftauchenden Fehler in einer anderen Funktion führen kann.Code: Alles auswählen
*Buffer = AllocateMemory(100) PokeL(*Buffer+100, 123) Debug PeekL(*Buffer+100)
in der hilfe heist es dazu:
Dieses Gadget unterstützt die SetGadgetColor() und GetGadgetColor() Befehle mit dem #PB_Gadget_FrontColor Typ, um die Textfarbe zu ändern. Die Hintergrundfarbe ist immer die Farbe des Fensters.
Hinweis: SetGadgetColor() wird nicht auf der MacOS X Plattform unterstützt.
unter einer nicht unterstützung habe ich ein bischen was anderes verstanden... naja nun gehts, das is doch die hauptsache, also danke sternentor
Re: ungültiger Speicherzugriff bei waitwindowevent() auf mac
Dieser Hinweis gilt eigentlich nur für das Carbon-Framework (mit Subsystem Carbon)! Ab PB 5.00 ist das Cocoa-Framework standardmäßig voreingestellt. SetGadgetColor() sollte daher eigentlich funktionieren. Es scheint sich eindeutig um einen Bug zu handeln, denn ich erreichte mit dem folgenden Beispiel bei 20 Klicks auf "Kompilieren/Starten" 8 mal eine erfolgreiche Ausführung und 12 mal den Fehler "Ungültiger Speicherzugriff":Rothammel hat geschrieben:das Problem lag bei einem HyperLinkGadget und dem darauf folgenden setgadgetcolor()
in der hilfe heist es dazu:
Dieses Gadget unterstützt die SetGadgetColor() und GetGadgetColor() Befehle mit dem #PB_Gadget_FrontColor Typ, um die Textfarbe zu ändern. Die Hintergrundfarbe ist immer die Farbe des Fensters.
Hinweis: SetGadgetColor() wird nicht auf der MacOS X Plattform unterstützt.
Code: Alles auswählen
If OpenWindow(0, 270, 100, 200, 50, "HyperlinkGadget")
HyperLinkGadget(0, 10, 20, 250, 20, "Red HyperLink", $FF0000)
SetGadgetColor(0, #PB_Gadget_FrontColor, $0000FF)
Repeat
Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf
Ich habe übrigens auch bereits im englischen Unterforum "Bugs - Documentation" darauf aufmerksam gemacht, dass der Hinweis auf fehlende Unterstützung für SetGadgetColor() bei MacOS X nur auf das Subsystem Carbon zutrifft und Fred hat den Beitrag bereits mit einem [Done] markiert.
Re: ungültiger Speicherzugriff bei waitwindowevent() auf mac
Shardik hat geschrieben:Dieser Hinweis gilt eigentlich nur für das Carbon-Framework (mit Subsystem Carbon)! Ab PB 5.00 ist das Cocoa-Framework standardmäßig voreingestellt. SetGadgetColor() sollte daher eigentlich funktionieren. Es scheint sich eindeutig um einen Bug zu handeln, denn ich erreichte mit dem folgenden Beispiel bei 20 Klicks auf "Kompilieren/Starten" 8 mal eine erfolgreiche Ausführung und 12 mal den Fehler "Ungültiger Speicherzugriff":Rothammel hat geschrieben:das Problem lag bei einem HyperLinkGadget und dem darauf folgenden setgadgetcolor()
in der hilfe heist es dazu:
Dieses Gadget unterstützt die SetGadgetColor() und GetGadgetColor() Befehle mit dem #PB_Gadget_FrontColor Typ, um die Textfarbe zu ändern. Die Hintergrundfarbe ist immer die Farbe des Fensters.
Hinweis: SetGadgetColor() wird nicht auf der MacOS X Plattform unterstützt.Ich habe diesen Fehler bereits im englischen Forum in diesem Beitrag gemeldet.Code: Alles auswählen
If OpenWindow(0, 270, 100, 200, 50, "HyperlinkGadget") HyperLinkGadget(0, 10, 20, 250, 20, "Red HyperLink", $FF0000) SetGadgetColor(0, #PB_Gadget_FrontColor, $0000FF) Repeat Until WaitWindowEvent() = #PB_Event_CloseWindow EndIf
Ich habe übrigens auch bereits im englischen Unterforum "Bugs - Documentation" darauf aufmerksam gemacht, dass der Hinweis auf fehlende Unterstützung für SetGadgetColor() bei MacOS X nur auf das Subsystem Carbon zutrifft und Fred hat den Beitrag bereits mit einem [Done] markiert.
Danke für die Bugmeldung, habe selber kein macosx, konnte da selber also nicht viel rumprobieren. Wir mussten ungefähr 20mails schreiben ehe wir den Fehler beheben konnten...