| |
|
|
- Seite 1 - |
|
| Hallo IF...
Ich habs mal getestet und hoffe nichts falsch gemacht zu haben: KompilierenMarkierenSeparieren $U thread.pcu = thread.
DEF @GetDlgCtrlID(1) !"USER32","GetDlgCtrlID"
DEF @ButtonClicked(1) @GetDlgCtrlID(@&(1))=-%MENUITEM
Testprogramm Timer
Profan Version 9
$H Windows.ph
-Main----------------------------------------------------------------
Declare Timer_Busy%,Ende%
Declare TimerID&,Create%,T_Text&,Test#
WindowStyle 26
WindowTitle "Timertest PHU-60"
Window 100,100 - 370,200
cls
Let T_TEXT&=@CREATETEXT(%HWND,"",30,30,300,30)
-Menue---------------------------------------------------------------
PopUp "&Programm"
AppendMenu 108,"&Einstellungen"
AppendMenu 109,"&Ende"
Ende% = 0
Timer setzen (4x pro Sekunde, 250ms)
thread.start 1,1
WhileNot Ende%
WaitInput
If @MenuItem(108)
Einstellungen
Endif
If @MenuItem(109)
thread.stopall
Ende% = 1
Endif
Wend
End
-Proc Einstellungen
Proc Einstellungen
Declare hD%, hA%, hB%, OK%, hTime%
Declare hF1%, hT1%
Clear OK%
Dialogfenster erzeugen
hD% = @Create("Dialog",%hWnd,"Einstellungen",%WinLeft+80,%WinTop+155,230,190)
hF1% = @Create("Font","Arial",16,0,0,0,0)
hT1% = @Create("Text",hD%,"Einstellungen...",10,10,220,20)
SetFont hT1%,hF1%
hTime% = @Create("TimeEdit", hD%, "00:00:00", 10, 35, 70, 24)
hB% = @Create("Button",hD%,"&Nachstellen",10,120,100,28)
hA% = @Create("Button",hD%,"&Abbrechen",120,120,100,28)
WhileNot Ok%
WaitInput
If @ButtonClicked(hB%) Nachstellen
Ok% = 1
Aktionen hier
ElseIf @ButtonClicked(hA%) Abbrechen
Ok% = 1
ElseIf (%Key = 2) ALT+F4 bzw. schließen
Ok% = 1
EndIf
EndWhile
DeleteObject hF1%
@DestroyWindow(hD%)
EndProc
-Prozedur die in bestimmten Zeitintervallen ausgefuehrt wird (4x pro Sekunde)
Proc thread.do
parameters n&
Dim Test#,1000000
Inc Timer_Busy%
Locate 5,5
Print "Timer:" + @str$(Timer_Busy%) + " Durchläufe"
Settext T_Text&,"Timer:" + @str$(Timer_Busy%) + " Durchläufe"
Dispose Test#
EndProc
Auch hier wird das Fenster nicht richtig angezeigt! Was bedeutet das? Werden im Hauptprogramm während ein Thread ausgeführt, überschreibt Profan intern gespeicherte Variablen zum Aufrufen von API. Je nachdem, welche Profanfunktionen im Hauptprogramm verwendet werden, ist die Gefahr mal mehr und mal weniger gegeben, sie ist aber auch (laut Roland) beim direkten Aufrufen von APIs vorhanden. Wann und ob ein Fehler auftritt, hängt vom gewählten Zeitintervall, vom Rechner und von der Programmbedienung durch den User ab. Was bedeutet das genau?
Ein Beispiel: Beim einem Rechner unter Windows2000 wird beim Aufruf der API RegUnloadKey ein solcher Crash verursacht und die API wird deshalb nicht korrekt ausgeführt. Daraufhin wird der Registryhive des User nicht wie geplant entladen und ist beim nächsten Start nicht mehr verfügbar => ein ganzes Userprofile ist unwiederbringlich verloren.
Ein anders Beispiel: Das Hauptprogramm schreibt während ein Callback läuft in die Registry. Da alles ungünstig zusammentrifft, wird in einen anderen Schlüssel geschrieben und Datenj in der Registry gehen verloren!
Weitere Fragen und Anmerkungen? |
|
|
| |
|
|
| |
|
- Seite 2 - |
|
|
| Hallo IF...
Mir ebenfalls - vor diesem schönen Quelltext konnte ich leider den Grund nicht finden. Kannst du dir jetzt vorstellen, warum ich unbedingt wissen wollte, ob du Timer in der PCU verwendest? Einen Thread würde ich erst stoppen, wenn er nicht mehr gebraucht wird => kann fatal werden!
Gruß
AH |
|
|
| |
|
|
|
| Nein kann ich nicht wirklich zumal der Timer hierbei Nebensache ist wenn es tatsächlich alle Dinge betrifft welche mit procaddr zutun haben. Da sind Timer wohl eher in der Minderheit wenn ich bedenke wie oft eine wProc angecallt wird...
Ich will sagen, selbst wenn ich jetzt in der DLL - mal angenommen - selber die Zeit rechnen würde und statt über einen Timer ein Call auf die ProcAddr mache - dann wäre es ebenso schlimm! Das Problem selbst hat also nicht vordergründig mit den Timern zu tun.
Eine Save-Variante wäre es natürlich einfach eine Message an hwnd zu senden wenn ein Event passieren soll. Das wiederum würde aber leider die Struktur ändern. |
|
|
| |
|
|
|
| Auch an dich: Lese dir genau durch, was ich schreibe. Das Problem hat meiner Meinung nach nichts mit anderen Callbacks zu tun! |
|
|
| |
|
|
|
| Ich lese die Postings aller Mitglieder gleichgenau durch.
Mir fehlt aber für Deine letzte Behauptung eine Begründung... |
|
|
| |
|
|
|
| WM_TIMER wird bei Angabe einer Adresse nicht unbedingt von der WndProc bearbeitet, das ist der Unterschied. |
|
|
| |
|
|
|
| Die Shatter Attack nutzt das - Ich suche gleich mal den Artikel... |
|
|
| |
|
|
|
| [quote:bf2faa3b30]WM_TIMER wird bei Angabe einer Adresse nicht unbedingt von der WndProc bearbeitet, das ist der Unterschied.[/quote:bf2faa3b30] Hm sei mir nicht böse aber ich finde das irreführend.
Ich will sagen, selbst wenn ich jetzt in der DLL - mal angenommen - selber die Zeit rechnen würde und statt über einen Timer ein Call auf die ProcAddr mache - dann wäre es ebenso schlimm! Das Problem selbst hat also nicht vordergründig mit den Timern zu tun und auch nicht damit - ob wm_timer von der wndproc erfasst wird - zumal unklar ist inwiefern Rolands wndProc dann wiederum weiterhandelt...
Aber ich glaube hier kann uns nur Roland helfen... |
|
|
| |
|
|
|
| EasyVent.Dll - selbe Problem... insgesammt aber sicherlich nicht unschlecht das das Thema angesprochen ist - es brennt auch mir schon lange auf der Seele - packen wirs also bei den Haxen und warten Rolands Statement ab... |
|
|
| |
|
|
|
| [quote:ae4c1936c9=iF][quote:ae4c1936c9]WM_TIMER wird bei Angabe einer Adresse nicht unbedingt von der WndProc bearbeitet, das ist der Unterschied.[/quote:ae4c1936c9] Hm sei mir nicht böse aber ich finde das irreführend.
Ich will sagen, selbst wenn ich jetzt in der DLL - mal angenommen - selber die Zeit rechnen würde und statt über einen Timer ein Call auf die ProcAddr mache - dann wäre es ebenso schlimm! [/quote:ae4c1936c9] Scon ausprobiert? Ich will hoffen, wir reden nicht aneinander vorbei...
[quote:ae4c1936c9] If you pass a non-null HWND after the specified interval has passed, a WM_TIMER message is posted to the window and the TIMERPROC parameter is ignored. The other option is passing a null HWND and a valid TIMERPROC address. In this case, after the specified time has elapsed, the HWND is ignored and the system calls your TIMERPROC function. [/quote:ae4c1936c9] |
|
|
| |
|
|
|
| Kann schon sein das wir aneinander vorbeireden...
vielleicht sehen wir die Problematik auch an verschiedenen Stellen...
Spielt ja keine Rolle - grundsätzlich geht es darum was passiert wenn eine XProfanprozedur nicht vom XProfan selbst - sondern von außen angerannt wird... - der Diener hierzu ist procaddr . Die Aufdröselung wie Roland das realisiert hat kann nur er uns geben - bis dato könnten alle Spekulationen im Nachhinein nichtig sein. |
|
|
| |
|
|
|
| FALSCH!!!!!!
Nicht darum von wo sie angerannt werden, sondern wie und wo sie stehen! Stehen Callbacks außerhalb von Profan, gibt es keine Probleme. Auch bei Callbacks innerhalb von Profan dürfte es wohl nur bei WM_TIMER große Probleme geben (bin mir da aber nicht ganz sicher). |
|
|
| |
|
|
|
| LOL, FALSCH!!! und (bin mir da aber nicht ganz sicher). An dem Postings ist nichts falsch vertrau mir.
Nun wart doch mal Rolands Antwort ab. |
|
|
| |
|
|