I have finally convinced my boss to have a look at Lazarus and start migrating our applications away from MFC ... but .... We are Windows only, currently shipping Win7. I'm using Lazarus 1.0.10 with the bundled FPC - relatively recent. Our applications control and communicate with various industrial devices via Dynamic Data Exchange (DDE), using Microsoft's Dynamic Data Exchange Management Library (DDEML). Delphi in all incarnations has had DDE controls - they're pretty much just simple WinAPI calls, so I figured I could port them rather painlessly.
A week and a half later I'm sending this message - hope someone can help.
The basic problem seems to be in passing a string to a function in Windows called DdeCreateStringHandle. It's already got a def in the win32 tree in Free Pascal - basically this:
function DdeCreateStringHandle(Inst: DWORD; psz: PChar; CodePage: Integer): HSZ; stdcall;
It doesn't seem to matter how I call it, it always registers a null string. I call it like this:
ServiceHSz:= DdeCreateStringHandle(Inst, StringName, CP_WINANSI); where StringName is a const PChar and Inst is a handle returned from the DDEInitialize function (which I know is valid by monitoring with other tools). This is basically identical to the VCL from Delphi 7 and prior - it works find there but not with FreePascal. I'm compiling with Delphi mode on and get no compilation errors.

DDE works on shared memory very much like the clipboard. I'm wondering if there's something amiss in that regard, but am at my wits end.

Any ideas are appreciated!
Thanks,
Dave H.

afaik DDEInitialize is defined slightly different in Freepascal from Delphi.

This creates a valid DDE string handle for me:

{$mode delphi}
uses ..., windows;
var
  Res: UINT;
  g_idInst: DWORD;
  g_hszAppName: HSZ;
const DMLERR_NO_ERROR=0;
  function DDECallback(CallType, Fmt: UINT; Conv: HConv; hsz1, hsz2: HSZ;
      Data: HDDEData; Data1, Data2: DWORD): HDDEData; stdcall;
begin
//
end;
begin
  g_idInst:=0;
  Res:=DdeInitialize(@g_idInst, DdeCallback, APPCLASS_STANDARD, 0);
  if Res = DMLERR_NO_ERROR then
    g_hszAppName:= DdeCreateStringHandle(g_idInst,'DDEServer',CP_WINANSI);
end.

If g_hszAppName is 0 then call

  DdeGetLastError(g_idInst);

to see what the last error is.

Ludo

Thanks, Ludo! It took me until today to try it, because I don't have a Windows machine at home, only Macs and Linux, and they don't do DDE ... Alas, when I got to work this morning, it didn't work ... your excellent sample returned the same kind of bogus data my routines were giving me.

However, it certainly put me on the path to solving the issue. I figured that if you said it worked, it must work - therefore the problem must be something else. A careful examination of the output from my DDE monitor revealed a strange "shifting" of data - the string handle was being returned as the task, and other things were "off". It finally dawned on me to look closer at the version of Lazarus and FPC I had installed - it was the 64 bit compiler. I happened to have a 64 bit laptop and that's what I picked for installation and evaluation (back in June). I reinstalled the latest from the website with the 32 bit compiler and everything worked fine.... including your sample, of course!

I don't know if this should be reported as a bug or not - I'm not sure that the Microsoft C compiler will correctly make these calls on Win64, either. We don't normally make 64 bit targets, so I will do some further investigations and let the list know. We're probably the only company on earth that still depends on DDE, but that was the last critical piece keeping us from shifting entirely to Lazarus and Free Pascal, and now that piece is in place. Goodbye MFC! ;>)

Thanks again and

Be well,
Dave H.