Announcement

**Andreas Kosch** · 19.01.2005, 07:25

Hallo,

>Wie funktioniert die PostMessage in .Net (Delphi8) ?

genauso wie fr�her. Bei einer FCL-Anwendung (Windows Forms aus dem .NET Framework) sieht das zum Beispiel so aus:

Schritt 1: Namespace System.Runtime.InteropServices einbinden
<pre>
unit WinForm;
 
interface
 
uses
System.Drawing, System.Collections, System.ComponentModel,
System.Windows.Forms, System.Data,
System.Runtime.InteropServices;
</pre>
Schritt 2: Botschaftsbehandlung �ber die geerbte Methode WndProc im Formular deklarieren
<pre>
type
TWinForm = class(System.Windows.Forms.Form)
{$REGION 'Designer Managed Code'}
...
{$ENDREGION}
strict protected
procedure Dispose(Disposing: Boolean); override;
procedure WndProc(var aMsg: System.Windows.Forms.Message); override;
private
{ Private Declarations }
public
constructor Create;
end;
</pre>
Schritt 3: Botschaftsbehandlung (Auswertung) implementieren
<pre>
procedure TWinForm.WndProc(var aMsg: System.Windows.Forms.Message);
begin
if aMsg.Msg = $8001 then
begin
Button1.Text := '$8001';
end;
inherited WndProc(aMsg);
end;
</pre>
Schritt 4: Botschaft �ber PostMessage verschicken
<pre>
[DllImport('user32.dll')]
function PostMessage(Hnwd, Msg, wParam, lParam: Integer): Integer; external;
 
procedure TWinForm.Button1_Click(sender: System.Object; e: System.EventArgs);
begin
PostMessage(Handle.ToInt32, $8001, 0, 0);
end;
</pre>
Handelt es sich im jedoch um eine VCL.NET-Anwendung, so �ndert sich nichts gegen�ber fr�her:
<pre>
unit Unit1;
 
interface
 
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, System.ComponentModel, Borland.Vcl.StdCtrls;
 
const
PM_APP = WM_APP + 1;
 
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
procedure PMAPP(var Msg: TMessage); message PM_APP;
private
{ Private declarations }
public
{ Public declarations }
end;
 
var
Form1: TForm1;
 
implementation
 
{$R *.nfm}
 
procedure TForm1.PMAPP(var Msg: TMessage);
begin
Button1.Caption := 'PM_APP';
end;
 
procedure TForm1.Button1Click(Sender: TObject);
begin
PostMessage(Handle, PM_APP, 0, 0);
end;
 
end.
</pre&gt

**Raimund Schennach** · 19.01.2005, 17:12

Danke f�r die prompte Antwort ! 
 
Habe aber noch eine Frage. 
 
