Das OFFIZIELLE PROFAN SUPPORT FORUM
Einsteigerfragen
PROFAN-Programmierung
Helfer & Tools
Anregungen & Vorschläge
PROFAN-NEWS
Die Regeln!
2 - PROFAN-Programmierung

 Neues Thema  |  Zur Übersicht  |  Suchen  |  Einloggen   Neuerer Beitrag  |  Älteres Thema 
 Messageloop direkt aufrufen?
Autor: Jens-Arne Reumschüssel (---.dip0.t-ipconnect.de)
Datum:   09.01.19 20:50

Hallo zusammen,

im Zusammenhang mit dem Fastmode hätte ich eine allgemeine Frage bzw. Bitte: Ist es möglich, den Profan-Messageloop anders als mit Waitinput aufzurufen?

Waitinput ist nämlich elendiglich langsam, wenn es nur darum geht, Messages zuzulassen und nicht, auf irgendeine Eingabe zu warten. Selbst mit

Waitinput 1

dauert das ganze bei jedem Durchlauf bis zu 15ms, da der Windows-Timer eine zeitliche Auflösung von etwa 15ms besitzt (siehe diverse Beiträge im Internet dazu). Das bedeutet, dass schon bei nur 1000 Schleifendurchläufen die Nutzung von Waintput 1 einen Zeitverlust von bis zu 15 Sekunden (!) mit sich bringt. In einem Profan-Progamm ohne Fastmode läut der Messageloop natürlich extrem viel schneller, er wird ja alle 20 Programmzeilen einmal aufgerufen, ohne dass man das groß merkt. Das kostet offenbar keine 15 Sekunden bei einer Schleife von 20000 Befehlen, wie man mit

whileloop 1,20000
endwhile

leicht herausfinden kann. Es liegt also tatsächlich daran, dass Waitinput 1 ewig herumwartet, obwohl man das sicher nicht gebrauchen kann, da man mit dieser (undokumentierten) Variante von Waitinput ja gerade ausdrückt, dass man nicht warten möchte. Waitinput 1 ist also ein extrem schmutziger, eigentlich gar nicht so bezeichenbarer "Workaround" dafür, dass man manchmal Messages bearbeitet haben muss.

Konkret, damit man die Praxisrelevanz sieht, geht es bei mir um eine Schleife, die meistens viele 1000 Male durchlaufen wird, und die ich gerne durch einen Klick auf einen Button unterbrechbar machen möchte. Aus hier nicht weiter interessierenden Gründen muss das im Fastmode laufen. Dann aber reagiert Profan auf Buttonklicks nicht, wenn der Messageloop nicht aufgerufen wird.

Es wäre also extrem wünschenswert, den Messageloop von Profan anders als mit Waitinput aufrufen zu können. Ist das zur Zeit schon möglich, oder wird es zumindest in künftigen Profan-Versionen möglich sein?

Geht da vielleicht irgendetwas mit @call(...)?

Oder gibt es noch eine andere Möglichkeit, die ich nur gerade nicht sehe?

Beste Grüße, Jens-Arne

Beitrag beantworten
 
 Re: Messageloop direkt aufrufen?
Autor: Heinz Brill (---.dip0.t-ipconnect.de)
Datum:   10.01.19 04:02

Wie sieht es denn mit einem Prozess aus ?

Abt. Multiprozessing mit XProfan .

H.Brill
XProfan X4 + FreeProfan

Beitrag beantworten
 
 Re: Messageloop direkt aufrufen?
Autor: Jens-Arne Reumschüssel (---.dip0.t-ipconnect.de)
Datum:   10.01.19 19:00

Hallo Heinz,

danke, aber ich verstehe nicht so ganz, was das bringen soll. Dann habe ich doch immer noch (in dem neuen Prozess) das Problem, dass die Messages nicht (oder mit waitinput 1 nur sehr langsam) bearbeitet werden.

Beste Grüße, Jens-Arne

Beitrag beantworten
 
 Re: Messageloop direkt aufrufen?
Autor: Heinz Brill (---.dip0.t-ipconnect.de)
Datum:   10.01.19 19:30

Was willst du denn genau machen ?

Wenn es um die Schleife geht, die viele 1000
Male durchlaufen wird, wäre sowas ja genau
richtig.

Diese käme ja in die Proc, die mit Pid& = pExec() bei Programm-
beginn gestartet wird. Ohne Waitinput oder sonst was.

Im Hauptprogramm kommen 2 Buttons, mit denen man zum
einen mit
Process("Suspend", Pid&)
den Prozess anhalten kann und zum anderen mit
Process("Resume", Pid&)
den Prozess wieder weiterlaufen läßt.


Und am Ende des Programms kommt einfach ein
Process("Kill", Pid&, 0).

Und was für Messages willst du eigentlich in einem solchen
Prozess bearbeiten ?
Die normalen Messages werden im Hauptprogramm abgearbeitet.
Wenn du möchtest, kannst du aber auch eine UserMessage einrichten.
Du gibst per Parameter (wie in der Hilfe am Beispielcode beschrieben)
das Handle deines Hauptfensters (%HWnd) mit. Sollte deine Proc
mit der Schleife fertig sein, schickst du einfach in der Proc mit
SendMessage(HandledesFensters, Usermessage, 0,0) an dein
Hauptprogramm eine Nachricht. Damit weiß dieses, daß der Auftrag
(Prozess) beendet ist. Die beiden Parameter bei SendMessage (N3 + N4)
kannst du auch noch gerne benutzen, um z.B. einen zus. Wert zu
schicken.


