Ich arbeite mit einer Windows-Anwendung in Smalltalk 3.1 entwickelt, und hier ist etwas wirklich komisches, das ich gerade gefunden habe und ich bin mir nicht sicher, wie viele Details ich enthalten sollte, also werde ich versuchen, eine Konversation mit der Hauptszenario:Smalltalk Windows-Anwendung arbeitet im Debug-Modus; .exe hängt
Das Programm öffnet ein Projekt von einer Remote-Maschine, wodurch die Schnittstelle für eine lange Zeit (~ 10 Minuten) hängen bleibt, bevor sie wieder reagiert.
Jetzt, wenn ich das Programm aus Smalltalk starten und self halt. nur irgendwo in der Nähe der relevanten Operationen hinzufügen, die sich mit dem Öffnen eines Projekts befassen, tritt das Problem nicht auf. Wenn ich jetzt keine Haltepunkte hinzufüge und sie von Smalltalk aus starte, taucht das Problem wieder auf.
Ich frage mich, ob das in Smalltalk-Apps üblich ist, da ich nicht viel über die Sprache weiß.
Sind Sie diese „Tests“ aus dem gleichen Entwicklungs Bild laufen? Wenn Sie den Halt hinzufügen und dann entfernen, besteht das Problem weiterhin? –
Auf was für "Smalltalk" beziehen Sie sich? Squeak, Pharo, Delphin, VisualWorks, VisualAge ...? Und wie startet man das Programm? Klicken Sie auf einen Knopf oder bewerten Sie den Code? Im letzteren Fall könnten Sie versuchen, den Code mit einer niedrigeren Priorität (Squeak/Pharo-Dialekt) zu betreiben: '[] forkAt: Prozessor userBackgroundPriority'. Wenn die "Nicht-Reaktion" auf etwas zurückzuführen ist, das den UI-Prozess blockiert, sollte dies helfen. –
Ja, alle Tests befinden sich im selben Dev-Image, und das Problem kommt zurück, wenn ich den 'Halt' hinzufüge und ihn dann entferne. Es ist einer der Visual SmallTalks, nicht sicher welcher wirklich! Sieht jedoch nicht wie VisualWorks aus ... 'RqReqBrowserDlg reinitializeChoices. "mpwAdded" Selbsthalt. App explorerPane initItems; redisplay.' Das ist der Teil des Codes, wo die Magie passiert. Die Interface-Elemente werden angezeigt, nachdem 'initItems' auswertet und dann hängt -nicht so mit diesem Halt darin. – carlsLobato