| |
| |
|
| - Page 1 - |
|
Georg
Hovenbitzer | Hallo Sebastian,
ich habe mal wieder ein größeres Problem.
Der geniale folgende Code stammt vom Pascal, soetwas potuto ich mir nicht ausdenken.
Er ermittelt den Quellcode aus einem geöffneten IE Fenster, wie z.B. www.google.de.
Zum Test bitte keine grande Seite nehmen, da die Zuweisung zum Edit Feld im Beispielt noch per SetText geht.
Im Interpreter und als Profan Exe corre er super, übersezt kommt immer eine Schutzverletzung.
Die Zeile die den Fehler verursacht ist die:
Error& = CallMethod(IHTMLElement&,62,@Addr(Text&))
Der Grund ist dafür, dass der Aufruf davor von:
Error& = CallMethod(IHTMLDocument2&,9,@Addr(IHTMLElement&))
Eine Error& Nummer <> 0 zurückt gibt und IHTMLElement&, gleich 0 ist.
Könnte dieses Problem des Übersetzen sein ?
KompilierenMarkierenSeparieren $H D:PrivatProfanXProfan9INCLUDEWindows.ph
---------------Umwandlung String > globally unique identifier
Proc StringToGUID
Parameters GUID$,GUID&
Declare Temp$
Temp$ = @Space$(80)
~MultiByteToWideChar(1,1,@Addr(GUID$),-1,@Addr(Temp$),80)
@External("ole32","CLSIDFromString",@Addr(Temp$),GUID&)
EndProc
-----------------------------------------------------------------------
--------------------------Methode eines COM-Interfaces aufrufen
Proc CallMethod
Parameters IFace&,Method&
Declare VTable&
VTable& = @Long(IFace&,0)
Method& = @Long(VTable&,(Method& * 4))
Case %PCount = 2 : Return @Call(Method&,IFace&)
Case %PCount = 3 : Return @Call(Method&,IFace&,@&(3))
Case %PCount = 4 : Return @Call(Method&,IFace&,@&(3),@$(4))
Case %PCount = 5 : Return @Call(Method&,IFace&,@&(3),@&(4),@&(5))
EndProc
-----------------------------------------------------------------------
----------WideChar (UniCode) zu MultiByte (Ansi) [nur OLE!]
Proc OLE_WideToMulti
Parameters Text&
Declare Text$,Size&,Text#
Size& = @External("oleaut32","SysStringLen",Text&)
Dim Text#,Size&
Clear Text#
~WideCharToMultiByte(0,0,Text&,-1,Text#,Size&,0,0)
@External("oleaut32","SysFreeString",Text&)
Text$ = @String$(Text#,0)
Dispose Text#
Return Text$
EndProc
-----------------------------------------------------------------------
------------------------------EnumChildProc---------------------------
Proc EnumChildProc
Parameters wnd&
Declare Name#
Dim Name#,255
~GetClassName(wnd&,Name#,255)
Case @String$(Name#,0)="Internet Explorer_Server" : IEServerWnd& = wnd&
Dispose Name#
Return 1
EndProc
---------------------------------------------------------------------------------
--------------------------RunningIE_GetText-----------------------
Proc RunningIE_GetText
Parameters IEHwnd&
Declare Error&,IID#,Msg&,Result&,oleacc&,IHTMLDocument2&,IHTMLElement&,Text&,Text$,Url&,Url$
Dim IID#,16
Declare IEServerWnd&
~EnumChildWindows(IEHwnd&,@ProcAddr(EnumChildProc,2),0)
@ProcAddr(EnumChildProc,-2)--ProcAddr freigeben
Print "IEServerwnd&",IEServerWnd&
Print
Msg& = ~RegisterWindowMessage("WM_HTML_GETOBJECT")
Print "msg",Msg&
Print
Error& = ~SendMessageTimeout(IEServerWnd&,Msg&,0,0,~SMTO_ABORTIFHUNG,1000,@Addr(Result&))
Print "Error SendMessageTimeout",Error&
Print "Result SendMessageTimeout",Result&
@External("ole32","CoInitialize",0)
oleacc& = @UseDLL("oleacc.dll")
Print "oleacc",oleacc&
Print
StringToGUID("{332c4425-26cb-11d0-b483-00c04fd90119}",IID#)--IID_IHTMLDocument2
Error& = @External("oleacc","ObjectFromLresult",Result&,IID#,0,@Addr(IHTMLDocument2&))
Print "Error ObjectFromLresult",Error&
Print "IHTMLDocument2",IHTMLDocument2&
FreeDLL oleacc&
Error& = CallMethod(IHTMLDocument2&,9,@Addr(IHTMLElement&))--IHTMLDocument2::get_body
Print "Error IHTMLDocument2::get_body",Error&
Print "IHTMLElement",IHTMLElement&
Print
----------------------------------------------Quelltext ermitteln
Error& = CallMethod(IHTMLElement&,62,@Addr(Text&))--IHTMLElement::get_outerHTML
Print "Error IHTMLElement::get_outerHTML",Error&
Print "Result get_outerHTML",Text&
Print
Text$ = OLE_WideToMulti(Text&)
-------------------------------------------------------URL ermitteln
Error& = CallMethod(IHTMLDocument2&,40,@Addr(Url&))--IHTMLElement::get_URL
Print "Error IHTMLElement::get_URL",Error&
Print "Result get_URL",URL&
Print
Url$ = OLE_WideToMulti(Url&)
Print "URL = ";Url$
Dispose IID#
@External("ole32","CoUninitialize")
Return Text$
EndProc---------------------------------------------------------------------------------
Window 0,0-800,600
Declare Fenster&
Declare Edit&
Declare Quell$
Declare IEServerWnd&
Fenster& = ~FindWindow("IEFrame",0)--Hier könnte man auch andere Möglichkeiten nehmen,
IfNot Fenster&---------------------z.B. Suche nach Fenstertitel.
Print "Bitte IE starten!!"------Benötigt wird das gewünschte Hauptfenster des IE!
WaitInput
End
EndIf
Quell$ = RunningIE_GetText(Fenster&)
If @Len(Quell$)
Edit& = @Create("multiedit",%hwnd,"",300,20,450,500)----Text anzeigen
SetText Edit&,Quell$
EndIf
'./../../funktionsreferenzen/xprofan/waitkey/'>WaitKey
End
|
|
| |
| Viele Grüsse, Georg Hovenbitzer(Windows XP Pro, XProfan 11.2, Profan2Cpp 1.6a) | 17.05.2006 ▲ |
|
| |
|
| |
| |
| - Page 2 - |
|
|
Georg
Hovenbitzer | Hallo Sebastian,
gibt es eine Möglichkeit die CPP Source manuell so zu ändern wie es später per Schalter sein wird.
Da es ja doch so ein paar Probleme gibt (DLL müssen per UseDLL geladen werden, urlmon.dll funktioniert mit manchen Links nicht mehr, Hotkeys gehen nicht) würde ich dies gerne mal versuchen. |
|
| |
| Viele Grüsse, Georg Hovenbitzer(Windows XP Pro, XProfan 11.2, Profan2Cpp 1.6a) | 24.05.2006 ▲ |
|
| |
|
|
Michael
Wodrich | Das Set(...,x) war schon gut - nur sollte es halt vom Präprozessor abgearbeitet werden.
Wenn XPSE jetzt so einen erweiterbaren Befehl bekäme, dann könnten auch alle von Profan nicht verstandenen XPSE-Befehle da hinein.
$Set(XPSE,cx)
$Set(P2CPP,external_on)
$Set(P2CPP,call_on)
Es hatte mich schon öfter gestört, daß ich ein mit XPSE getestetes Programm erst nachbearbeiten muß wenn es mal ohne XPSE aufgerufen wird (vorausgesetzt es ist nichts XPSE-spezifisches drin).
Dann muß ich immer erst die XPSE-Direktive auskommentieren.
Wenn XPSE das circa Kommentare löst, dann corre es auch so. Und da XPSE zur Kompatibilität sagt: es corre immer nur mit der neuesten XProfan-Version potuto man hier doch mal eine Umstellung vornehmen.
Damit ist dann ausschließlich ein Kommentar der mit $Set( beginnt, zu ignorieren - und dieser kann dann sogar speziell koloriert werden.
Schöne Grüße
Michael Wodrich |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 24.05.2006 ▲ |
|
| |
|
|
Michael
Wodrich | [quote:c61d21d565]
[quote:c61d21d565]
Warum also nicht
Set(P2CPP:...,1)
[/quote:c61d21d565]
2. XProfan würde eine solche Anweisung mit Unbekannter Schalter: P2PP... quittieren...
[/quote:c61d21d565]
Nein, iF meinte den neuen Befehl von XProfan10:
KompilierenMarkierenSeparieren
Nur mal so zum Verständnis.
Schöne Grüße
Michael Wodrich
Wobei mir gerade auffällt, das XPSE die neuen Befehle ja alle noch beigebracht werden müssen. Eine gute Gelegenheit per den Präprozessor-Schalter... |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 24.05.2006 ▲ |
|
| |
|
|
 | [quote:25d48ad347]Wobei mir gerade auffällt, das XPSE die neuen Befehle ja alle noch beigebracht werden müssen. Eine gute Gelegenheit per den Präprozessor-Schalter...[/quote:25d48ad347]
Einige 10er habe ich dem XPSE schon beigebracht - ich bemühe mich auch das der Rest nicht so lange auf sich warten lässt.  |
|
| |
| |
| |
|
|
| @Sebastian: Ich meine nur das Kommentare auch solche sein bleiben sollten. Ich glaub man potuto irre werden wenn man nun auch darauf achten sollte was die Comments beinhalten. Ne ne, Rems mit Bedeutung - das find ich garnicht gut!
Ich glaube eine andere Lösung muß her, und das nicht deshalb weil ich dem XPSE beibringen müsste die Comments zu parsen. |
|
| |
| |
| |
|
|
Sebastian
König | [quote:4dc4baa0c2]gibt es eine Möglichkeit die CPP Source manuell so zu ändern wie es später per Schalter sein wird.
Da es ja doch so ein paar Probleme gibt (DLL müssen per UseDLL geladen werden, urlmon.dll funktioniert mit manchen Links nicht mehr, Hotkeys gehen nicht) würde ich dies gerne mal versuchen.[/quote:4dc4baa0c2]
ja - klar  Ist aber etwas mühsam: Alle External und Call zwischen den Schaltern müssten in External_ST bzw. Call_ST geändert werden... |
|
| |
| |
| |
|
|
Michael
Wodrich | Und wie wäre es dann hiermit?
$DEFINE Name: setzt eine Bedingung
$UNDEF Name: setzt eine Bedingung zurück
Das ist doch sowieso ausschließlich Futter per die Präcompiler. Hier kann Sebastian dann den entsprechenden Namen vorgeben, der verwendet werden darf, z.B.:
$DEFINE p2cpp_irgendeinschalter
Damit braucht man dann auch nichts neues zu erfinden - XProfan 10 hat es ja an Bord.
Schöne Grüße
Michael Wodrich |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 24.05.2006 ▲ |
|
| |
|
|
Sebastian
König | [quote:d6877f32d4]Das Set(...,x) war schon gut - nur sollte es halt vom Präprozessor abgearbeitet werden.
Wenn XPSE jetzt so einen erweiterbaren Befehl bekäme, dann könnten auch alle von Profan nicht verstandenen XPSE-Befehle da hinein.
$Set(XPSE,cx)
$Set(P2CPP,external_on)
$Set(P2CPP,call_on)
...[/quote:d6877f32d4]
Solange das ganze in einem Kommentar steht und somit Profan selbst nicht stört ist es ja ok - wobei ich die Syntax schon fast zu kompliziert finde... ;)
[quote:d6877f32d4]$DEFINE Name: setzt eine Bedingung
$UNDEF Name: setzt eine Bedingung zurück
Das ist doch sowieso ausschließlich Futter per die Präcompiler. Hier kann Sebastian dann den entsprechenden Namen vorgeben, der verwendet werden darf, z.B.:
$DEFINE p2cpp_irgendeinschalter[/quote:d6877f32d4]
Eigentlich eine schöne Idee - aber leider auch nicht abwärtskompatibel zu älteren Profan-Versionen  |
|
| |
| |
| |
|
|
Sebastian
König | [quote:d01220718e]@Sebastian: Ich meine nur das Kommentare auch solche sein bleiben sollten. Ich glaub man potuto irre werden wenn man nun auch darauf achten sollte was die Comments beinhalten. Ne ne, Rems mit Bedeutung - das find ich garnicht gut![/quote:d01220718e]
Das sehe ich wirklich anders - und es gibt mit dem #!/bin/sh auch ein recht bekanntes Beispiel per eine Kommentar-Zeile mit Bedeutung! 
Ich finde auch, man sollte das ganze nicht überbewerten: Es geht hier wirklich um eine sehr spezielle Situtation, nämlich um die Beeinflussung der Übersetzung von External(), Call() per ganz bestimmte Teile des Codes - womöglich wird das außer Georg in diesem Fall nichtmal jemand benötigen... In so gut wie allen Fällen ist die ganz normale Übersetzung dieser Funktionen ja völlig in Ordnung!
Wenn man dies bedenkt, ist das mit den Kommentaren wirklich die schönste Möglichkeit, die mir so einfällt... |
|
| |
| |
| |
|
|
Michael
Wodrich | Und wenn man bei diesen Spezialkommentaren bestimmt, daß davor kein Befehl stehen darf - also nach beliebigen Whitespaces folgt das Kommentarzeichen mit dem Spezialbefehl - dann läßt sich das auch entsprechend herausfiltern (Kommentare gehen ja bis zum Zeilenende).
Es ist dann ja immer auf einer Zeile per sich.
Ich sehe das auch als einzige Möglichkeit per die Abwärtskompatibilität - und die hat sich P2CPP ja auf die Fahne geschrieben.
Schöne Grüße
Michael Wodrich |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 24.05.2006 ▲ |
|
| |
|
|
Georg
Hovenbitzer | [quote:fec088bf63]ja - klar Ist aber etwas mühsam: Alle External und Call zwischen den Schaltern müssten in External_ST bzw. Call_ST geändert werden...[/quote:fec088bf63]
Hallo Sebastian,
wenn ich es richtig verstanden habe, muss ich doch nur die Aufrufe die den Fehler verursachen mit .._ST versehen und keine define setzen.
Wenn dies stimmt sind es nicht so viele  |
|
| |
| Viele Grüsse, Georg Hovenbitzer(Windows XP Pro, XProfan 11.2, Profan2Cpp 1.6a) | 24.05.2006 ▲ |
|
| |
|
|
Sebastian
König | Hallo Georg,
[quote:e363eebe1e]wenn ich es richtig verstanden habe, muss ich doch nur die Aufrufe die den Fehler verursachen mit .._ST versehen und keine define setzen.
Wenn dies stimmt sind es nicht so viele [/quote:e363eebe1e]
ja, aber damit der Thread-Kontext immer stimmt, solltest Du sicherheitshalber alle Aufrufe in der Prozeur Runningie_gettext anpassen.
MfG
Sebastian |
|
| |
| |
| |
|
(855)
Deutsch
English
Français
Español
Italia