Hallo,
eine DLL-Methode benötigt als Argument ein Fenster-Handle, jedoch ist meine Anwendung lediglich eine Konsolenanwendung.
Welche Möglichkeiten habe ich jetzt, um der Methode ein HWND bereitszustellen, denn bei NULL bekomme ich eine Schutzverletzung.
Vielen Dank schonmal,
Lars
Deine DLL braucht wohl das Handle auf das Windows window um irgendwelche Eigenschaften des Fensters zu aendern. HWND ist der Identifier des Fensters und wird erzeugt wenn der Konstruktor der CWnd -Klasse via create aufgerufen wird. Gespeichert wird in m_hWnd.
Ich wuerde vorschlagen, Du schreibst Deine Konsolenanwendung um in eine dialogfeld basierende Anwendung um. CDialog ist von CWnd abgeleitet und das m_hWnd holst du Dir direkt.
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
… bin’s nochmal …
Die DLL holt sich für ihre grafische Oberfläche wohl lediglich das Icon meines Fensters (von dem das HWnd benötigt wird). Ist es möglich, dass ich in meiner (Konsolen~)Anwendung ein unsichtbares Fenster habe, dass der DLL die nötigen Eigenschaften bereitsstellt ?
Wie erstelle ich dann so ein „unabhängiges“ Fenster ?
CFrameWnd *wnd = new CFrameWnd();
wnd->Create(…)
Wie muessen dann die Argumente von Create aussehen ?
Vielen Dank, auch für die erste Antwort,
mfG Lars
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Ich glaube nicht, dass die DLL das Handle nur wegen des Icons benoetigt.
Wozu soll das gut sein? Ich denke eher, dass ueber das handle der CWnd Pointer geholt wird,
um z.B. für einen Dialog den Parent zu bestimmen.
Das mit dem CFrameWnd halte ich für keine gescheite Lösung, aber gut…
Allgemein lautet create folgendermassen:
BOOL Create(
LPCTSTR lpszClassName,
LPCTSTR lpszWindowName,
DWORD dwStyle = WS\_OVERLAPPEDWINDOW,
const RECT& rect = rectDefault,
CWnd\* pParentWnd = NULL,
LPCTSTR lpszMenuName = NULL,
DWORD dwExStyle = 0,
CCreateContext\* pContext = NULL
);
Fuer lpszClassName wuerde ich NULL waehlen.
Fuer lpszWindowName wuerde ich z.B. _T(„Dummy“).
dwStyle = WS_VISIBLE wuerde das Fenster sichtbar machen.
Ich halte eher die DLL für schlecht, denn die sollte auch mit einem NULL-Pointer umgehen koennen.
OK, danke für Deine Antwort, ich glaube, ich muss mal mein Problem umfassender erklären:
Ich moechte einen Twain-Treiber für Java schreiben. Dazu nutze ich JNI (was sonst … ?). Um eine Initialisierung zwischen Anwendung und Twain-Sourcemanager herzustellen, muss die Anwendung dort zu Beginn registriert werden. Dazu fordert die TWAIN-API ein HWnd des AppFensters (NULL endet in Schutzverletzung … schlechte DLL = TWAIN_32.DLL).
Um das HWND von Java-Komponenten zu erhalten, waren bis JDK1.3 zusätzliche Klassen (sun.awt.DrawingSurface, …) vorhanden (deprecated), die jedoch mit dem JDK1.4 ganz verschwanden und in C ausgelagert wurden (/include/jawt.h). Jedoch ist es mir damit nicht möglich, das Handle des JFrames zu bekommen (assertions failure). Alle Beispiele für getHwnd(), die im Netz zu finden sind, beziehen sich lediglich auf java.awt.Canvas (das funktioniert auch). Damit kann aber der Source-Manager nichts anfangen, da er mind. das Icon der Applikation für seine grafische Oberfläche benötigt (Verwendungszweck des Eingescannten).
Also muss ich irgendwoher in meiner JNI-DLL ein Fenster „auftreiben“, das ich an die TWAIN-Methode übergeben kann.
Hat jetzt jemand eine Idee ?
Danke soweit,
Lars
Sorry, tut mir leid.
Wie ich sehe bist Du im Java Forum da besser aufgehoben. Ich habe leider praktisch gesehen so gut wie keine Erfahrungen in Java, die so tief gehen.
OK, Hallo Vir2,
ich hab das ganze „hwnd-Abgefrage“ jetzt in einer einzelnen Methode gekapselt, die erstmal über FindWindow(NULL, ); das ganze erfragt. Das funktioniert soweit anständig.
Wenn mir noch was besseres
einfällt, dann kann ich’s ja umändern und werd’s posten.
Gruss, Lars
P.S: Danke für Deine Antworten !