Forum | | | | - page 1 - |
| | 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? |
| | | | |
| | | | | - page 3 - |
| | et cet trois Source wären là sous anderem aussi encore intéressant: KompilierenMarqueSéparationDEF @GetDlgCtrlID(1) !"USER32","GetDlgCtrlID"
DEF @ButtonClicked(1) @GetDlgCtrlID(@&(1))=-%MENUITEM
DEF @GetProcAddress(2) !"KERNEL32","GetProcAddress"
Testprogramm Timer
Profan Version 9
$H Windows.ph
-Main----------------------------------------------------------------
Declare Timer_Busy%,Ende%
Declare TimerID&,Create%,T_Text&,Test#,T_TEXT2&
Declare OldWndProc&,DLL&,P_A&
LET DLL&=@Usedll("Send.DLL")
WindowStyle 26+512
WindowTitle "Subclassingtest"
Window 100,100 - 370,200
Let T_TEXT&=@CREATEButton(%HWND,"",30,80,300,30)
Let T_TEXT2&=@CREATEButton(%HWND,"Ende",30,120,300,30)
Waitinput
Set("FastMode", 1)
OldWndProc& = ~GetWindowLong(%hWnd,~GWL_WNDPROC)
LET P_A&=@GetProcAddress(DLL&,"_timer@16")
~SetWindowLong(%hWnd,~GWL_WNDPROC,@ProcAddr("Sub",4))
Ende%=0
TimerID&=~SetTimer(%HWND,333,20,P_A&)
Print TimerID&
WhileNot Ende%
WaitInput
If @Buttonclicked(T_TEXT&)
Einstellungen
Endif
If @Buttonclicked(T_TEXT2&)
~KillTimer(%HWND,333)
Ende%=1
Freedll DLL&
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)
hD% = @Control("Dialog","Einstellungen",$14C80084,%WinLeft+80,%WinTop+155,230,190,%HWND,0,%HINSTANCE,$101)
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
Proc Sub
Parameters hWnd&,Message&,wParam&,lParam&
If Message&=$401
Inc Timer_Busy%
Settext T_Text&,"Timer: " + @str$(Timer_Busy%) + " Durchläufe"
Return ~CallWindowProc(OldWndProc&,hWnd&,Message&,wParam&,lParam&)
Else
Return ~CallWindowProc(OldWndProc&,hWnd&,Message&,wParam&,lParam&)
EndIf
ENDPROC
KompilierenMarqueSéparationDEF @GetDlgCtrlID(1) !"User32","GetDlgCtrlID"
DEF @ButtonClicked(1) @GetDlgCtrlID(@&(1))=-%MENUITEM
DEF @GetProcAddress(2) !"KERNEL32","GetProcAddress"
Testprogramm Minuteur
Profan Version 9
$H Windows.ph
-Main----------------------------------------------------------------
Déclarer Timer_Busy%,Ende%
Déclarer TimerID&,Créer%,T_Text&,Test#,T_TEXT2&
Déclarer OldWndProc&,DLL&,P_A&
LET DLL&=@Usedll("Send.DLL")
Fenêtre Style 26+512
Titre de la fenêtre "Subclassingtest 2"
Fenêtre 100,100 - 370,200
Laisser T_TEXT&=@CREATEButton(%HWND,»,30,80,300,30)
Laisser T_TEXT2&=@CREATEButton(%HWND,"Ende",30,120,300,30)
Waitinput
Set("Fastmode", 1)
OldWndProc& = ~GetWindowLong(%hWnd,~GWL_WNDPROC)
LET P_A&=@GetProcAddress(DLL&,"_timer@16")
~SetWindowLong(%hWnd,~GWL_WNDPROC,@ProcAddr("Sub",4))
Ende%=0
TimerID&=~SetTimer(%HWND,333,25,@ProcAddr("Sub",4))
Imprimer TimerID&
WhileNot Ende%
WaitInput
Si @Buttonclicked(T_TEXT&)
Einstellungen
Endif
Si @Buttonclicked(T_TEXT2&)
~KillTimer(%HWND,333)
Ende%=1
Freedll DLL&
Endif
Wend
Fin
-Proc Einstellungen
Proc Einstellungen
Déclarer hD%, hA%, hB%, OK%, hTime%
Déclarer hF1%, hT1%
Claire OK%
Dialogfenster erzeugen
hD% = @Créer("Dialog",%hWnd,"Einstellungen",%WinLeft+80,%WinTop+155,230,190)
hD% = @Contrôle("Dialog","Einstellungen",$14C80084,%WinLeft+80,%WinTop+155,230,190,%HWND,0,%HINSTANCE,$101)
hF1% = @Créer("Font",Arial,16,0,0,0,0)
hT1% = @Créer("Text",hD%,"Einstellungen...",10,10,220,20)
SetFont hT1%,hF1%
hTime% = @Créer("TimeEdit", hD%, "00:00:00", 10, 35, 70, 24)
hB% = @Créer("Button",hD%,"&Nachstellen",10,120,100,28)
hA% = @Créer("Button",hD%,"&Abbrechen",120,120,100,28)
WhileNot Ok%
WaitInput
Si @ButtonClicked(hB%) Nachstellen
Ok% = 1
Aktionen ici
ElseIf @ButtonClicked(hA%) démolir
Ok% = 1
ElseIf (%Key = 2) ALT+F4 ou schließen
Ok% = 1
EndIf
Endwhile
DeleteObject hF1%
@DestroyWindow(hD%)
ENDPROC
Proc Sous
Paramètres hWnd&,Message&,wParam&,lParam&
Inc Timer_Busy%
Settext T_Text&,"Timer: " + @str$(Timer_Busy%) + " Durchläufe"
ENDPROC
KompilierenMarqueSéparation qui faute hat alors wohl rien avec Subclassing trop 1faire - ou bien quoi meinst du oui c'est ca? |
| | | | |
| | | | - page 4 - |
| | | [quote-part:19dfeaab2b=Frank Abbing][quote-part:19dfeaab2b]Comme je le disais: s'il te plaît Testen! intéressé mich brennend. Bau fois le Callback dans un DLL - dauert oui pas longtemps...[/quote-part:19dfeaab2b] je hatte cela déjà gemacht. mon Dll hat une Fil erzeugt et cette hat une profansche Callbackroutine aufgerufen. Pour mehreren Aufrufen brach Profan avec den sonderlichsten Fehlermeldungen ab. Je kürzer qui Spanne qui Aufrufe, desto plus rapide kamen qui faute.[/quote-part:19dfeaab2b] allô Frank...
enfin versteht la fois einer, quoi je sage . Hab deinen Beitrag malheureusement seulement maintenant gelesen. cet Problem c'est moi également bekannt - cela liegt mais entier woanders et läßt sich droite simple tourner autour de (siehe Rolf). |
| | | | |
| | | So Andreas,
qui pas écouter peux doit sentir.
Im Grunde aller unsere Meinungen oui dahingehend auseinander le moi sage, cela es grundsätzlich à procaddr liegt, weil ca qui Schnittstelle ist en supplément cela de aussen Prozeduraufrufe injiziert volonté peut et Du meinst cela es speziell avec WM_Timer trop 1faire hat.
alors habe je cela ganze sans Wm_timer gelöst, un Call wird de einer DLL direct aufgerufen, toujours et toujours wieder.
Es belegt cela es vokommen peux, cela si une proc qui per procaddr disponible gemacht wurde, extern aufgerufen wird, XProfan sich verhäddert. sans ProcAddr wäre ca oui pas possible.
ici qui Code zum Selbertesten, unten ne versaute Dll.
Es hat demzufolge rien avec qui Fil-Unit trop 1faire et rien avec wm_timer, weshalb Je l' Fil aussi aus dem Fil-Unit-Bereich entfernt, et pour Programmation geschoben habe. KompilierenMarqueSéparationDef @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
declare h&
h&:=usedll("thread2.dll")
h&:=external("kernel32","GetProcAddress",h&,"dodo")
external("thread2.dll","f",procaddr("thread.do",0),h&)
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
|
| | | | |
| | | allô IF...
Im habe Je l' impression, wir reden im Prinzip de qui selben l'affaire , penser mais beide pas zuende . la hâte du dir déjà la fois überlegt, pourquoi qui faute beim Verwenden de Set(FastMode, 1) pas plus auftritt ? si cela wirklich chez chaque Callback sur une Profanfunktion vorkommt (cela glaube je dir, aussi sans den Voir le texte source qui DLL trop voyons), devrait on absolument oui c'est ca savons, chez welchen Profanfunktionen là péril besteht. j'ai ici Stundenlang avec Writeini et Readini$ herumexperimentiert, sans (zum Glück) une faute trop erzeugen. si cela wirklich sogar (le son Roland) beim direkten Aufrufen de APIs passer pourrait, gibt es eigentlich gar aucun Possibilité, cela Messagehandling beizubehalten et autre chose gleichzeitig ablaufen trop laisser.
cela es à qui Häufigkeit des Aufrufens qui Procédure liegt, peux je pas bestätigen. Je moins qui Procédure aufgerufen wird, umso geringer ist qui probabilité, cela un faute passiert - qui faute passer mais doch. dans TNT wird également un Callback verwendet - cela Programme verwende je laufend, um irgendetwas dans Windows trop untersuche. Am Anfang traten, égal comment souvent qui Callback aufgerufen wurde, toujours irgendwelche faute sur. depuis je là quelques Profanfunktionen à une autre Stelle déménagé habe (wohin vous aucun Probleme plus faire), ist Ruhe. |
| | | | |
| | | [quote-part:3974012546]la hâte du dir déjà la fois überlegt, pourquoi qui faute beim Verwenden de Set(FastMode, 1) pas plus auftritt ? [/quote-part:3974012546] c'est Unsinn Andreas, es hat aussi rien avec dem Fastmode trop 1faire.
Es liegt simple à qui Umsetzung de procaddr - j'ai mir mon Betrachtungsweise bestätigen laisser.
Im FastMode treten naturellement selbige Probleme sur! |
| | | | |
| | | Nachtrag: péril besteht grundsätzlich chez allen ProfanFunktionen, qui péril augmenté sich - je dis donc plump - aus desto plus Aufrufen qui Funktion interne besteht.
cet Dinge de denen Du berichtest - dire wir il y a près de/Folgeerscheinungen. |
| | | | |
| | | allô IF...
seulement la fois besten Dank pour deine Bemühungen. Sollte cela so stimmen (et cela est maintenant pas, le moi dir cela pas glaube), ist cela vraie une Hiobsbotschaft - im Klartext bedeutet cela oui u.a. folgendes: - c'est dans aucun Weise possible seulement avec Profan irgendetwas (gleichzeitig) correct ablaufen trop laisser. - c'est pas possible, avec Profan une vernünftigen Service trop écrivons. - une vielzahl à APIs peux on avec Profan pas verwenden (SendMessageCallback, alle Minuteur avec Callbacks, EnumThreadWindows, EnumWindows....)
Eignet sich Profan überhaupt ensuite zum Programmieren? la fois angenommen, doit dans certain Zeitabständen quelque chose sur une Callback dokumentieren et mon Programme fummelt gleichzeitig avec RegLoadKey / RegUnloadKey dans qui Registry rum (so comment RegEdt32 cela tut), qui venez ensuite pour den dommage à fremden Rechnern ou bien Systemen sur? Sollte on avec Profan programmierte Programme ensuite überhaupt dans Umlauf apporter? cela doit sich schnellstens changement! |
| | | | |
| | | bof! qui Ausnahme - dans qui es keinerlei Probleme gibt - sommes arrêt Funktionen quelle une ProcAddr besoin mais sich seulement finissons si le travail geschehen ist! Roland hat ProcAddr eigendlich aussi seulement so gedacht!
ici z.B. cet Beispiel: [...]
alors Probs gibts pas, si le Funktion qui Proc derrière qui ProcAddr aufruft, ca aussi seulement tut solange vous selbst encore fonctionne.
quoi qui Gleichzeitigkeit avec cela betrifft bedeutet ca pour alle anderen Fälle cela qui Funktion ProcAddr ungeeignet ist. malheureusement! |
| | | | |
| | | [quote-part:0f571140cc=iF]bof! qui Ausnahme - dans qui es keinerlei Probleme gibt - sommes arrêt Funktionen quelle une ProcAddr besoin mais sich seulement finissons si le travail geschehen ist! Roland hat ProcAddr eigendlich aussi seulement so gedacht! [/quote-part:0f571140cc] alors alle Enum-Funktionen faire aucun Probleme. [quote-part:0f571140cc=iF] alors Probs gibts pas, si le Funktion qui Proc derrière qui ProcAddr aufruft, ca aussi seulement tut solange vous selbst encore fonctionne. [/quote-part:0f571140cc] alors gibts u.a. avec SendMessageCallback Probleme. cela écrivons sämtlicher Services serait également au-dessous tomber et Probleme faire. une vernünftigen Taskmanager peux on ensuite également pas écrivons. [quote-part:0f571140cc=iF] quoi qui Gleichzeitigkeit avec cela betrifft bedeutet ca pour alle anderen Fälle cela qui Funktion ProcAddr ungeeignet ist. malheureusement![/quote-part:0f571140cc] c'est très grave. Überhaupt une Taskmanager trop écrivons, ist alors pas possible. Den Speicherverbrauch plusieurs Prozesse im Auge trop behalten, également pas. Vernünftige Registryeditoren tomber wohl aussi flach - au cours de on Unterschlüssel auflistet, pourrait on son Programme seulement schwer bedienbar tenir. une l'heure dans mon Programme einzublenden - allez pas. si sich cela wirklich pas avec Set(FastMode, 1) tourner autour de läßt, schmeiße je Profan lieber seulement la fois dans qui coin. cet Problem doit absolument besser dokumentiert ou bien am besten entier beseitigt volonté - là peux on oui dans Teufelsküche venons. |
| | | | |
| | | bof on munkelt es pourrait bientôt Abhilfe donner. ;)
là bleibt wohl rien plus comme qui Erkenntnis - et quelque chose attendre...
Zumal - cela ganze wird eigendlich par toi aufgebauscht - cela muss je aussi la fois bien sûr dire!
c'est réellement nichtmal demie so wild!
j'écris très viele Programme quelle ProcAddrs nutzen - je hatte encore ne...aucune solches Phänomen - muss mais aussi en supplément dire - je suis naturellement geübt y mir très bien vorzustellen comment un Source den j'écris oui c'est ca Abläuft - et verhindere avec cela naturellement déjà unbewusst so manch Komplikationen - zumal mir cela ProcAddrProblem comment bereits souvent erwähnt pas récente ist.
Simple verfügbare Beispiele - déjà une derartigen faute dans Konstantinopel ou bien Okrea herbeiführen peut? je crois non.
cela écrivons de ganzen Hives ou bien grobe RegÄnderungen serait je - égal dans quel Discours - eh pas so simple draufzu abarbeiten laisser. Quelque chose comme serait je toujours dans une Pool 1faire quel abgearbeitet wird si le air rein ist. Machs Dir alors pas trop léger!
Du sprichst arrêt très spezielle Sonderfälle à - là mag es naturellement son cela qui ProcAddr pas safe ist. Pour cet Sonderfälle la hâte Du mais comme Programmierer genügend Ausweichmethoden zur main.
Alles allez nunmal dans aucun Discours - wohlbemerkt - un safe ProcAddr peux je mir présenter wird es dans XProfan donner! |
| | | | |
| | Sebastian König | allô Andreas,
[quote-part:afe202e11c](...) c'est très grave. Überhaupt une Taskmanager trop écrivons, ist alors pas possible. Den Speicherverbrauch plusieurs Prozesse im Auge trop behalten, également pas. Vernünftige Registryeditoren tomber wohl aussi flach - au cours de on Unterschlüssel auflistet, pourrait on son Programme seulement schwer bedienbar tenir. une l'heure dans mon Programme einzublenden - allez pas. si sich cela wirklich pas avec Set(FastMode, 1) tourner autour de läßt, schmeiße je Profan lieber seulement la fois dans qui coin.[/quote-part:afe202e11c] comme Workaround peux Du oui erstmal qui aktuelle Profan2Cpp-Beta prendre . avec cela tritt qui Problematik schließlich pas sur, comment wir [...] déjà diskutiert avons...
MfG
Sebastian |
| | | | |
| | | Habe sowieso avant, mir Profan2Cpp zuzulegen. |
| | | | |
|
répondreOptions du sujet | 4.201 Views |
Themeninformationencet Thema hat 4 participant: |