Programm trotz Ziehen mit der Maus weiterlaufen lassen

[Jac de Lad]

Wie ist es, möglichst einfach, möglich, dass ein Programm trotz Anklicken und Ziehen mit der Maus im Fenster-Caption noch weiterläuft? Weiß das jemand?

[Frabbing]

Alle programmrelevanten Aktivitäten innerhalb eines Timerinterrupts, Subclassing, etc. durchführen. Noch besser wäre ein zweiter Thread, aber dafür ist dann wohl XPIA oder P2Cpp nötig. Liegt daran, was genau dein Programm machen soll.

[AHT]

Zitat von Jac de Lad

Wie ist es, möglichst einfach, möglich, dass ein Programm trotz Anklicken und Ziehen mit der Maus im Fenster-Caption noch weiterläuft? Weiß das jemand?

Einfach ist das gar nicht möglich, Profan ist nicht multithreadingfähig - das gleiche gilt für das Anklicken des Menüs.

[RGH]

Zitat von AHT

Einfach ist das gar nicht möglich, Profan ist nicht multithreadingfähig

Mit dem ab XProfan 11 möglichen SubClassing per SubClassProc sollte sich das schon recht einfach und sicher regeln lassen. Einfach mal das in der Hilfe vorhandene Beispielprogramm ausprobieren und entsprechend erweitern.

Gruß
Roland

[RGH]

... und hier ein kleines Beispiel! Die Uhr auf dem Bildschirm läuft auch weiter, während das Fenster per Maus in der Titelzeile verschoben wird:

$H Messages.ph
$H Windows.ph

'{
SubClassProc 
  If SubClassMessage(%hWnd, ~wm_sizing)
    SetStyle %hwnd, 1, GetStyle(%hwnd, 1) | $02000000
    Resize
    PaintScreen
    Set("WinProc", 0)
  ElseIf SubClassMessage(%hWnd, ~wm_timer)
    PaintScreen
    Set("WinProc", 0)
  ElseIf SubClassMessage(%hwnd, ~wm_close)
    SetMenuItem 3999
    Set("WinProc", 0)
  EndIf  
EndProc

Proc Resize
  SetWindowPos bt& = 0, 50 - Width(%HWnd)/2, Height(%HWnd) - 75
  SetWindowPos tb& = 0, 0 - 0,0; 0
EndProc

Proc PaintScreen
  locate 10,10
  print "Es ist jetzt " + time$(0) + ":" + left$(time$(1),2) + " Uhr"
EndProc

declare bt&, bt2&, st&, tb&
declare ende%

cls
tb& = create("Toolbar", %HWnd,0,15,1,1000,1)

SubClass %HWnd, 1 'SubClassing des Hauptfensters einschalten

whilenot ende%
  waitinput 100
  If %wmtimer
    PaintScreen
  ElseIf %Key = 4
    Resize
    SetStyle %hwnd, 1, GetStyle(%hwnd, 1) - $02000000
  ElseIf MenuItem(3999)
    Case Messagebox("Wollen Sie das Programm wirklich verlassen?","Frage",36) = 6 : Ende% = 1
  EndIf
endwhile  

' Subclassing wieder ausschalten
SubClass %HWnd, 0

end

Gruß
Roland

[Jac de Lad]

Nein, nein, nein, das ist mir doch alles bekannt. Es geht mir um das HAUPTPROGRAMM, welches nicht weiterläuft. Und ich finde es nicht sinnvoll, das in eine SubclassProc auszulagern oder per Timer laufen zu lassen, das klappt einfach nicht.

[AHT]

Zitat von Jac de Lad

Nein, nein, nein, das ist mir doch alles bekannt. Es geht mir um das HAUPTPROGRAMM, welches nicht weiterläuft. Und ich finde es nicht sinnvoll, das in eine SubclassProc auszulagern oder per Timer laufen zu lassen, das klappt einfach nicht.

Wie gesagt, Profan ist nicht multithreadingfähig.
Profan ist eine Sprache für Anwender, die Programme, die ständig laufen, nicht benötigen.

[Frabbing]

Profan ist nicht multithreadingfähig - das gleiche gilt für das Anklicken des Menüs.

Das geht wohl nur mit zweitem Thread. Mit dem XPIA-Uhren-Code kein Problem.

Es geht mir um das HAUPTPROGRAMM

Was genau wird dort denn gemacht?

[iF_]

@Jac: Im Grunde ist das was Du möchtest ganz einfach und das Thema hat mit Threads nicht wirklich etwas zu tun.

Das eigentliche Problem ist der (bei egal wie vielen Threads) erhebliche Mehraufwand.

Dein Hauptprogramm ist doch auch nur eine Funktion main().

