| |
|
|
| allô IF...
je habs la fois getestet et hoffe rien faux gemacht trop avons: KompilierenMarqueSéparation $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"
ENDPROC
aussi ici wird cela la fenêtre pas richtig angezeigt! quoi bedeutet cela? Werden im Hauptprogramm au cours de un fil fonctionnement, überschreibt Profan interne gespeicherte Variablen zum Aufrufen de API. Je après que, quelle Profanfunktionen im Hauptprogramm verwendet volonté, ist qui péril la fois plus et la fois moins gegeben, vous ist mais aussi (le son Roland) beim direkten Aufrufen de APIs vorhanden. quand et si un faute auftritt, hängt vom gewählten Zeitintervall, vom calculateur et de qui Programmbedienung par den User ab. quoi bedeutet cela oui c'est ca?
un Beispiel: Beim einem calculateur sous Windows2000 wird beim Aufruf qui API RegUnloadKey un solcher Crash verursacht et qui API wird c'est pourquoi pas korrekt fonctionnement. Daraufhin wird qui Registryhive des User pas comment geplant entladen et ist beim prochain Start pas plus disponible => un ganzes Userprofile ist unwiederbringlich verloren.
un anders Beispiel: cela Hauptprogramm écrit au cours de un Callback fonctionne dans qui Registry. là alles ungünstig zusammentrifft, wird dans une anderen Schlüssel geschrieben et Datenj dans qui Registry aller verloren!
Weitere Fragen et Anmerkungen? |
|
|
| |
|
|
|
| quoi Du sagst bedeutet cela sobald une Procédure, quel per ProcAddr à une Api transfert wurde, de einer Api statt de XProfan selbst aufgerufen wird, XProfan ca pas korrekt auseinanderhalten peux et Variablenspeicher überschrieben volonté?
eh bien cela wäre fatal, zumal cela oui ensuite oui aussi den FastMode betrifft, et chacun APP quel une eigene wProc besitzt avec cela potenziell comme très périlleux eingestuft volonté devrait. cela betrifft alors Callbacks et Subclassing.
mais je hab ne Abhilfe - hoffentlich - comment verhält es sich si sich aucun Variablenbezeichnung - dans aucun Procédure - widerholt? Selbe Problem? *pour*Roland*schrei*seulement*qui*kanns*savons*
si mon AbhilfeIdee cela Problem cependant beseitigen sollte - ensuite hieße es aussi cela un rein-sur-OOP-basiertes Programme möglicherweise moins périlleux son pourrait? |
|
|
| |
|
|
|
| Ah je vois aussi tu as dans Deinem Demo une Hinweis de Je ne beachtet, quel besagte cela seulement cela Waitinput avec Fil.Start et Fil.Stop umschlossen son sollte!
je hab den Source la fois so geändert comment je mir cela vorstelle et empfehle, et siehe là, il y a aucun Probleme: KompilierenMarqueSéparation $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)
Whilenot Ende%
.waitinput
If @Menuitem(108)
Einstellungen
Endif
If @Menuitem(109)
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
proc .waitinput
thread.start 1
Waitinput
thread.stopn class=s2>1
endproc
|
|
|
| |
|
|
|
| allô IF...
non, ne...aucune Variablenspeicher - cela wäre pas so grave. mon Erklärung: si une Profanfunktion, z.B. Créer, fonctionnement wird, doit Créer seulement einmal auseinandergepflückt volonté. Es doit u.a. überprüft volonté, quelle API Créer appel soll. en supplément doit données gespeichert et verglichen volonté. si eh bien mitten im comparaison qui Callback fonctionnement wird (bevor qui API aufgerufen wurde), volonté cet données überschrieben et si qui Callback zurückkehrt, steht là wohin maintenant qui API Call verglichen volonté sollte, seulement encore Mist. |
|
|
| |
|
|
|
| bof mais vais doch la fois sur que voici de mir geschriebene un:
[quote-part:ca377de2a5]quoi Du sagst bedeutet cela sobald une Procédure, quel per ProcAddr à une Api transfert wurde, de einer Api statt de XProfan selbst aufgerufen wird, XProfan ca pas korrekt auseinanderhalten peux et Variablenspeicher überschrieben volonté?
eh bien cela wäre fatal, zumal cela oui ensuite oui aussi den FastMode betrifft, et chacun APP quel une eigene wProc besitzt avec cela potenziell comme très périlleux eingestuft volonté devrait. cela betrifft alors Callbacks et Subclassing.
mais je hab ne Abhilfe - hoffentlich - comment verhält es sich si sich aucun Variablenbezeichnung - dans aucun Procédure - widerholt? Selbe Problem? *pour*Roland*schrei*seulement*qui*kanns*savons*
si mon AbhilfeIdee cela Problem cependant beseitigen sollte - ensuite hieße es aussi cela un rein-sur-OOP-basiertes Programme möglicherweise moins périlleux son pourrait?[/quote-part:ca377de2a5] cet Vermutung de Dir J'ai eu mais aussi déjà autrefois, tout autor empfahl je oui aussi folgendes:
[quote-part:ca377de2a5]Ah je vois aussi tu as dans Deinem Demo une Hinweis de Je ne beachtet, quel besagte cela seulement cela Waitinput avec Fil.Start et Fil.Stop umschlossen son sollte![/quote-part:ca377de2a5] |
|
|
| |
|
|
|
| Rolands antwort puis devrait eigendlich son, qui si on CallBacks utilise, et/ou bien den Fastmode, cela on ensuite seulement reine API écrivons darf. je crois mais cela qui so pas gedacht ist, ou bien? |
|
|
| |
|
|
|
| allô IF...
une gute concept um cela trop tourner autour de, doch quelquefois voudrais (doit) on plan GetMessage verwenden.
Salut
Andreas |
|
|
| |
|
|
|
| [quote-part:14713789fd=Andreas Hötker]allô IF...
une gute concept um cela trop tourner autour de, doch quelquefois voudrais (doit) on plan GetMessage verwenden.
Salut
Andreas[/quote-part:14713789fd] Ist mir bien sûr - mais il y a nunmal aucun Funktion / Procédure / Unit / quoi que + subj. quelle dans 100% aller Fälle/Situationen toujours richtig ist bzw. korrekt angebracht ist.
Viel schlimmer - la fois de qui thread.pcu abgesehen - finde je doch cela ganze avec den Callbacks! |
|
|
| |
|
|
|
| nous sommes alors beim Thema XProfansche Critical-Sections arrivé |
|
|
| |
|
|
|
| [quote-part:a00f5c25f8=iF]bof mais vais doch la fois sur que voici de mir geschriebene un:
[quote-part:a00f5c25f8]quoi Du sagst bedeutet cela sobald une Procédure, quel per ProcAddr à une Api transfert wurde, de einer Api statt de XProfan selbst aufgerufen wird, XProfan ca pas korrekt auseinanderhalten peux et Variablenspeicher überschrieben volonté?
[/quote-part:a00f5c25f8][/quote-part:a00f5c25f8] seulement einmal aucun Variablen, mais de Profan interne genutzte Strukturen Aussi ca va pas à Übergabe einer Prozeduradresse, mais um cela, quoi im Hauptprogramm passiert.
pourquoi haut cela hin, quoi du là tust: Du stoppst den Minuteur, bevor cela la fenêtre erzeugt wird => cela peux pas crashen, den qui Minuteur fonctionne gar pas, si cela la fenêtre erzeugt wird. Nochmal (1001 la fois ): Theorie: 1 Profan arbeitet´die Créer Funktion des Fensters ab. 2. Profan legt dabei données de Créer dans internen grenier ab, um u.a. trop überprüfen, quelle API aufgerufen weerden doit. 3. Bevor qui API Créer komplett abgearbeitet ist, d.h. bevor qui API CreateWindowEx de Profan aufgerufen wird, appelez cela OS qui dem Minuteur mitgegebene Adresse sur. 4. Profan führt Funktionen dans qui Callback aus et belegt qui internen Variablen avec neuen Werten. 5. qui Callback wird jusqu'à zum Ende fonctionnement et es wird trop qui Adresse gesprungen, à qui auparavant aufgehört wurde. 6. Profan veux CreateWindowEx appel, ici stehen mais maintenant qui données vom Callback
So mon je cela... |
|
|
| |
|
|
|
| Du je sais um Votre Theorie, aussi pas seulement êtes Deinem heutigen Posting mais mir allez cela Ganze déjà très longtemps par den tête...
...tout autor meinte je oui cela es demzufolge pas seulement TimerOPs betrifft mais chacun Api quelle une XProfanProzedur aufruft! |
|
|
| |
|
|
|
| je crois il y a pour Roland qui Possibilité, un Aufruf einer XProfanprozedur aus einer API heraus, abzuprüfen. je denke sogar es wäre sonst qui Funktion procaddr garnicht possible - irgendwie muss il oui den angeblichen Sprung à une pas-nativ-vorliegenden Prozeduradresse umsetzen. peut-être peux il ici quelque chose kapseln?! |
|
|
| |
|
|