@real
bei mir tritt der Fehler im Grunde immer auf, aber halt manchmal lassen sich beide MR bewegen und drücken. OHNE CODEANDERUNG wie du so schön schreibst, war aber erst 2 oder 3 mal der Fall. Hangt wohl vom Timing ab.
Und auch wenn es das Programm stoppen sollte, dann müßte doch der zuerst aufgerufene MR auch als erstes wieder "beendet" werden. Aber es kann immer nur der zu letzt aufgerufene bestätigt werden und da kann es schon mal passieren (je nach Programm) das bevor man klicken kann, ständig neue positioniert werden. Schön das du dieses Verhalten auch nachvollziehen konntest. Na ja, besser wäre es, wenn es nicht so wäre
@Kaeru Gaman
Das ist doch Quatsch. Funktionen sind dazu da aufgerufen zu werden, wo auch immer. Das hangt nun mal von dem ab was der Programmierer will. Und wenn man unabhängige Threads erstellt die verschiedene Programmteile abarbeiten, so kann es doch ganz logischer WEise dazu kommen, das man durch diese Threads auch eine Bildschirmausgabe bzw. Eingabe durchführen lassen will. Und dazu sind doch die Messagerequester da. Siehe auch meinen TExt zu ts-soft. Außerdem ist dies doch nur ein gekürztes Beispiel gewesen. Das tritt auch auf, wenn man den Messagerequester in unterschiedlichen Proceduren nutzt.
@ts-soft
Deine Aussage, das die Verwendung falsch ist, ist falsch. Mehr auch nicht. Die einzige Aussage die du nutzen könntest ist "Ich sehe für mich keine sinnvolle Verwendung...". Und wie kommst du darauf das es egal ist, das er unterschiedlich reagiert. Du bist wohl zu sehr an Microsoft gewöhnt
Verwenden kann man das an unterschiedlichsten stellen, die bei mir am meißten vorhandene Variante ich sind die eigenen Errorsubroutinen. Allociere ich z.B. einen SPeicherbereich, so geschieht das über eine Subroutine, tritt hier ein fehler auf, so kommt eine Requester. Diese Allocierungsroutine, wie auch die Errorroutine sind natürlich für alle Threads da. Bei anderen Fehler natürlich auch. Will man nun den Fehler rausfinden, kann ich nicht jeden Thread einzeln ausschließen, da alle Requester geblockt werden. Ich muß zwangsweise den mir angebotenen zuerst "freigeben".
@all
Alleine die Hilfe ist schon schwammig und das ist ja das Problem. Entweder die Hilfe ist nicht korrekt oder der MessageRequester buggy.
MessageRequester soll die Programmausführung anhalten. DAS MACHT ER NICHT. wird der MessageRequester aufgerufen, läuft das Programm normal weiter. ALLE anderen Thread werden nicht beeinflußt. den Process zu stoppen bzw. das Programm, dazu kann es also nicht dienen. Dient es dazu den Thread zu stoppen, dann stimmt das, aber dann dürfte der MR nicht die Threads gegenseitig blocken die den MR nutzen, aber nicht die anderen. Und dann macht er das auch noch nach Lust und Laune.Real hat das ja auch festgestellt. Zwar block er "fast immer", manchmal aber nicht. Die Hilfe erklärt das Verhalten nicht annähernd.
Also damit es klar ist, ich bin nicht davon überzeugt, das der Messagerequester buggy ist. Vielleicht muß er sich auch so verhalten. Vielleicht ist das das selbe Verhalten wie "die normale Messagebox", ich kannte bisher das interne Verhalten noch zu wenig (teste gerade), aber dann ist in der Hilfe die Erklärung nicht korrekt bzw. sehr schwammig. Eines von Beiden stimmt nicht: Die Erklärung in der Hilfe oder das Verhalten des MR.
Aber die MR verhält sich anders als die MB (mit WindowsID, vorausgesetzt ich da da keinen Fehler gemacht). Die MB block sich nicht gegenseitig.
Code: Alles auswählen
Global mh.l
Procedure repeat_(message.s)
Repeat
Delay(1000)
Debug "1"
ForEver
EndProcedure
Procedure Message(message.s)
MessageRequester("Message",message)
EndProcedure
Procedure Messagebx(message.s)
t.s = "ZickeZacke"
MessageBox_(WindowID(mh) , @message, @t, 0)
EndProcedure
mh = OpenWindow(#PB_Any,0,0,200,200,"Test",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)
Debug WindowID(mh)
CreateThread(@repeat_(),"")
Delay(4000)
If 1 ;0
CreateThread(@Messagebx(),"Thread3 MB")
CreateThread(@Messagebx(),"Thread4 MB")
CreateThread(@Messagebx(),"Thread5 MB")
CreateThread(@Messagebx(),"Thread6 MB")
Else
CreateThread(@Message(),"Thread1 MR")
CreateThread(@Message(),"Thread2 MR")
CreateThread(@Message(),"Thread3 MR")
EndIf
Test ruhig mal. Die MB block nicht, der MR schon. ABER egal ob ich nun die MB vielleicht falsch erstellt habe (falsches handle), die MR macht nicht, was in der Hilfe steht. Das PRogramm läuft weiter, nur die "MR-Threads" blocken sich (fast immer) gegenseitig.
Also aus meiner Sicht stimmt da auf jeden Fall was nicht. Ob es die Erklärung in der Hilfe ist, kann uns nur das PB-Team sagen.
1. Win10
PB6.1
