[erledigt] Warum wird der LV-Aufbau verzögert ?

[ts-soft]

Bei WindowEvent() wird exact ein Ereignis aus der Warteschlange genommen, das reicht also nicht.
Durch WindowEvent() bzw. WaitWindowEvent() werden auch Ereignisse
abgearbeitet, deren Code sich nicht in der Schleife befindet, sprich das
interne Callback, bzw. die gesubclassten Callbacks der Gadgets werden
abgearbeitet.

Seine Schleife um Gosub sehe ich auch nicht

Ansonsten wie schon gesagt, entweder nach jedem gosub ..., oder alle
gosubs in die Eventschleife mit Timeout abarbeiten

[Kaeru Gaman]

> Seine Schleife um Gosub sehe ich auch nicht

eben das ist der punkt...

hier ist nirgendwo etwas, wo auf PB-code-seite eine aktion wiederholt wird,
die man durch eine ereignisbearbeitung ergänzen könnte.

das hat alles eine zeile, und mündet direkt in die haupt-ereignisschleife.

also, da kann nix irgendwo warten. das kann irgendwie nicht schneller gehen...

[scholly]

eben das ist der punkt...

hier ist nirgendwo etwas, wo auf PB-code-seite eine aktion wiederholt wird,
die man durch eine ereignisbearbeitung ergänzen könnte.

Ich glaub, jetzt hab ichs verstanden.
Da ich mehrere Seiten downloaden und unter verschiedenen Namen abspeichern will, böte es sich ja an, die Stringpaare URL|Filename in ein 2-dimensionales array zu schreiben, das dann per Schleife über eine proc abzuarbeiten und in dieser jeweils ein While WindowEvent() : Wend zu benutzen um die Dartellungsauffrischung zu erzwingen.

Richtig verstanden ?

[edel]

*seufz*

Vergiss das mit dem windowevent. Das ist "dreckig coden" und fuehrt nur
zu Problemen. Folgender Code zeigt zwar das Fenster aber es reagiert
nicht auf Benutzereingaben wie schliessen usw..

Code: Alles auswählen

hwnd = OpenWindow(0,0,0,200,200,"")

For i = 0 To 10000000
  While WindowEvent() : Wend 
Next

Repeat
  e = WaitWindowEvent() 
Until e = 16

Schau dir lieber mal das Kapitel Thread in der Hilfe an.

Beispiel :

Code: Alles auswählen

  Structure DL_URL
    url.s
    file.s
  EndStructure

  Procedure Download(*download.DL_URL)
    
    If URLDownloadToFile_(0,*download\url,*download\file,0,0) = 0
      AddGadgetItem(0,-1,*download\url + " - geladen")
    EndIf
    
  EndProcedure

  OpenWindow(0, 50, 50, 300, 600, "weekly charts", #PB_Window_SystemMenu) 
  
  CreateGadgetList(WindowID(0))
  
  ListViewGadget(0, 10, 10, 280, 580)
  
  Download.DL_URL
  Download\url  = "HTTP://www.mtvhome.de/hitlistgermany/index.php"
  Download\file = "D:\mtv_ger_100.html"
  CreateThread(@Download(),Download) 
  
  Download2.DL_URL
  Download2\url  = "HTTP://google.de"
  Download2\file = "D:\google.htm"
  CreateThread(@Download(),Download2) 
  
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow

[scholly]

Danke an alle Hilfsbereiten - hab wieder was gelernt.

Für den schnellen Erfolg hab ich den edel-code genommen, aber den anderen Weg werde ich in einer stillen Stunde auch nochmal gehen.

bis zum nexten Problem...
scholly

[Kaeru Gaman]

ein thread ist ne gute möglichkeit, aber es sollte auch ohne gehen.

> die Stringpaare URL|Filename in ein 2-dimensionales array zu schreiben, das dann per Schleife über eine proc abzuarbeiten

richtiger weg

> und in dieser jeweils ein While WindowEvent() : Wend zu benutzen um die Dartellungsauffrischung zu erzwingen.

nein. das ist, wie edel sagte, dreckig coden.

sowas sollte man sich eigentlich gar nicht angewöhnen.

wichtig wäre im grunde, dass du immer genügend events abarbeitest,
bevor du das nächste selber auslöst.

das kannst du ohne thread am besten dadurch erreichen,
dass du auch das auslesen in die hauptschleife schreibst.

so in der richtung:

Code: Alles auswählen

Repeat
   Event = WaitWindowEvent(10)

  If Event = 0
    ; nächster netzzugriff oder gadget-änderung
  Else
    ; normale event-bearbeitung
  EndIf
Until Event = #PB_Event_CloseWindow

damit hast du nur eine einzige schleife, keinen thread,
und mit dem If Event=0 stellst du sicher, dass du nur dann ein
event erzeugst, wenn die eventschleife platz zum bearbeiten hat.
die wartezeit, hier 10ms, ist wichtig, damit die hauptschleife nach 10ms
auch dann durchlaufen wird, wenn kein event stattgefunden hat.
du könntest hier auch nur WindowEvent() benutzen, aber das würde dazu führen,
dass die schleife dauernd durchlaufen wird und CPU frisst.


egal also, wieviel events du mit einem netzzugriff/gadget ändern erzeugst,
die werden erst alle abgearbeitet, dann erst wird der nächte zugriff versucht.

[ts-soft]

>> nein. das ist, wie edel sagte, dreckig coden.
Solange das normale Eventloop nicht aktiv ist, also keine Useraktivitäten
stattfinden, ist das Quatsch. Evtl. sollte er vorhandene Knöpfe disablen.

An einen Thread, der einen Pointer erwartet, eine Variable zu übergeben,
funktioniert zwar, ist aber dreckiges Coden. "Anfängern" Threads überhaupt
vorzuschlagen ist auch falsch, weil bei Fehlfunktion kommen die wieder nicht
weiter, bzw. Fehler in Threads werden meist nicht als solche erkannt, weil der
Debugger auch falsche Ergebnisse bringt.

Die Lösung mit dem Timeout ist auf jedenfall ein guter Kompromiß.

Ich bin raus

[Kaeru Gaman]

> Solange das normale Eventloop nicht aktiv ist, also keine Useraktivitäten
> stattfinden, ist das Quatsch

da magst du ja recht haben, aber ich habs schon oft in normalen eventloops gesehen,
um überhänge abzuarbeiten, und das kann sich negativ auswirken.


> Die Lösung mit dem Timeout ist auf jedenfall ein guter Kompromiß.

ja, aber ich bin nicht ganz zufrieden...

sobald das komplette einladen erledigt ist, besteht keine notwendigkeit mehr,
ohne event die schleife zu bearbeiten.
evtl. will man durch einen buttonclick ein weiteres einladen auslösen, dann besteht wieder bedarf.

im grunde bräuchte man noch ein extra-flag, dass das durchlaufen nur dann zuläßt,
wenn auch wirklich noch event-erzeugende aktionen anstehen.

[edel]

Brauchst ja nur ne Variable fuer den Timeout , wenn du fertig bist
setzt man es wieder auf #pb_default bzw -1.

[Kaeru Gaman]

das is ne gute idee...
und die könnte man dann auch bei bedarf wieder hochsetzen.

bist du sicher, das -1 als #DEFAULT interpretiert wird, und nicht als $FFFFFFFF ?