Das Beispiel beinhaltet die Zeilen .. 
<PRE>
[DLLImport('user32.dll')]
funktion PostMessage(Hnwd,Msg,wParam,lParam: integer ;external;
</PRE>
 
Das sieht f�r mich so aus als ob hier eine Funktion aus der alten win32-Welt verwendet wird und nicht eine reine .Net Funktion. 
Ist das jetzt ein .net Programm oder nicht ? 
 
Dank

**Bernhard Geyer** · 20.01.2005, 09:04

> Das sieht f�r mich so aus als ob hier eine Funktion aus der alten
win32-Welt verwendet wird und nicht eine reine .Net Funktion.

Na Und? 
Du verwendest wie ich sehe VCL.NET. Und dort wird alles �ber PInvoke auf die "alten" Win32-Funktionen umgesetzt. 
Auch WinForms werden letztendlich auf Win32-API-Funktionen umgesetzt. Jedoch im Gegensatz zu VCL.NET in "Trusted" MS-Assemblies und deshalb mit weniger problemen (Rechte, Portierbarkeit, ...)

> Ist das jetzt ein .net Programm oder nicht ?

Es ist ein .NET-Programm, jedoch nicht mehr auf andere Plattformen (PocketPC, Linux) portierbar, da eine feste Bindung mit Win32 vorliegt

**Andreas Kosch** · 20.01.2005, 09:04

Hallo,

>Das sieht f�r mich so aus als ob hier eine Funktion aus der alten
win32-Welt verwendet wird ...

�ber das DllImport-Attribut wird der CLR (Common Language Runtime) von .NET mitgeteilt, dass die Implementierung der aufgerufenen Methode in einer unmanged code-DLL (Win32-DLL) steckt. Wenn die Konfiguration der .NET Security dem Aufruf nicht im Wege steht, schaltet die CLR f�r den Zeitpunkt des Aufrufs in der Tat kurzzeitig vom mananged code auf unmanged code um (P/Invoke-Aufruf).

>Ist das jetzt ein .net Programm oder nicht ?

Es ist immer noch ein .NET-Programm. Denn auch die nativen Klassen aus dem .NET-Framework setzen ja zur Zeit noch direkt auf die "alten" Win32-API-Funktionen auf. Der Komfort besteht nur darin, dass die Klassen im .NET Framework gerade im Bezug auf die Code Access Security (CAS) bereits alle Vorkehrungen treffen (d.h. die von Microsoft signierten Assemblies werden effizienter ausgef�hrt als eigene P/Invoke-Aufrufe). Erst mittelfristig wird sich das �ndern, wenn das Win32-API im Betriebssystem ersetzt wird.

Wenn man "reines" .NET (also ohne eigene P/Invoke-Aufrufe) nutzen will, muss man auf andere (vorhandene) Synchronisationsmechanismen wie zum Beispiel �ber die Klassen AutoResetEvent und ManualResetEvent zur�ckgreifen. Die Frage ist nur, welchen Vorteil man von diesem "puren" Ansatz hat ;-

**Raimund Schennach** · 20.01.2005, 13:09

Hallo, 
 
<Die Frage ist nur, welchen Vorteil man von diesem "puren" Ansatz hat ;-) ... 
 
f�r mich stellt sich die Frage wie wird es in Zukunft weiter gehen?. 
Ich denke die Zukunft wird sicher .net sein. Das bedeutet aber auch dass es die win32 Welt 
irgendwann einmal nicht mehr geben wird. Wenn ich schon in .net Programmiere dann werde ich 
auch die vorhandenen .net Funktion verwenden und nicht die win32 Funktionen. Weil wie schon 
gesagt irgendwann werden die win32 Funktionen nicht mehr zur Verf�gung stehen, und ich muss 
dann alle meine Programme umschreiben! 
Dieser Arbeit will ich rechzeitig aus dem Weg gehen!<BR&gt

**Andreas Kosch** · 20.01.2005, 13:30

Hallo,

>Dieser Arbeit will ich rechzeitig aus dem Weg gehen!

derartige �berlegungen sind sicherlich prinzipiell richtig. Aber wenn man bedenkt, dass auch Heute noch Win16-Anwendungen unter aktuellen Windows-Versionen laufen, ist die �bergangsfrist schon sehr lang, die uns an dieser Stelle von Microsoft einger�umt wird. Denn nach dem .NET Framework 2.0 wird ja erst die darauffolgende Version grundlegende Erweiterungen vornehmen (Longhorn, Avalon, WinFS usw.). Ich glaube daher, dass der pragmatische Ansatz im Alltag am zweckm��igsten ist - nur aus didaktischer Sicht muss die "reine" .NET-Anwendung im Vordergrund stehen ;-

**Bernhard Geyer** · 20.01.2005, 14:04

> Weil wie schon gesagt irgendwann werden die win32 Funktionen nicht mehr zur Verf�gung stehen, und ich muss dann alle meine Programme umschreiben!

Wirst Du eh machen d�rfen wenn Du auf WinForms/VCL.NET aufsetzt. Erst mit .NET 2.0 und Avalon gibt es einen komplett neuen Ansatz, welcher letztendlich nicht auf Win32 basiert

**Andreas Kosch** · 20.01.2005, 15:20

Hallo Bernhard,

>Wirst Du eh machen d�rfen ...

auch nach Avalon werden die bisherigen FCL Windows Forms unterst�tzt. Nur dann, wenn man die neuen F�higkeiten nutzen will (d.h. wenn die Benutzeroberfl�che aufpoliert werden soll), gibt es Handlungsbedarf.

