Entwickler-Ecke :: Thema anzeigen - API-Call an Fremdanwendung

gsmgrufti - Do 18.10.07 22:03
Titel: API-Call an Fremdanwendung

Hallo zusammen,
folgendes Problem in Stichworten:
- Fremdprogramm (TV-Prog) bietet API-Schnittstelle
- eine bereits von mir programmierte DLL dazu funktioniert perfekt mit den entsprechenden API-Calls
- nun möchte ich auch von einer Standalone-App diese Calls durchführen und die Rückgabewerte verarbeiten.
- das finden des HWND ist kein Problem ->geht und ist überprüft auf "Gleichheit" zur DLL
- wenn ich aber via Sendmessage dann die selbe Routine wie in der DLL anstossen möchte, krieg ich nix zurück, bzw. geht.

Hab ich da einen Denkfehler, bzw. kann ich mich einer in die richtige Richtung schubsen ?

P.S:
Crossposting : http://forum.dsdt.info/viewtopic.php?t=34525

alzaimar - Fr 19.10.07 08:49

Ohne Beispielcode aus der DLL und deiner nicht funktionierenden Anwendung werden sich nur die Seher und professionellen Medien unter uns in der Lage sehen, Dir zu helfen. Naturgemäß sind Menschen mit übersinnlichen Fähigkeiten dieser Art selten Softwareentwickler, obwohl das von Vorteil wäre, vor allen Dingen dann, wenn da man Bugs sieht, bevor sie gecodet werden.

Also: Rück mal ein wenig Code raus :mrgreen:

gsmgrufti - Fr 19.10.07 16:32

Also, DLL-Auszug, geht:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:

const
 WTVP_GET_CHANNELFILE_NAME  = $01021140;
type
 c_string = array of char;
 CHANNELFILE_INFO = record
                      pDestination  : c_string;
                      iSize         : integer;
                    end;
var
 ChannelFilename: CHANNELFILE_INFO;

procedure Read_Channel_Filename;Cdecl;
begin
  SetLength(ChannelFilename.pDestination,4096);
  ChannelFilename.iSize:=Length(ChannelFilename.pDestination);
  SendMessage(appwindow, WM_USER, WTVP_GET_CHANNELFILE_NAME, longword(@ChannelFilename));
  Filename:=Trim(string(ChannelFilename.pDestination));
end;

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:

function TMainform.WTVP_getChnFilename(WTV_HWND:hwnd): string;
type
 c_string = array of char;
 CHANNELFILE_INFO = record
                      pDestination  : c_string;
                      iSize         : integer;
                    end;
var ChannelFilename: CHANNELFILE_INFO;

begin
  SetLength(ChannelFilename.pDestination,4096);
  ChannelFilename.iSize:=Length(ChannelFilename.pDestination);
  SendMessage(WTV_HWND, WM_USER, WTVP_GET_CHANNELFILE_NAME, longword(@ChannelFilename));
  result:=Trim(string(ChannelFilename.pDestination));
end;

WTV_HWND wird via Enumwindows ... geholt -> spar ich mir hier, da ich das vergleichen kann und exakt übereinstimmt

Stefan.Buchholtz - Fr 19.10.07 16:56

Meiner Meinung liegt es daran, dass die DLL im gleichen Prozessraum wie das zu steuernde Programm läuft und das separate Programm natürlich nicht. Deswegen kann die DLL mit dem Programm Daten über einen Zeiger austauschen, den du über die Window-Message mitteilst (@ChannelFilename). Ein separates Programm arbeitet in einem eigenen virtuellen Speicherbereich und der durch die Window-Message übergebene Zeiger ist nicht gültig.

Ich sehe da im Moment auch keinen Workaround, der nicht die Kooperation des zu steuernden Programms voraussetzt, z.B. via Shared Memory. Du könntest höchstens eine DLL bauen, die die Plugin-Schnittstelle bedient und mit deinem separatem Programm auf eine andere Art kommuniziert.

Stefan

alzaimar - Fr 19.10.07 16:59

Oho, sieht ok aus, auf den ersten Blick. Aaaaaber: Du übergibst einer fremden Anwendung einen Zeiger auf Speicher deiner eigenen Anwendung. Das kann eigentlich gar nicht funktionieren. Daher frage ich mich, in wessen Adressraum die DLL läuft? Daten zwischen Anwendungen austauschen geht eigentlich nur über WM_COPYDATA, oder allgemeiner, mit IPC (siehe Link oben)...

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!