Ich hoffe, wir reden nicht wieder aneinander vorbei.

H.Brill
XProfan X4 + FreeProfan

Beitrag beantworten
 
 Re: Messageloop direkt aufrufen?
Autor: p. specht (---.aon.at)
Datum:   10.01.19 19:36

Meine Notlösung:
Ich mache das so, daß ich entweder die Durchläufe zähle
(inc n&:if n&> xxx: ...) - wenn deren Zeit in etwa gleich ist, oder
- davon unabhängig das recht schnelle Rnd()>0.998 nutze, um
Waitinput 12 seltener aufzurufen (Waitinput 1 führt bei langsamen
Rechnern wie meinem eher zu Stau-Erscheinungen).
Gruss

____
Ein richtiges Problem hat keine Lösung, nur Näherungen!

Beitrag beantworten
 
 Re: Messageloop direkt aufrufen?
Autor: Heinz Brill (---.dip0.t-ipconnect.de)
Datum:   10.01.19 20:03

Vielleicht hier ein kleines Beispiel zum besseren
Verständnis.

 Declare Handle btn1, btn2, btn3, grid, Long ende, pid
 
 Window 640, 400
 btn1 = Create("Button", %HWnd, "Suspend", 10, 10, 80, 25)
 btn2 = Create("Button", %HWnd, "Resume", 100, 10, 80, 25)
 btn3 = Create("Button", %HWnd, "Ende",   500, 10, 80, 25)
 grid = Create("GridBox", %HWnd, "Spalte 1;0;80;Spalte 2;0;80;Spalte3;0;80", 0, 10, 80, 280, 200)
 
 ende = 0
 pid = 0
 
 UserMessages $1000
 
 pid = pExec("|Schleife", %HWnd, grid)
 
 WhileNot ende
   WaitInput
   If Clicked(btn1)
      Process("Suspend", pid)
   ElseIf Clicked(btn2)
     Process("Resume", pid)
   ElseIf Clicked(btn3)
      Ende = 1
   EndIf
   If %UMessage = $1000
       MessageBox("Schleife hat aufgehört !", "Info", 0)
   EndIf    
 EndWhile
 
 If pid > 0
    Process("Kill", pid, 0)
 EndIf
 End
 
 Proc Schleife
 Parameters Handle win, tabelle
 Declare Long i
 For i, 1, 100
      WhileLoop 1, 10
          AddString(tabelle, Str$(&LOOP) + "|" + Str$(&LOOP * 2) + "|" + Str$(&LOOP * 3))
          Sleep 100
          ' Das Sleep ist hier nur drin, damit man den Fortschritt und
          ' damit die Anzeige in der Tabelle besser sieht. Andernfalls
          ' rutscht es zu schnell durch.
      EndWhile
 EndFor
 SendMessage(win, $1000, 0, 0)
 EndProc
 


H.Brill
XProfan X4 + FreeProfan

Nachricht bearbeitet (10.01.19 20:09)

Beitrag beantworten
 
 Re: Messageloop direkt aufrufen?
Autor: Jens-Arne Reumschüssel (---.dip0.t-ipconnect.de)
Datum:   10.01.19 21:14

Hmm, die Idee ist im Prinzip in der Tat nicht schlecht. Aber leider ist die fastmode-Verzahnung zwischen Hauptprogramm und Schleife nicht auflösbar. Es geht tatsächlich immer noch um das scheinbar so einfache, aber im Detail doch echte Kopf-ab-Problem der farbigen Controls. Es ist einfach nicht zu fassen, dass Microsoft nicht einfach ein setcolor bereithält, wie es auch ein settext gibt...

Gruß, Jens-Arne

Beitrag beantworten
 
 Re: Messageloop direkt aufrufen?
Autor: Jens-Arne Reumschüssel (---.dip0.t-ipconnect.de)
Datum:   10.01.19 21:16

Da hatte ich auch schon dran gedacht. Notfalls mache ich das auch so, aber leider ist der Ablauf der Schleife von der Zeitdauer her extrem unterschiedlich (darin werden Dateien kopiert, die von einem Byte bis quasi unendlich groß sein können). Das ist das Problem mit Workarounds: Sie funktionieren leider fast nie so gut wie die "richtige" Lösung, die es im Moment hier aber noch nicht zu geben scheint.

Gruß, Jens-Arne

Beitrag beantworten
 
 Re: Messageloop direkt aufrufen?
Autor: Jens-Arne Reumschüssel (---.dip0.t-ipconnect.de)
Datum:   10.01.19 21:32

Habe die Lösung gefunden, siehe der neue Thread direkt unter diesem (damit der Rest sieht, dass es da nichts mehr zu knobeln gibt).



Nachricht bearbeitet (10.01.19 21:33)

Beitrag beantworten
 Foren-Liste  |  Baumstruktur   Neuerer Beitrag  |  Älteres Thema 


 Foren-Liste  |  Zur Registrierung 
 Benutzerlogin
 Benutzername:
 Passwort:
 Login-Daten speichern:
   
 Passwort vergessen?
E-Mail-Adresse oder Username unten eingeben. Dann wird Dir per e-Mail ein neues Passwort zugeschickt.

phorum.org