C ++ Forum | | | |  Georg Hovenbitzer | allô Sebastian,
j'ai la fois wieder un größeres Problem. qui geniale folgende Code stammt vom Pascal, soetwas pourrait je Je ne ausdenken. il ermittelt den Quellcode aus einem geöffneten IE la fenêtre, comment z.B. www.google.de. Zum Test s'il te plaît aucun grand page prendre, là qui Zuweisung zum Éditer champ im Beispielt encore per SetText allez.
Im Interpreter et comme Profan Exe fonctionne il super, übersezt venez toujours une Schutzverletzung. qui la ligne qui den faute verursacht ist qui: Error& = CallMethod(IHTMLElement&,62,@Addr(Text&))
qui Grund ist pour, dass qui Aufruf devant de: Error& = CallMethod(IHTMLDocument2&,9,@Addr(IHTMLElement&))
une Error& numéro <> 0 zurückt gibt et IHTMLElement&, juste 0 ist.
Könnte cet Problem des Übersetzen son ? KompilierenMarqueSéparation $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
Fin
|
| | | Viele Grüsse, Georg Hovenbitzer(Windows XP Pro, XProfan 11.2, Profan2Cpp 1.6a) | 17.05.2006 ▲ |
| |
| |  Sebastian König | allô Georg,
merci pour den Hinweis - cela Problem tritt aussi chez mir sur - malheureusement konnte je qui Ursache encore pas feststellen ...
comment Du déjà geschrieben la hâte, schlägt qui Aufruf
Error& = CallMethod(IHTMLDocument2&,9,@Addr(IHTMLElement&))
fehl, sodass IHTMLElement& keinen gültigen Schnittstellenzeiger contient et qui Versuch, une Methode avec cela aufzurufen, zum Abstruz führt.
seulement quoi oui c'est ca là schiefläuft, c'est moi encore un Rätsel... cela CallMethod selbst ist oui encore dans Ordre, es wird seulement un faute-Cdoe retour... je werde la fois versuchen, dessen signification herauszufinden et melde mich nochmal, si je quelque chose nouveau sais...
MfG
Sebastian |
| | | | |
| |  Sebastian König | allô Georg,
qui Code steht pour RPC_E_CANTCALLOUT_ININPUTSYNCCALL. qui Beschreibung pour lautet:
un ausgehender Aufruf peux pas fonctionnement volonté, là qui Anwendung une Eingabe-synchronisierten Aufruf weiterleitet.
très komisch...
là mir sonst rien einfiel, J'ai eu irgendwie cela MultiThread-Konzept im le doute (qui idée kam mir, weil là oui angeblich irgendwas gleichzeitig stattfindet ...
Jedenfalls habe je ensuite folgendes probiert: Call() et Externe() volonté dans den traduire Programmen oui grundsätzlich im Kontext des tête-Threads fonctionnement, weil on oui nie savons peux, si irgendwie la fenêtre ou bien Controls erstellt/bearbeitet volonté... il y a cependant une Possibilité, ca trop changement: si Je l' Code zunächst seulement übersetze, alors faire.bat pas automatisch starte, et dans qui erzeugte [Projektname].cpp-Dossier (attention: pas qui PrfMain.cpp) pour den ganzen #include-Anweisungen qui beiden Zeilen
#define Externe External_ST #define Call Call_ST
einfüge, funktioniert es sur einmal...
peux Du cela bestätigen?
MfG
Sebastian
P.S.: cela ganze scheint un bekannter Windows-Bug trop son... bien possible, dass es sich oui c'est ca um cela [...] beschriebene Problem handelt. qui paragraphe Symptoms beschreibt nämlich oui c'est ca cela aktuelle Problem  |
| | | | |
| |  Georg Hovenbitzer | allô Sebastian,
deine Solution funktioniert avec dem Demo très bien 
je werde vous im laufe des Tages im Programme testen afin de voyons si là Schwierigkeiten auftreten.
S'inscrire mich ensuite ici. |
| | | Viele Grüsse, Georg Hovenbitzer(Windows XP Pro, XProfan 11.2, Profan2Cpp 1.6a) | 18.05.2006 ▲ |
| |
| |  Sebastian König | allô Georg,
malheureusement ist es très wahrscheinlich, dass cela pauschale Umstellen sur qui *_ST-Versionen dans Deinem Programme trop Problemen führt . dans qui règle ist es oui comment déjà erwähnt sogar notwendig, dass API-Funktion im Kontext des tête-Threads fonctionnement volonté, là là qui ganze Fensterverwaltung stattfindet...
j'ai inzwischen aussi la fois den sous dem Link (siehe PS dans mon Posting dessus) gegebenen Vorschlag Use Poster un message instead of à inter-process/inter-thread SendMessage. ausprobiert - aussi avec cela ist qui faute behoben.
cela blöde ist seulement: qui Alternative venez eigentlich pas dans Frage. Ursprünglich J'ai eu pour Externe() et Call() réellement PostThreadMessage() benutzt, jusqu'à irgendwann (je crois es était encore dans qui Beta-Phase avant qui Veröffentlichung de Profan2Cpp) auffiel, dass es avec cela dans Extremsituationen (très viele Aufrufe dans très court Zeit) trop Problemen venons konnte . avec dem Umstieg sur SendMessage() était ensuite alles dans Ordre et obendrein encore qui Performance quelque chose besser, là oui qui le détour sur qui Nachrichtenschleife entfiel ...
So, maintenant pour dem ganzen expliquer, quoi pas allez, la fois un Vorschlag zur Solution des Problems :
Dass es dans qui Demo avec den _ST()-Funktionen aussi chez Dir funktioniert, ist oui Schonmal super! mon concept wäre maintenant, Profan2Cpp so trop erweitern, dass avec einer speziellen Anweisung im Profan-Code automatisch pour une certain paragraphe sur qui _ST-Varianten umgeschaltet volonté peux. avec cela sich XProfan selbst pas sur unbekannte Befehle beschwert, würden sich spezielle Kommentare anbieten. dans Deinem Code pourrait es ensuite dans etwa so air: KompilierenMarqueSéparation quoi hältst Du de dem Vorschlag?
MfG
Sebastian |
| | | | |
| |  Georg Hovenbitzer | allô Sebastian,
je peux toi beruhigen 
mon Programme fonctionne eh bien sans faute, es donnais zwar un paire seltsame Effekte comment z.B. dass je alle DLL avec UseDLL magasin musste, quoi sans Übersetzen pas nötig était. Anderseits mach cela Programme aussi pas viel, es ließt den Voir le texte source qui page aus et cherchez là pour à gauche, speichert Bilder et Text Fichiers. Pour qui Zukunft wäre deine prévu Solution très vom Vorteil, là vous très léger dans den Profan Code einzubauen ist et on sich dadurch aussi pas qui Possibilité nimmt deine Plugins trop benutzen (là je encore pas herausgefunden habe comment je avec dem ResHacker Versions Informationen dans un Dossier bekomme). |
| | | Viele Grüsse, Georg Hovenbitzer(Windows XP Pro, XProfan 11.2, Profan2Cpp 1.6a) | 19.05.2006 ▲ |
| |
| |  Sebastian König | allô Georg,
si es sogar so déjà funktioniert, ist cela naturellement seulement droite super! 
qui vorgeschlagen Kommentar-commutateur werde je ensuite dans qui prochain Version einbauen - pour größtmögliche Flexibilität sogar getrennte commutateur pour Call() et Externe(), qui mais dans einer einzigen la ligne gesetzt volonté peut, z.B.
P2CPP: <USE_EXTERNAL_ST,USE_CALL_ST>
MfG
Sebastian |
| | | | |
| |  Georg Hovenbitzer | allô Sebastian,
j'ai mich quelque chose trop tôt gefreut 
j'ai dir la fois un Codebeispiel geschrieben qui malheureusement pour dem manuellen insérer de: #define Externe External_ST #define Call Call_ST pas funktioniert. cela Problem liegt daran, dass &UwParam keinen Wert plus erhält  KompilierenMarqueSéparationDef RegisterHotKey(4) !"USER32.DLL","RegisterHotKey"
Def UnregisterHotKey(2) !"USER32.DLL","UnregisterHotKey"
Declare Edit&
Window 100,100-400,400
Edit& = @Create("Edit",%hWnd,"",100,100,150,20)
UserMessages $312
RegisterHotKey(%hWnd,11111,3,80) Strg + Alt + P
WhileNot %Key = 2
WaitInput
SetText Edit&,""
DrawText 20,30,@Space$(30)
DrawText 20,20,"&UwParam = " + @Str$(&UwParam)
If ((&UwParam = 11111) And (%GetFocus = Edit&))
SetText Edit&,"TREFFER !"
EndIf
EndWhile
UnRegisterHotKey(%hWnd,11111)
UserMessages 0
Fin
|
| | | Viele Grüsse, Georg Hovenbitzer(Windows XP Pro, XProfan 11.2, Profan2Cpp 1.6a) | 23.05.2006 ▲ |
| |
| |  | Mir viel là aussi encore quoi un!
P2CPP: <USE_EXTERNAL_ST,USE_CALL_ST>
Ist imaginable mal comme Indikator - Rems devrait toujours wegoptimierbar son.
XProfan selbst hat déjà solch tollen Befehl SET 
pourquoi alors pas KompilierenMarqueSéparation je glaub cela wäre eleganter.  |
| | | | |
| |  Sebastian König | allô iF,
[quote-part:26d3b84306]XProfan selbst hat déjà solch tollen Befehl SET
pourquoi alors pas
Set(P2CPP:...,1)
je glaub cela wäre eleganter. [/quote-part:26d3b84306] cela allez malheureusement aus 2 Trouvé pas:
1. l'information muss déjà zum la date qui Übersetzung zur Disposition stehen - chez Set() ist cela malheureusement pas so, weil on oui aussi une Stringvariable benutzen pourrait... (dehalb ließ sich zum Beispiel cela @Set(ESCAPE, n%) de XProfan 9 pas richtig umsetzen ).
2. XProfan serait une solche Anweisung avec Unbekannter commutateur: P2PP... quittieren...
eh, justement fällt mir encore un:
3. Abwärtskompatibilität! Aîné Profan²-Versionen connaître gar ne...aucune Set()...
peux Du dem XPSE pas simple beibringen, chez certain Kommentaren un un peu Zurückhaltung trop üben? 
MfG
Sebastian |
| | | | |
| |  | [quote-part:a8là9240c6=Sebastian König]allô iF,
[quote-part:a8là9240c6]XProfan selbst hat déjà solch tollen Befehl SET
pourquoi alors pas
Set(P2CPP:...,1)
je glaub cela wäre eleganter. [/quote-part:a8là9240c6] cela allez malheureusement aus 2 Trouvé pas...
...peux Du dem XPSE pas simple beibringen, chez certain Kommentaren un un peu Zurückhaltung trop üben? 
[/quote-part:a8là9240c6] Ohhhh mon Gott. 
Ok, encore ne concept: p2cppcompiler$=blub  |
| | | | |
| |  Sebastian König | [quote-part:f983247403]Ohhhh mon Gott.
Ok, encore ne concept: p2cppcompiler$=blub [/quote-part:f983247403] je sais maintenant pas so entier, quoi Du meinst... 
qui Solution avec cette Kommentar-Befehlen comme mir eigentlich aussi assez bien, weil vous très flexibel ist (on pourrait sogar pour einzelne Aufrufe cela Verhalten changement), den XProfan-Interpreter bzw. Compiler pas du tout stört et gar keinen unnötigen Overhead erzeugt...  |
| | | | |
|
répondreOptions du sujet | 6.750 Views |
Themeninformationencet Thema hat 4 participant: |