Jump to content
dbraner

Erweiterung COM Interface mit DVBViewer 5.2

Recommended Posts

dbraner

Wurde eigentlich mit dem DVBViewer 5.2 das COM-Interface erweitert? Mich interessieren speziell Funktionen, um eine URL per hbbtv-Browser aufzurufen.

 

Share this post


Link to post
Tjod

Nein

Share this post


Link to post
nuts

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.

Share this post


Link to post
hackbart

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.

Share this post


Link to post
nuts

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?

Share this post


Link to post
dbraner

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.

Share this post


Link to post
erwin

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

Share this post


Link to post
hackbart

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

Share this post


Link to post
hackbart

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.

 

Share this post


Link to post
dbraner

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?

Share this post


Link to post
dgdg

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.

Share this post


Link to post
Tjod

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

Share this post


Link to post
hackbart

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.

 

flash.jpg

 

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.

Share this post


Link to post
dbraner

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 = 1
Else
HbbTV.Visible = 0
SendCommand (16388)
End If

Und 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 by dbraner

Share this post


Link to post
dbraner

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 by dbraner

Share this post


Link to post
Delphi

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!

Share this post


Link to post
dbraner

What would be the advantage of these 2 functions? A generic interface for writing or reading data?

Share this post


Link to post
hackbart

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 ;)

Share this post


Link to post
Delphi

@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 by Delphi

Share this post


Link to post
dbraner

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.

Share this post


Link to post
Delphi

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.

Share this post


Link to post
dgdg

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! :thumbsup:

I think it is essential to have a new Windows independent interface to communicate over LAN and Internet - with smartphones and tablets.

Share this post


Link to post
Delphi

@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". ;)

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...