Lagere doch Deine Ereigniserkennung aus, in eine Funktion welche den Hauptstrang höchstens "benachrichtig" für Operationen, die Du selbst deklarierst als "hier kann ruhig gewartet werden / bzw. hier muss gewartet werden".

Ich glaube ich mache das in so ziemlich allen Win32-GUI-XProfan-Anwendungen vor und hatte Dir hierzu auch schon einmal ein Beispiel "formuliert" - musst einfach stöbern.

Was genau soll denn passieren - oder eher die Frage: Was genau soll denn zu sehen sein?

@Roland: Die Uhr läuft (natürlich) nicht während der MessageBox. (Aber das Prinzip meine ich auch.)

@AHT:

Zitat von AHT

Profan ist eine Sprache für Anwender, die Programme, die ständig laufen, nicht benötigen.

Ich finde Du erzählst hier manchmal ganzschön viel Quatsch. Muss aber kein Thema werden, aber bei einzelnen Sachen erscheint mir immer die Anzahl der Jahre die notwendig sind damit Du manch eigene Aussage von selbst als "ei lustig - so hab ich damals gedacht" einschätzt. Du hast in vielen Dingen unrecht, glaub mal, also sei doch nicht so deklarativ.

Ausserdem hast Du Dich noch nicht mitgezählt [...] !

@Jac die 2.: Du auch nicht [...] ! Das Du Deinen alten Account deaktiviert hast ist hoffentlich nicht Problem der Aufgabe! (lol)

[AHT]

Hallo IF...

Vielleicht liegt es einfach daran, dass ich als Anwender nicht unbedingt das tue, was andere Anwender tun und man sich deshalb gegenseitig nicht versteht. Ich lache über viele Sachen, die ich so von mir gebe, bereits ein paar Minuten später - bin ja kein Experte und kein Lehrer und lerne jeden Augenblick dazu. Über viele Sachen, die du so von dir gibst, muss ich auch sehr oft lachen - meist merke ich dann aber, dass es nur deine (durchaus richtige) Sicht der Sache ist, du aber manche Sachen gar nicht sehen kannst, weil du dich nicht dafür interessierst und nichts damit zu tun hast und wahrscheinlich auch dein ganzes Leben lang nichts damit zu tun haben wirst.

Ich denke schon, dass es so ist, wie ich dass meine:
Profan ist eine Sprache für Anwender, also für Leute, die in der Regel nur kleine GUI-Anwendungen schreiben und von anderen Sachen nichts wissen wollen, die ab Vista aber immer wichtiger werden.
Kann gut sein, dass das eine Ansicht ist, über die man lachen kann - aber das ist nicht schlimm. Lachen hält gesund und verlängert das Leben.

[iF_]

Aber nein, das ist doch nicht richtig.

Programmiert ein Anwender ein noch so kleines Programm, so ist dieser nunmal der Programmierer und nicht der Anwender des Programmes - auch wenn er z.B. Bäcker, Tischler, oder PC-Anwender ist. Ein About "Angewandt von Max Bytebrüher" wäre sicher wenig einleuchtend.

Das Profan eine Sprache ist für Anwender, also für Leute, die in der Regel nur kleine GUI-Anwendungen schreiben, ist etwas anderes, als "Profan ist eine Sprache für Anwender, die Programme, die ständig laufen, nicht benötigen".

Da stimmt aber auch etwas anderes nicht - worum es mir eher ging, denn die Vermischung zwischen "Eigene-Threads-Fähigkeit" und "Sprache für Anwender" ist auch fachlich ziemlich unschlüssig und bringt in Betracht auf die von Jac gewünschten Ergebnisse auch keine Lösung.

Die Qualität eines Programmierers zeichnet sich nicht durch die Sprachen aus, in denen er programmiert. Gibt sogar Programmierer die können nur auf Papier (UML)! Aufzählen von Eigenschaften (einer Programmiersprache), welche eben nicht gegeben sind für eine Lösungfindung, ist wiederum das Laientheater von Anwendern - kaum von Programmierern, welche eben Lösungen erbringen oder eruieren im Bezug auf die Umgebung bzw. angewandte Sprache.

Ein Beispiel: Es gibt Doom für DOS und Windows - im DOS-Doom hatte niemand die Idee von mehreren Threads - und dennoch läuft scheinbar alles gleichzeitig. Das haben keine Zauberer programmiert, sondern Programmierer, welche sicherlich mindestens Anwender sind - mindestens von C.

