WebGadget als Ersatz für native GUI

[X0r]

@kiffi: Danke für deinen Beitrag. Das klappt leider nicht. Aber da gibt es sicher einen Weg über die WinAPI.

@Shardik: auch dir ein Dankeschön für deine Mühe.


Ich habe mir neulich nun weitergehende Gedanken über die Kommunikation mit dem WebGadget gemacht. Ein bestehendes Problem war noch, dass ich nicht so recht wusste, wie ich Benutzereingaben innerhalb des WebGadgets (z. B. in Formularfelder) ermitteln kann.
Diesbezüglich habe ich mir nun folgenden Ansatz überlegt:

1) Aufruf einer JavaScript-Funktion wie gehabt über einen URL-Aufruf: SetGadgetText(WebGadget,"javascript: GetInputData()")

2) Die JavaScript-Funktion GetInputData() kann nun bequem beliebige Daten in Eingabefeldern ermitteln.

Fragt sich nun, wie ich an diese Daten innerhalb meiner Anwendung komme. Die Lösung:

3) Innerhalb der GetInputData()-Funktion kann man wiederum eine URL aufrufen ( document.location.href = "..."). Diese kann ich über einen CallBack abfangen und parsen. Die Daten werden also über die URL übergeben.

Diese Möglichkeit erscheint mir derzeit recht gut. Ich werde das Ganze aber erst mal sacken lassen und mir nochmals Gedanken darüber machen, ob ein WebGadget letztlich die beste Option darstellt.

[RSBasic]

Ich werde das Ganze aber erst mal sacken lassen und mir nochmals Gedanken darüber machen, ob ein WebGadget letztlich die beste Option darstellt.

Das meinte ich doch. Du musst erstmal Workarounds bauen, um überhaupt mit der eigentlichen Grundfunktion deiner Design-Vrwaltung anfangen zu können. Du hättest schon längst deine Benutzeroberfläche bauen können und du wärst inzwischen viel weiter.
WebGadget ist nicht dafür geeignet. Man kann es zwar umbiegen und Workarounds schreiben, aber ob sich der ganze Aufwand lohnt, obwohl es mit anderen Schnittstellen viel einfacher, schneller und effektiver geht?
Ich empfehle dir, mit der Arbeit an WebGadget sofort aufzuhören, um unnötige weitere Probleme, die zusätzlich Zeit kosten, zu vermeiden, und lieber eine andere bessere Lösung in Anspruch zu nehmen.

[TroaX]

Oder man baut den Atomic ein. URL's haben laut Spezifikation eine begrenzte Größe, was die Möglichkeiten stark einschränkt. Den Atomic kann man in einem zweiten Thread laufen lassen und man kann mit nahezu unbegrenztem Umfang mit dem Backend kommunizieren!

[mk-soft]

Dann ist der Weg einer Multi-Client-Server Anwendung auch nicht mehr weit...

[TroaX]

Dann ist der Weg einer Multi-Client-Server Anwendung auch nicht mehr weit...

Wenn es denn auch gewünscht ist ... wobei da doch noch um einiges mehr dran hängt.

[PMV]

Wenn du jetzt schon das Webgadget in Frage stellst, sollteste nen großen Bogen darum machen
... für Webentwickler gab es nix schlimmeres, als alte IE-Versionen zu unterstützen. Selbst wenn
das ganze erst mal läuft, wirst du noch den Tag verfluchen, an dem du dich entschieden hast,
damit zu arbeiten.


Ich weis jetzt nicht, was genau du machen möchtest, aber die Engine von Webbrowsern zu verwenden,
um damit eine hübsche und flexible GUI zu erstellen ist nicht neu. Dank Chromium gibt es schon
unzähliche Anwendungen. Wenn wir irgend wann mal auf Objekt-Orientierte-DLLs direkt zu greifen
könnten, würde sich eine neue Welt eröffnen

Mal Spaß bei Seite, den Thread zu Awesomium von vor Jahren hast du doch bestimmt mit bekommen.
Wenn nicht, wäre jetzt der Zeitpunkt den mal zu überfliegen und dir Awesomium an zu schauen. In die
Richtung sollteste dich nämlich schlau machen. Neben Awesomium gibt es noch andere Bibliotheken,
die Chromium zu einer GUI für Programme umbauen. Am vielversprechensten war neben Awesomium
noch das, welches Steam nutzt. Leider hab ich den Namen grad vergessen. Evt. gibs da sogar
Unterstützung für C ... aber vermutlich wirds auch hier wie ja inzwischen auch bei Awesomium nur
ne C++-DLL ... und da wir mit PB nach wie vor nicht darauf direkt zu greifen können, brauchtss
nen Wrapper mit C/C++. Hast den aber ein mal, kannst dich ohne Grenzen austoben.

MFG PMV

[GPI]

Wenn du jetzt schon das Webgadget in Frage stellst, sollteste nen großen Bogen darum machen
... für Webentwickler gab es nix schlimmeres, als alte IE-Versionen zu unterstützen.

Man kann umstellen, das er den neuen IE benutzt.
https://msdn.microsoft.com/en-us/librar ... s.85).aspx

__________________________________________________
URL-Tags hinzugefügt
26.08.2017
RSBasic

[X0r]

Wenn wir irgend wann mal auf Objekt-Orientierte-DLLs direkt zu greifen
könnten, würde sich eine neue Welt eröffnen

Das ist doch schon lange möglich in PB (ich meine sogar, seit PB 4). Siehe Interfaces.

Ich selbst habe schon objektorientierte DLLs in PB eingebunden und es funktioniert bestens. Kopfschmerzen bereiten einem eher die mangelhafte Untersützung von nativen unsigned Datentypen. Aber dafür hat Fred ja das beste Argument...

[RSBasic]

... für Webentwickler gab es nix schlimmeres, als alte IE-Versionen zu unterstützen.

Oh ja, besonders Kunden, die in ihrem Intranet ältere Betriebssystem- und IE-Version verwenden. Quirks-Modus in modalen Dialogen war auch sehr schlimm. Es wurde zwar alles vom Auftraggeber bezahlt, aber ständige CSS-Hacks für jede Kleinigkeit zu verwenden, macht keinen Spaß.
Ist aber heute zum Glück nicht mehr so schlimm wie vor ein paar Jahren, weil auch Firmen endlich mal auf neuere Betriebssysteme wechselten.

[X0r]

... für Webentwickler gab es nix schlimmeres, als alte IE-Versionen zu unterstützen.

Das Argument kann ich nicht nachvollziehen. Troax hat ja schon eine praktikable Lösung angeboten.