Notepad++ in die eigene GUI einbinden

busgi

Aktives Mitglied
Hallo zusammen,

wie schon am Titel gelesen, frage ich mich ob man zb. Notepad++ in die eigene GUI einbinden kann.
Sprich, ich möchte Notepad++ in meiner eigenen GUI benutzen und nicht das Programm separat öffnen.

Grüße
Büsra
 
Wenn du irgendwie an OLE (so hiess doch mal eine Technik von Windoof, oder?) dafür kommst, könntest du den abenteuerlichen Versuch unternehmen, das vielleicht in eine SWT-Anwendung zu integrieren. Aber ob und wie das gehen sollte... Keine Ahnung.

.......... Eine kurze Recherche später ..........

Allerdings gibt es dazu von SWT tatsächlich etwas:
SWT nutze ja win32 (das alte Window-Toolkit von Windows), dort gibt es laut Doku tatsächlich OLE-Krimskrams: https://help.eclipse.org/neon/index...rg/eclipse/swt/ole/win32/package-summary.html

OLE - https://help.eclipse.org/neon/index...erence/api/org/eclipse/swt/ole/win32/OLE.html

OleFrame - https://help.eclipse.org/luna/index...e/api/org/eclipse/swt/ole/win32/OleFrame.html

Hier ein erwartet uraltes Beispiel (ob das noch geht - keine Ahnung):
https://www.oreilly.com/library/view/eclipse-cookbook/0596007108/ch10s10.html
http://www.java2s.com/Code/JavaAPI/org.eclipse.swt.ole.win32/newOleFrameCompositeshellintstyle.htm
https://www.eclipse.org/articles/article.php?file=Article-ActivexSupportInSwt/index.html

Viel... ähm... Spass!?
 
Wenn du irgendwie an OLE (so hiess doch mal eine Technik von Windoof, oder?) dafür kommst, könntest du den abenteuerlichen Versuch unternehmen, das vielleicht in eine SWT-Anwendung zu integrieren. Aber ob und wie das gehen sollte... Keine Ahnung.

.......... Eine kurze Recherche später ..........

Allerdings gibt es dazu von SWT tatsächlich etwas:
SWT nutze ja win32 (das alte Window-Toolkit von Windows), dort gibt es laut Doku tatsächlich OLE-Krimskrams: https://help.eclipse.org/neon/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/ole/win32/package-summary.html

OLE - https://help.eclipse.org/neon/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/ole/win32/OLE.html

OleFrame - https://help.eclipse.org/luna/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/ole/win32/OleFrame.html

Hier ein erwartet uraltes Beispiel (ob das noch geht - keine Ahnung):
https://www.oreilly.com/library/view/eclipse-cookbook/0596007108/ch10s10.html
http://www.java2s.com/Code/JavaAPI/org.eclipse.swt.ole.win32/newOleFrameCompositeshellintstyle.htm
https://www.eclipse.org/articles/article.php?file=Article-ActivexSupportInSwt/index.html

Viel... ähm... Spass!?



Hmm, ich mache das ganze mit JavaFX.
Schade das es echt wenig und/oder gar keine Infos und Möglichkeiten gibt 🙁
Das hätte meine GUI "verschönert"

Aber vielen Dank für die Hilfe 🙂
 
SWT nutze ja win32 (das alte Window-Toolkit von Windows)
Naja, "win32" ist kein "altes Window-Toolkit" sondern die Bezeichnung für die Gesamtheit der nativen System-Funktionen von Windows, die selbstverständlich mit jedem Service-Release und jeder neuen Major-Version von Windows ständig weiterentwickelt werden. Win32 ist also der Grundbaustein von allem, was unter Windows läuft, das betrifft nicht nur Windowing-Toolkit sondern alles, Filesystem-Zugriffe, Socket-Schnittstellen, Ansteuerung von Drucker, ...hastenichgesehn. Der Object Linking and Embedding Teil davon, ja, der ist alt.
Der Begriff "win32" ist jetzt einfach zu einem Kürzel geworden, um jene Variante einer Cross-Plattform-Bibliothek oder Anwendung zu bezeichnen, die unter Windows läuft. Andere Varianten sind dann z.B. "macos" oder "linux" oder auch unterschiedliche Windowing-Toolkit-Varianten unter Linux wie "linux-gtk" oder "linux-gtk3" wie es bei SWT üblich ist.
 
@httpdigest Ok und danke für die Ausformulierung. Was ich konkret meinte, ist, das Eclipse mal kurz WPF unterstützte, aber noch nie Richtung UWP geschaut hat. Ich meine damit also eher die GUI-Toolkits, die auf win32 aufsetzen. Das, was die Eclipse Foundation für SWT verwendet, ist ziemlich Low Level und... veraltet. Daher meine Bemerkung bzgl. des Alters.

@busgi Vielleicht mal etwas Vorweg: JavaFX ist, wie Swing - und im weiteren Sinne auch diverse Frameworks für Hybrid-App-Entwicklung für mobile Geräte, in erster Linie plattformunabhängig. Das heisst, es geht darum, mit einer Code-Basis eine indentisch aussehenden Anwendung auf verschiedene Plattformen zu bringen. (Das da jetzt natürlich am Ende ein plattformspezifischer Renderer existiert, steht auf einem anderen Blatt, aber bei Java ging es stehts darum, einen Code überall laufen zu lassen, nicht ob die Runtime darunter selbst nicht doch nativen Kram machen muss.)
Daher ist es schwierig, native Komponenten (z.B. OLE/ActiveX) in so eine Anwendung zu integrieren. Im Moment z.B. gibt es bei der Cross-Plattform-App-Lösung Flutter einiges an arbeiten am Unterbau, um genau das zu unterstützen. Bei JavaFX steht das IMHO nicht auf der Roadmap.
Bei SWT dagegen geht das, da SWT "nur" eine plattformunabhängige Abstraktion vom darunterliegenden Toolkit (win32 auf Windows, Cocoa auf Mac (glaub ich) und GTK 2/3 auf Linux) darstellt. Was man bei SWT also am Ende bekommt ist eine mit Java angesteuerte native Anwendung (von der GUI her). JavaFX und Swing dagegen bieten "lediglich" ein natives Frame (hier auch wieder platformspezifisch), dass du mit dem jeweiligen Renderer mit nicht-nativen Inhalt füllst. Sozusagen.

Aber noch etwas anderes: Du hast neulich schon gewisse Problem bei der Tabelle gehabt - die Integration nativer Komponenten setzt dem ganzen da noch einmal eins oben drauf! IMHO wäre das im Moment eh etwas zu sehr nach den Sternen gegriffen, denke ich.
 
@dzim Vielen Dank für die Aufklärung. Ich lerne das Programmieren und das Ganze drum und dran, aber es ist schon mal gut zu wissen, dass das eine Meisteraufgabe ist, sowas umzusetzen. Dann zerbreche ich mir den Kopf nicht weiter drum.
Es ist schön zu wissen, dass ich mir hier Ratschläge, Informationen und Tipps holen kann 🙂
 
Was heisst "Meisteraufgabe"? Ist IMHO unnötig, bzw. dafür sind weder Swing noch JavaFX überhaupt gedacht. Wenn du andere Programme als Teil in deiner Anwendung integriert haben möchtest, ist Java einfach nicht die beste Wahl, sondern eher etwas Platformspezifisches (Konkret hier Windows, also C# mit UWP/WPF/...)
 

Neue Themen


Zurück
Oben