dbraner Posted July 16, 2013 Share Posted July 16, 2013 Wurde eigentlich mit dem DVBViewer 5.2 das COM-Interface erweitert? Mich interessieren speziell Funktionen, um eine URL per hbbtv-Browser aufzurufen. Quote Link to comment
nuts Posted July 16, 2013 Share Posted July 16, 2013 Hätte ich mir auch gewünscht, aber die Pflege des COM-Interface war ja hauptsächlich im Aufgabenbereich von Lars und somit würde vor dem Release daran nichts kurzfristig gedreht. Mittelfristig wäre das imho schon sinnvoll. Quote Link to comment
hackbart Posted July 16, 2013 Share Posted July 16, 2013 Nein ist leider richtig, ich hatte Lars vor ein paar Wochen gefragt ob und wie man am einfachsten die Com Schnittstelle erweitern kann. Im Prinzip sind das ja nur 2 Funktionen: ShowBrowser(const Visible: Boolean) , und LoadInBrowser(const Url: Widestring). Alles andere macht die Browserklasse, sprich das Erkennen ob es sich um ein Texteingabefeld handelt was den Fokus hat bzw. die Ansteuerung der einzelnen DOM Objekte. Er hatte nur gesagt das es schon seinen Grund hat warum er da nicht wirklich oft dran herum dreht und ich hatte mich parallel dazu auch schon ein paar Mal probiert, dann aber weil ich das dazugehörige Interface ständig ab und umgeändert hatte nicht nochmal probiert. Im Prinzip könnte man überlegen eine Message zu erstellen die einen Link öffnet. Quasi sowas wie: Postmessage(DVBViewerHandle, WM_B2C2, MSG_OPENBROWSER, Longint(@PAnsiCharUrl)); Ist der lparam 0, dann wird der Browser geschlossen und hat er einen Wert, ist er nen Pointer auf einen Link. Das ist jetzt nur grob gesponnen und auch nicht wirklich schön, aber wenn z.B. die GE jemals HbbTV bekommt wird das wohl auf eine Message hinauslaufen. Quote Link to comment
nuts Posted July 16, 2013 Share Posted July 16, 2013 Ja Lars hat sich immer sehr zurückhaltend gegenüber Änderungen am COM-Interface geäußert. Das wird schon seinen Grund gehabt haben ... Im Prinzip könnte man überlegen eine Message zu erstellen die einen Link öffnet. Quasi sowas wie: Postmessage(DVBViewerHandle, WM_B2C2, MSG_OPENBROWSER, Longint(@PAnsiCharUrl)); Ist der lparam 0, dann wird der Browser geschlossen und hat er einen Wert, ist er nen Pointer auf einen Link. Das ist jetzt nur grob gesponnen und auch nicht wirklich schön, aber wenn z.B. die GE jemals HbbTV bekommt wird das wohl auf eine Message hinauslaufen. Ist jetzt aber die Frage ob man für alle zukünftigen Änderungen eine Art neue API für Post/Send Message aufbauen will. Mir würde es besser gefallen bei COM zu bleiben. Vielleicht liest hier ja auch ein COM Experte mit und kann sich zu Risiken und Nebenwirkungen äußern? Quote Link to comment
dbraner Posted July 16, 2013 Author Share Posted July 16, 2013 Ja Lars hat sich immer sehr zurückhaltend gegenüber Änderungen am COM-Interface geäußert. Das wird schon seinen Grund gehabt haben ... Ist jetzt aber die Frage ob man für alle zukünftigen Änderungen eine Art neue API für Post/Send Message aufbauen will. Mir würde es besser gefallen bei COM zu bleiben. Vielleicht liest hier ja auch ein COM Experte mit und kann sich zu Risiken und Nebenwirkungen äußern? Kann ich nicht verstehen (die Zurückhaltung). In Windows ist COM das offizielle Interface, wenn eine Anwendung ihre Dienste für andere Anwendungen bereitstellen will. Hätte gegenüber PostMessage den Vorteil, dass man es aus der Command.vbs einfach aufrufen kann. PostMessage ist eine Krücke. Dann lieber gar nicht. Das kann so viele Seiteneffekte haben, wenn man es Anwendung übergreifen verwendet. Böse. Wenn man über eine neue Schnittstelle nachdenkt, dann wäre vielleicht ein Webservice (SOA) eine praktikable Lösung. Das könnte man dann über alle Plattformen (falls es mal eine MacOS Variante gibt) und auch für den Recordingservice verwenden. Und es wäre einfach zu implementieren (selbst schon öfters gemacht), da es reichlich unterstützende Frameworks gibt. Quote Link to comment
erwin Posted July 17, 2013 Share Posted July 17, 2013 Wenn man über eine neue Schnittstelle nachdenkt, dann wäre vielleicht ein Webservice (SOA) eine praktikable Lösung. Nein bitte nicht. Nicht noch eine neue Schnittstelle auf noch einer anderen Technologie basierend. Es gibt jetzt schon der Schnittstellen zu viele: - das traditionelle Plugin-Interface - COM - das kaum dokumentierte InitPlugin2-Interface - ...(?) Wenn man nicht am vorhandene COM-Interface experimentieren will, schlage ich vor einen zweiten DVBV-COM-Server für die neuen Dinge aufzumachen. erwin Quote Link to comment
hackbart Posted July 17, 2013 Share Posted July 17, 2013 Naja mal schaun. Ich hab mal eben im Typbibliothekeditor ein Interface erstellt IHbbTV und zwei Funktionen IsAvailable bzw. LoadinBrowser, eventuell erstelle ich noch ein SetVisible und GetVisible als Property und probiere das mal aus. Mehr brauchen wir ja nicht und im Prinzip wäre das natürlich die einfachste Methode. Auf diese Weise könnte man recht leicht auf die Engine zugreifen. Ich versuche das heute mal gangbar zu machen, Lars wusste allerdings sicherlich warum er da Bauchschmerzen hatte. Ich hab die letzten Tage mehrere Dinge angefangen wo er sich etwas geweigert hat die abzuändern, gut ich war naiv und nach 8h fluchen hatte ich vieles dann so wie ich wollte. Aber bei einigen Konstruktionen hat es wohl seinen Sinn das sowohl Lars als auch ich nicht freiwillig dran herumfuhrwerkt haben. Christian Quote Link to comment
hackbart Posted July 23, 2013 Share Posted July 23, 2013 Erwin hat es schonmal vorab testen können und ich poste das mal hier, damit es nicht untergeht. Eigentlich habe ich mich mit jeder Faster gesträubt an der Com Schnittstelle zu drehen und diese zu Erweitern, im Nachhinein hattes es jedoch mehr Vorteile als Nachteile. So weiß ich wieder warum wir das so selten gemacht haben, allerdings weiß auch auch wieder wie man das unter Umständen dennoch mit etwas Aufwand relativ schnell realisieren kann. Die nächste Version hat ein weiteres Interface. Über das kann man Webseiten laden und diese anzeigen: Dim DVBViewer Set DVBViewer = GetObject(, "DVBViewerServer.DVBViewer") DVBViewer.HbbTV.LoadInBrowser "www.spiegel.de", 0 DVBViewer.HbbTV.Visible = 1 Was jedoch etwas ungünstig ist sind Popups. Diese werde ich wohl generell deaktivieren, denn es gibt so finde ich nix schlimmeres als wenn man eine Seite mit der Fernbedienung öffnet und auf einmal irgendwelche Extrafenster aufpoppen außerhalb der Anzeige und einem so den Spaß vermiesen. Quote Link to comment
dbraner Posted July 23, 2013 Author Share Posted July 23, 2013 Vielen Dank für die Implementierung! Die Unterdrückung von Popups finde ich gut (wegen Eingabefokus), auch wenn sie für meinen Anwendungsfall (Darstellung einer selbst erstellten Seite vom NAS oder meiner Wetterstation) keine Rolle spielt. Ich gehe davon aus, dass die dargestellten Webseiten dem - im Vergleich zu HTML 4 oder 5 eingeschränkten - CE-HTML bzw. XHTML 1.0 Standard entsprechen müssen, oder? Quote Link to comment
dgdg Posted July 26, 2013 Share Posted July 26, 2013 Wenn man über eine neue Schnittstelle nachdenkt, dann wäre vielleicht ein Webservice (SOA) eine praktikable Lösung. Das könnte man dann über alle Plattformen (falls es mal eine MacOS Variante gibt) und auch für den Recordingservice verwenden. Und es wäre einfach zu implementieren (selbst schon öfters gemacht), da es reichlich unterstützende Frameworks gibt. Da wäre ich 100%ig dafür. Damit man endlich aus dem proprietären Windows-Käfig rauskommt. Jeder App-Programmierer baut sich mühsam sein eigenes COM<->TCP/IP Gateway (habe ich auch gemacht) oder nutzt den sehr eingeschränkten DVBViewer-Webserver oder den Recording Service. Das schränkt den Kreis der Addon-Programmierer (die sich sowas noch antun wollen) drastisch ein. Viele plattformübergreifende Programmierumgebungen unterstützen überhaupt kein COM. Selbst unter DOT.NET läuft's nur über "Interop". Die Sicht, dass alle Addons auf der gleichen physikalischen Maschine laufen müssen, ist einfach nicht mehr zeitgemäß. Deswegen kommunizieren ja schon DVBViewer und Recording Service über einer (leider proprietäre) Web-API. Ich plädiere nicht für noch eine neue Schnittstelle, sondern für eine Harmonisierung der Schnittstelle. Eine Schnittstelle, mit der man alles erschlägt und nicht für jeden Zweck wieder eine neue Schnittstelle. Quote Link to comment
Tjod Posted July 26, 2013 Share Posted July 26, 2013 Ich gehe davon aus, dass die dargestellten Webseiten dem - im Vergleich zu HTML 4 oder 5 eingeschränkten - CE-HTML bzw. XHTML 1.0 Standard entsprechen müssen, oder? Da CEF1 verwendet wird sollten normale Webseiten gehen. Aber für Seiten mit Interaktion sollte man was mit der unterstüzung für die Fernbedieungs Tasten basteln Quote Link to comment
hackbart Posted July 27, 2013 Share Posted July 27, 2013 Ja, Tjod hat recht es gehen alle normalen Webseiten auch. Vorhin hab ich spaßenshalber Quake3 WebGL Port getestet und war überrascht wie gut das lief - insbesondere da in dem Fall quasi so die Anzeige gerendert wird WebGL->Framebuffer->D3D Texture oder GDI+. Der Anwendungsfall Ist natürlich etwas an den Haaren herbeigezogen, aber es funktioniert problemlos. Das gilt natürlich auch für Flash Wermutstropfen dabei ist das natürlich die Tasteneingaben nicht gehen. Bei Textfeldern wird eine virtuelle Tastatur geöffnet und ich schreibe den Value-Wert des aktiven Elements. Leider kann ich das nicht direkt via CEF machen, sondern muss da ein Javascript injecten, aber macht ja für den Nutzer keinen Unterschied. Quote Link to comment
dbraner Posted August 6, 2013 Author Share Posted August 6, 2013 (edited) Eine Verständnisfrage: Wenn ich bei aktiver Darstellung einer Webseite das Flag HbbTV.Visible = 0 setze, wird die Webseite geschlossen. Wird dann auch das Plugin beendet oder läuft das im Hintergrund weiter? Und wenn es weiterläuft: ist das ein Problem (Ressourcen mäßig)? Könnte man eine Action implementieren, die hbbtv beendet? Das würde mein Problem lösen, dass beim ersten Aufruf von OSD-Menu erst das Menü kommt und beim 2. Aufruf dann hbbtv bzw. das Browser-Fenster beendet wird. Und gleich noch eine Frage: Wenn ich mit LoadInBrowser www.youtube.com/tv aufrufe und ein Video abspiele (was sehr gut klappt) bleibt der Ton vom TV hörbar, was zusammen mit dem Youtube Ton ziemlich bescheiden klingt. Kann man den TV Ton beim Aufruf einer Webseite separat deaktivieren? EDIT: Gelöst. Schicke vor dem Aufruf ein DisableAudio und beim Schließen der Webseite EnableAudioVideo. Hier mal der Code aus meiner Command.vbs If HbbTV.Visible = 0 Then SendCommand (16385) HbbTV.LoadInBrowser "http://www.youtube.com/tv", 0 HbbTV.Visible = 1Else HbbTV.Visible = 0 SendCommand (16388)End IfUnd hier noch ein Tipp, wie man die Youtube-Anzeige auf dem TV mit einem iPhone oder iPad steuert: https://support.google.com/youtube/answer/2523964?hl=de-DE Gefällt mir immer besser, das hbbtv Plugin. Edited August 7, 2013 by dbraner Quote Link to comment
nuts Posted August 10, 2013 Share Posted August 10, 2013 Schaut mal hier: http://www.DVBViewer.tv/forum/topic/52993-idvbviewer2epgmanager2importepg-fails-with-527/#entry392755 Meinungen dazu? Quote Link to comment
dbraner Posted August 10, 2013 Author Share Posted August 10, 2013 (edited) Ein neues Interface sollte kein Problem sein. Microsoft macht das seit Jahren so,z.B. beim COM Interface des Internet Explorers. Ich glaube, die sind schon bei IHTMLDocument5 angekommen. Wichtig ist nur, dass das neue Interface die alten enthält. Sonst wirds umständlich. Ach ja, die command.vbs sollte dann natürlich im Kontext des IDVBViewer3 Interfaces laufen. Sonst wars das mit dem Aufrufen von Webseiten. Edited August 10, 2013 by dbraner Quote Link to comment
Delphi Posted August 30, 2013 Share Posted August 30, 2013 Hi Hackbart If you make an IDVBViewer3 interface, I suggest that you in addition to the HbbTV interface adds something like function GetInfo(OutCommandID: integer): WideString; procedure SetInfo(InCommandID: integer; const Info: WideString); For now they should do nothing (GetInfo should return an empty string). It is not very elegant but pretty efficient and could be used to avoid having to make an IDVBViewer4 interface some time in the future. Just my 2 cents. I am certainly not a COM Expert, but I know that Lars actually did struggle a bit when he created the IDVBViewer2 interface. It's probably not that easy! Quote Link to comment
dbraner Posted August 30, 2013 Author Share Posted August 30, 2013 What would be the advantage of these 2 functions? A generic interface for writing or reading data? Quote Link to comment
hackbart Posted August 30, 2013 Share Posted August 30, 2013 Since we did not published a new version and especially since i had to make a few modifications according to the interface I'm open for suggestions which could be added. The reason for the changes are explained here: http://www.DVBViewer.tv/forum/topic/52993-idvbviewer2epgmanager2importepg-fails-with-527/. A possible add on could be something like a colorkey property and i'm still thinking of something like a GetUrl which returns the current html page or frame. A SaveAsImage might be also quite cool for automated screenshots. Anyhow i'm open for suggestions Quote Link to comment
Delphi Posted August 30, 2013 Share Posted August 30, 2013 (edited) @dbraner: Yes to your last question. It is meant as a sort of extended SendCommand, which has proven to be very usefull for increasing functionallity without having to define new interfaces. Personally I might at some time want to manipulate the channel list (epgflag). The string could then be the channellist as XML as you get it from the Recording Service. I should then post a request at that time. It is not likely that such a request would be anticipated if it involves extending COM with new interfaces. @Hackbart: Great that you will consider. Since the SetInfo (or whatever you want to call it) can fail I now think it is better to make it a function (True means succes ofcource), maybe something like: function GetInfo(OutCommandID: integer): WideString; function SetInfo(InCommandID: integer; const Info: WideString): WordBool; Edited August 30, 2013 by Delphi Quote Link to comment
dbraner Posted August 30, 2013 Author Share Posted August 30, 2013 I think the idea of Delphi is very helpful: 2 functions that communicate with DVBViewer by sending and receiving xml formated data. Will be easy to write a wrapper soap interface. Quote Link to comment
Delphi Posted August 30, 2013 Share Posted August 30, 2013 I think the idea of Delphi is very helpful: 2 functions that communicate with DVBViewer by sending and receiving xml formated data. Will be easy to write a wrapper soap interface. That the data is XML was meant as an example only, could be anything. I don't think a whole new communication method like you suggest is wanted, at least not for me and it would require at lot of coding by Hackbart. Well, it keeps a door open for that and for allmost anything else you can think of. Quote Link to comment
dgdg Posted August 31, 2013 Share Posted August 31, 2013 That the data is XML was meant as an example only, could be anything. I don't think a whole new communication method like you suggest is wanted, at least not for me and it would require at lot of coding by Hackbart. Why use "anything" if there is a standard like XML? I vote for SOAP! I think it is essential to have a new Windows independent interface to communicate over LAN and Internet - with smartphones and tablets. Quote Link to comment
Delphi Posted August 31, 2013 Share Posted August 31, 2013 @dgdg: You can have both (SOAP and "Anything"). It's just a question of defining a range of integer constants for the InCommandID and OutCommandID to be used for SOAP, rest is free for "anything". Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.