Forum | | | | | 
E.T. | Mein folgendes Beispiel reagiert in der .exe anders als im Interpreter:
Interpreter :
Ich kann mit der Tab-Taste von einem Edit zum anderen hüpfen, ohne das irgendwas passiert. Komme ich in Edit 1 an, wird der Kalender aktiv, verlasse ich dieses, wird der Kalender wieder deaktiviert. Ich kann also im Edit 1 den Kalender anklicken, und das Datum (welches angeklickt wurde), wird übernommen (also ins SubClassProc gerannt, Menu 15000 gesetzt, das dann ausgewertet).
Freu, so will ich es haben !! 
In der Exe
Jedes mal, wenn der Kalender aktiviert wird (also Focus in Edit 1) wird ins SubclassProc gerannt und Menu 15000 gesetzt  (also auch gleich am Start, weil ja der Focus in Edit 1 ist).
Beim Deaktivieren des Kalenders (Focus ausserhalb Edit 1) wird nochmal ins SubClassProc gerannt und das Event ausgelöst.
Stoffwechselendprodukt !! 
Bin für jede Idee dankbar !!
KompilierenMarkierenSeparierenDeclare Element&[], Kalender&, Ende%
SubClassProc
If SubClassMessage(Kalender& , 15)Tag angeklickt
messagebox(Im SubClassProc,Info,64)...zur Information
SetMenuItem 15000
Set(WinProc, 1)
EndIf
EndProc
Proc Check_Element
If @GetFocus(Element&[1])
EnableWindow Kalender&,1
Else
EnableWindow Kalender&,0
EndIF
EndProc
Proc Kal_GetDate
Declare Datum#
dim Datum#,20
SendMessage(Kalender&,4097,0,Datum#)
Var Zurück$ = format$(00,word(Datum#,6))+.+format$(00,word(Datum#,2))+.+format$(0000,word(Datum#,0))
Dispose Datum#
Return Zurück$
ENDPROC
Window 800,600
Kalender&=Control(SysMonthCal32,Kalender,$50000000,600,0,180,height(%HWnd),%HWnd,5000,%hinstance,0)
EnableWindow Kalender&,0
Element&[0] = @Control(Dialog,,$54000000 | $00800000,0,0,400,height(%HWnd),%HWnd,5001,%HInstance,$10000)
Element&[1] = @Create(Edit,Element&[0],,10,10,200,20)
Element&[2] = @Create(Edit,Element&[0],,10,50,200,20)
Element&[3] = @Create(Edit,Element&[0],,10,100,200,20)
Element&[4] = @Create(Edit,Element&[0],,10,150,200,20)
SetFocus(Element&[1])
SubClass Kalender&,1
WhileNot Ende%
Check_Element
Waitinput
If %Key = 2
Ende% = 1
ElseIf @MenuItem(15000)
SetText Element&[1],Kal_GetDate()
EndIf
EndWhile
SubClass Kalender&,0
end
Nachtrag: Wieso werden überhaupt im Subclassproc die Messages verdreht, der Kalender löst %Message=32 aus, nur nicht im Subclassproc ??? |
| | | | Grüße aus Sachsen... Mario  WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 28.12.2008 ▲ |
| | |
| | 
Andreas
Miethe
 | IDEE !
KompilierenMarkierenSeparierenDeclare Element&[], Kalender&, Ende%
SubClassProc
If SubClassMessage(Kalender& , 15) & GetFocus(Element&[1])Tag angeklickt
SetMenuItem 15000
Set(WinProc,1)
EndIf
EndProc
Proc Kal_GetDate
Declare Datum#
dim Datum#,20
SendMessage(Kalender&,4097,0,Datum#)
Var Zurück$ = format$(00,word(Datum#,6))+.+format$(00,word(Datum#,2))+.+format$(0000,word(Datum#,0))
Dispose Datum#
Return Zurück$
ENDPROC
Window 800,600
Kalender&=Control(SysMonthCal32,Kalender,$50000000,600,0,180,height(%HWnd),%HWnd,5000,%hinstance,0)
Element&[0] = @Control(Dialog,,$54000000 | $00800000,0,0,400,height(%HWnd),%HWnd,5001,%HInstance,$10000)
Element&[1] = @Create(Edit,Element&[0],,10,10,200,20)
Element&[2] = @Create(Edit,Element&[0],,10,50,200,20)
Element&[3] = @Create(Edit,Element&[0],,10,100,200,20)
Element&[4] = @Create(Edit,Element&[0],,10,150,200,20)
SetFocus(Element&[1])
SubClass Kalender&,1
WhileNot Ende%
Waitinput
If %Key = 2
Ende% = 1
ElseIf @MenuItem(15000)
SetText Element&[1],Kal_GetDate()
SetFocus(Element&[1])
EndIf
EndWhile
SubClass Kalender&,0
end
|
| | | | Gruss Andreas ________ ________ ________ ________ _ Profan 3.3 - XProfanX2 Win 95,98,ME,2000,XP,Vista - Win 7 32 / 64 Bit ASUS X93S - Intel Core I7-NVIDIA GForce 540M 8GB Arbeitsspeicher Homepage : [...]  | 28.12.2008 ▲ |
| | |
| |
E.T. | @Andreas: Danke. Jetzt wird aber der Kalender nicht mehr deaktiviert 
Bei mir im richtigen Proc ist das wichtig, dort werden auch noch div. Buttons und Menü-Eintrage disabled. |
| | | | Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 28.12.2008 ▲ |
| | |
| | 
Sascha
Oliver
Haak | In Deinem Code habe ich den Focus von Element&[1] genommen.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ändern
Proc Check_Element
If @GetFocus(Element&[1])
EnableWindow Kalender&,1
Else
EnableWindow Kalender&,0
@SetFocus(Element&[2]) Focus von Element&[1] weg nehmen
EndIF
EndProc
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Ende ändern
Habe auch IDEE gehabt.! 
Wenns passt bitte schön!
Gruß
Sascha |
| | | | | | |
| |
E.T. | @Sascha:  , Nur sagt mir meine Logik, das alles, was hinter dem Else steht, sowieso ausgeführt wird, wenn der Focus nicht auf [1] ist .
Deine Schleife bewirkt nur das ich immer in [2] ankomme, wenn ich nicht in [1] bin. Also komme ich dann gar nicht mehr in [3] und [4]... |
| | | | Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 28.12.2008 ▲ |
| | |
| |
Sascha
Oliver
Haak | OK hast ja recht. (Schnellschuß gleich Kurzschluß!?!?!) 
Solltest als erstes in Deiner Hauptroutine erst waitinput und dann Check_Element durchführen.
Weil sonst die Routine Check_Element den Focus sofort ermittelt.
Nach Übernahme des Datums hat das Edit Feld keinen Focus mehr und erhält diesen bei erneutem
betreten.
Besser, bei mir klappt es nun! 
Gruß
Sascha |
| | | | | | |
| |
E.T. | | | | | Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 28.12.2008 ▲ |
| | |
| |
E.T. | WORKARROUND
Ich hab jetzt in meinem Prog einfach mal hinter das Aktivieren / Deaktivieren des Kalenders ein sleep 10 gesetzt, und siehe da, jetzt funzt es auch in der .exe.
In meinem obigen Bsp. hab ich das ganze bis sleep 2000 getrieben, ohne Wirkung (ggf. doch mal 10.000 testen). Ich vermute mal, im Interpreter läuft da einiges gewaltig langsamer ab, als in der .Exe >>> Moment (dämmer...), irgendwo hab da doch mal was gelesen, das im Interpr. irgendwas alle 30 Zeilen gecheckt wird und in der .Exe jede Zeile...nachschau  (aber erst heut Mittag).
[offtopic]So, jetzt schnell noch nen Eimer Kaffee, dann will ein TraPo voller Post-Taschen im Holzäppelgebirge an die Zusteller verteilt werden (um diese Zeit meist mit Zoll-Kontrollen  verbunden (bedingt durch die Nähe zur CZ, manchmal fahr ich direkt auf der Grenze lang) >> aber man gewöhnt sich an alles, und die Jungens (und manchmal auch hübsche Mädels) machen ja auch nur Ihren Job). Dann fix noch ne Runde schlafen...und schon kann der Tag am Mittag wieder beginnen  [/offtopic] |
| | | | Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 29.12.2008 ▲ |
| | |
| | 
Frank
Abbing | Alle 20 Zeilen.
Hm, ein Sleep 10 als Workaround halte ich immer für untauglich... |
| | | | | | |
| | 
RGH | E.T.
Moment (dämmer...), irgendwo hab da doch mal was gelesen, das im Interpr. irgendwas alle 30 Zeilen gecheckt wird und in der .Exe jede Zeile...nachschau (aber erst heut Mittag).
Umgekehrt wird ein Schuh draus: Im Interpreter wird (außer im Fast-Mode) nach jeder Zeil der Messageloop aufgerufen, in der Runtime nach jeder 20. Zeile. Deine Prozeduren nutzen Messages, also muss auch diesen Gelegenheit gegeben werden anzukommen. In diesem Fall ist das Sleep(10) also eine korrekte Lösung. (In XProfan 11 könnte stattdessen auch das undokumentierte WaitInput 1 verwandt werden.)
Gruß
Roland
Nachtrag: Die einfachste Lösung habe ich dabei natürlich übersehen: Ein Repaint macht hier auch das, was der Name vermuten lässt, da auch dieser Befehl außerhalb des Fastmode einen Messageloop auslöst. |
| | | | Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 29.12.2008 ▲ |
| | |
| |
Frank
Abbing |
Deine Prozeduren nutzen Messages, also muss auch diesen Gelegenheit gegeben werden anzukommen. In diesem Fall ist das Sleep(10) also eine korrekte Lösung.
SendMessage wartet, bis die Message auch angekommen ist. Sleep reagiert bisweilen unerwartet im Zusammenhang mit Messages, darum verwende ich in solchen Fällen:
KompilierenMarkierenSeparieren |
| | | | | | |
| |
RGH | Frank Abbing
Frank AbbingDeine Prozeduren nutzen Messages, also muss auch diesen Gelegenheit gegeben werden anzukommen. In diesem Fall ist das Sleep(10) also eine korrekte Lösung. SendMessage wartet, bis die Message auch angekommen ist. Sleep reagiert bisweilen unerwartet im Zusammenhang mit Messages, darum verwende ich in solchen Fällen: KompilierenMarkierenSeparieren
... was dem erwähnten Waitinput 1 entspricht.
Ja, SendMessage wartet, im Gegensatz zu PostMessage, bis die Message angekommen ist. Aber manche Message löst nach Quittierung weitere Messages aus, die etwa zum Neuzeichnen von Controls aufrufen. Und die warten dann auf den nächsten Messageloop.
Gruß
Roland |
| | | | Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 29.12.2008 ▲ |
| | |
|
AntwortenThemenoptionen | 1.874 Betrachtungen |
ThemeninformationenDieses Thema hat 5 Teilnehmer: |
(448)
Deutsch
English
Français
Español
Italia