Klar, Windows bietet praktische Threads - könnte man glauben. Tatsächlich ist daran kaum etwas praktisch, Threads sind eher eine Notlösung innerhalb (wenn es denn nötig ist) eines Prozesses scheinbar gleichzeitige Abläufe abzufahren z.B. wenn das Betriebssystem von Haus aus für z.B. bestimmte API's keine asynchone Variante anbietet oder wenn man manuell eine Mehrprozessorumgebung ausnutzen möchte.

Was jeder nachvollziehen kann: Versuch einmal 2 von 2 Threads organisierte bewegte Körper aufeinander reagieren zu lassen und einmal scheinbar/sichtbar selbes mit 1 Thread. Der notwendige Code (wg. "notwendig" auch ein Alias für "Effizienz") für das erste Beispiel ist spätestens aus Kernelsicht 3 Mal so aufwendig und die Synchonisierungsleistung des Programmiers stellt oft Barrieren dar welche sogar ins Philosophische abdriften. Alleine die Bitte um einen (zwei) scheinbar flimmerfreien Ball wird den ohnehin schon 3x grösseren Code verzehnfachen was den Ball wiederum aber nicht flimmerfrei werden liesse.

Im Kopf - klar: Gib mir ein Thread. Wie als wenn man sich selbst duplizieren möchte wenn man in 2 Minuten mit der Freundin verabredet ist aber den Abwasch noch erledigen sollte.

Genau die selben Probleme, welche beim Abwaschbeispiel entstehen können, gibt es im Thread-Fall: Die tatsächlichen Nebenwirkungen stellen ganz schnell eine messbare Effizienz in Frage - wer abwäscht bekommt durst... (Um auch einmal etwas in andreasähnlichem "Duktus" formuliert zu haben. *g*)

Da wäre es imho doch eher hilfreich Verfahren aufzuzeigen - oder sei es nur eine Umdenkweise - welche es eben ermöglichen unter Nutzung der vorhandenen Umgebung genau das passieren zu lassen, was sich z.B. Jac wünscht.

Und wenn Jac unstur etwas davon abkommt, dass tatsächlich irgendwas "gleichzeitig" passieren soll, dann werden die Lösungen auch ganz einfach bzw. möglich.

Eine falsche Vorstellung dessen wie einfach und schön alles wäre mit lauter Threads, weswegen XProfan für XYZ ungeeignet sei, ist imho lediglich unhilfreich.

Wenn er z.B. möchte, dass immer die Uhrzeit im Status blinkt, dann muss er halt in seiner Ereignisschleife einen Aktualisierungsintervall abprüfen (anders gehts auch nicht mit 12 Threads per ASM, C oder D oder JS.). Und wenn er nicht 1ne Ereignisschleife hat, dann muss er das Programm halt dahingehend verbessern/umstricken sodass es ihm selbst leichter fällt Dinge zu implementieren, welche eben nach Zeit X abzulaufen haben.

Hat doch mit Threads nichts zu tun wie es nichts damit zu tun hat ob man als anwendender Programmierer Anwender oder Programmierer ist *g* oder ob man in C, D oder eben in X programmiert.

Zitat von AHT

ich als Anwender

Ich finds ziemlich "beknackt" als Programmierer sich ständig in einem Programmiererforum als Anwender zu bezeichnen, wenn man doch garnichts programmieren kann ohne etwas anzuwenden und wenn man lauter Programme programmiert. Ich bin z.B. Bergbauer - werde ich gefragt warum CLS einen weissen Hintergrund erzeugt, dann erzähle ich auch nicht etwas wie "bergbauer anwender keine farbe bergbauer angegeben anwender schau berbauer in anweder die hilfe".

Wenn es Dir das deklarieren Deiner Programmierer-Fähigkeit geht: Das ist völlig unnötig, die Programme sprechen immer für sich...

Toll, jetzt ists ja doch ein "Thema" geworden. (Bitte abwürgen!)

[Frabbing]

Man sollte auch bedenken: Laufen zwei Threads, teilen diese sich die Zeit, die für den Prozess vorgesehen ist.

[iF_]

Imho aber auch nur bei anorganischer Hardware, ich z.B. krich pro Thread einen Pickel! (Frag nicht!)

@Jac: Einfach den Abwasch und die Freundin zeitlich stückeln sodass am Ende es wirkt als wäre beides synchon passiert. ^^

[Jac de Lad]

@iF: Ich hab seit 2 Monaten ne Spülmaschine.

Aber ich probier das nochmal auf ne andere Art aus, das Hauptprogramm auszulagern. Ich hatte damit bisher wenig Erfolg, aber noch ne Idee wie man es anders machen könnte.

[iF_]

Wenn man von Anbeginn so schreibt ists sicher einfacher als späteres Umstellen des ganzen Programmes. Was schreibst Du eigentlich grad?