Ich bin so frei, die entsprechende Passage im Original zu zitieren (den aus meiner Sicht entscheidenden Satz habe ich durch die Fettschrift hervorgehoben):


At PDC2003, Microsoft introduced a new Windows presentation technology, code-named �Avalon.� Though Avalon v1.0 is not slated to be available to customers until 2006, we want to provide guidance on the relationship of Avalon to Windows Forms to ensure that customer investments in user interface are protected.

Windows Forms has substantial customer adoption today. It delivers a powerful rapid application development experience with full integration with Visual Studio, which lowers cost of development and time to market of smart client applications. Windows Forms v2.0 will release with Visual Studio 2005 (prior to Avalon v1.0) and is the best way today to create client applications using the .NET Framework. Going forward, Windows Forms will continue to be part of the .NET Framework and supported as such and is the main way to write managed code today to prepare for Avalon.

Avalon is Microsoft�s future presentation platform, designed for creating visually stunning, differentiated user experiences. Avalon builds on top of DirectX and introduces a unified engine for creating forms-based applications, graphics, video, and documents. Avalon�s engine fully exploits the richness of today�s hardware. When delivered, Avalon will become Microsoft�s strategic UI platform.

Microsoft is committed to providing guidance, tools, and technologies that will enable customers to leverage their skills and, where appropriate, source code to extend applications with the latest technologies. One of the key areas Microsoft has invested in is interoperability between Avalon and Windows Forms, enabling Windows Forms controls to be used in Avalon applications and Avalon controls to be used in Windows Forms applications. This interoperability technology will help customers smoothly transition to Avalon.

Microsoft�s roadmap for client UI development has three main phases:

1. Today, use Windows Forms v1.1 and observe the Microsoft Patterns and Practices guidance for maintaining clean separation between UI and other application logic.

2. When Avalon v1.0 releases (scheduled for mid-2006), we recommend that applications looking to differentiate their user interface such as Web sites and graphically intensive applications such as complex data visualization look closely at Avalon. Other applications should continue using Windows Forms.

3. Following the release of Avalon 1.0, the next version of Visual Studio following Visual Studio 2005 will contain tools and designers to support Avalon. At this point, customers should start to move their new development efforts to Avalon and use the Windows Forms/Avalon interoperability features.
</i&gt

**Bernhard Geyer** · 20.01.2005, 17:30

Hei�t das das hier ein �hnlich Weg wie mit D8/2005 eingeschlagen wird, wo auch WinForms und VCL.NET-Forms in einer Anwendung gemischt werden (bzw. auch mit <a href="http://www.inchl.nl/delphi/">VCL2NET</a>) auch auf einem Form? 
Oder wird es Schnittstellenkompatible Avalon-Controls geben, welche den WinForms-Controls entsprechen und transparent ersetzt werden

**Andreas Kosch** · 21.01.2005, 08:50

Hallo,

>Hei�t das das hier ein �hnlich Weg wie mit D8/2005 eingeschlagen

nein, denn der Delphi-Weg mixt ja .NET mit Win32, w�hrend die "Mischbatterie" von Microsoft in allen F�llen aus MSIL gespeist wird. Da in jedem Fall der JIT greift, kann zur Laufzeit via Reflection bei Bedarf beliebiger Anpassungs-Code (MSIL) dazugemischt werden, so dass keine schmutzigen Kompromisse notwendig werden. Zur Zeit gibt es allerdings meines Wissens nach keine exakte Beschreibung, wie das sp�ter technisch umgesetzt werden soll. Es gibt nur die Aussage von Microsoft, dass ein bequemer Migrationspfad bereitgestellt wird (der allerdings nur f�r die Windows Forms aus der FCL, aber nicht f�r die VCL.NET verf�gbar w�re)

**Bernhard Geyer** · 21.01.2005, 09:05

Wir werden sehen ob das wirklich elegand umgesetzt wird. 
MS hat ja schon of was versprochen und erst Jahre versp�tet umgesetzt (wenn �berhaupt)

Announcement

PostMessage in Delphi8 (.net)

PostMessage in Delphi8 (.net)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment