Announcement

**Mathias Simmack** · 21.09.2001, 13:53

Das Thema hatten wir schon mal. Bitte nicht als Vorwurf verstehen. Meine Frage ist, ob du irgendwelche speziellen Komponenten benutzt, die dir evtl. ein paar Systemeingriffe abnehmen. Ich dachte da z.B. an: 
1. Hotkey-Funktionen 
2. Funktionen, die dein Programm in der TNA anzeigen usw. 
Alles Funktionen, f�r die du sonst diverse WinAPI-Aufrufe t�tigen m�sstest. Es hat sich n�mlich hier und im DF herausgestellt, dass solche Komponenten intern die Botschaften selbst bearbeiten und offenbar die eine, die zum Beenden wichtig ist, nicht korrekt zur�ckgeben, bzw. sich selbst nicht korrekt beenden. Und dadurch h�ngt alles. System-m��ig, meine ich ... das andere ist altersbedingt ... ;o) 
Alternativ k�nnte man das Programm ja mal unter Win9x testen. 
Und dann noch dies als Schnellhilfe:
http://entwickler-forum.de/webx?50@@.ee86305 
Gru�, Mathias

**Nimrod** · 24.09.2001, 08:41

Hallo,

erstmal danke f�r deine Hinweise

Auch ich lass meine Anwendung als Tray in der Taskbar erscheinen.

Das Problem trat erst auf als ich eine Tray-Komponente (TCoolTrayIcon)
aus meinem Projekt entfernte und diese durch folgenden (sparsamen) Quelltext ersetzte:

const WM_TRAYMSG = WM_USER + 99; // User Message f�r Tray

type
TForm1 = class(TForm) ...
private
FnotiTray: TNotifyIconData;
procedure TrayMessage(var Message : TMessage); message WM_TRAYMSG;
...
public
end;

implementation
...

procedure TForm1.FormCreate..
begin
//notifyIconData-Struktur installieren ...
with FnotiTray do begin
cbSize := SizeOf(FnotiTray);
Wnd := Handle;
uFlags := NIF_ICON + NIF_MESSAGE + NIF_TIP;
uCallBackMessage := WM_TRAYMSG;
hIcon := Application.Icon.Handle;
szTip := 'Zeiterfassung';
end;
Shell_NotifyIcon(NIM_ADD, @FnotiTray); //*)
....
end;

procedure TForm1.TrayMessage(var Message: TMessage);
var i:integer;
begin
if message.LParam = WM_LBUTTONDBLCLK then
begin
frmZeit.Show;
dmZeit.connectingDB;
for i:= 0 to componentCount -1 do
if components[i] = frmFile then frmFile.FormStyle := fsStayOnTop;
end;
end; //*)

procedure TForm1.FormClose .....
begin
...
Shell_NotifyIcon(NIM_DELETE, @FnotiTray); //tray icon l�schen
...
end;

Woher ich genau den Quelltext hatte weiss ich nicht mehr. Sicher ist das erst seit dem Austausch Windows NT nicht mehr automatisch beendet.

Gruss
ahira

**Mathias Simmack** · 24.09.2001, 14:04

Ich wei� nicht, ob�s f�r das Problem verantwortlich ist. Ich habe meine TNA-Funktion immer so abgefragt:
<pre>
procedure TForm1.TrayMessage...
begin
  if(Message.msg = WM_TRAYMSG) then
    begin
      if(Message.lPa ram = ....) ...
    end;
  inherited;
end;</pre>
Also, er f�hrt die Kontrolle aus, ob �berhaupt die Nachricht "WM_TRAYMSG" angekommen ist, dann macht er die Sache mit dem Mausklick usw., und ganz egal wie - am Ende gibt er die Kontrolle (was auch immer) mit "inherited" an das System zur�ck. Hilft das weiter?, denn ansonsten kann ich - so auf den ersten Blick - keinen Fehler in der Funktion entdecken. Gru�, Mathias

**Hagen Reddmann** · 24.09.2001, 16:30

der inherited Call ist in diesem Moment sinnlos. Die Message wurde als wm_User + X erst f�r und in dieser Unit definiert. Sollte vom inherited System genau diese Message wm_User + X schon vorbelegt und benutzt sein dann hat sie garantiert NICHT die gleiche Bedeutung. Es ist also falsch hier inherited zu benutzen.

Besser w�re sowieso mit wm_TrayIcon := RegisterMessage(UniqueMessageNameHere); erst zur Laufzeit, dynamisch eine Systemeineindeutige Message-ID zu erstellen. Dann ist auch garantiert sichergestellt das diese Message eindeutig ist und nicht zu Problemen f�hren wird. Eine Annahme das wm_User + 99 noch NICHT andersweitig benutzt wird f�hrt zur zwangsl�ufigen Konsequenz das sie schon benutzt sein k�nnte und w�re dann keine exakter Programmierstil, und zweites MUSS dann sichergestellt sein das auch NUR dieses Formular auf wm_user+99 regaiert, kein inherited oder anderes Formluar auch nicht der DefaultHandler hat n�mlich das Wissen dar�ber was wm_User + 99 bedeutet und wie darauf zu reagieren w�re. Bzw. viel fataler w�re demnach das wm_user +99 schon mal definiert wurde und nun der inherited Handler diese Message als was ganz anderes interpretiert als sie tats�chlich ist.

Gru� hage

**Hagen Reddmann** · 24.09.2001, 16:40

N�chstes problem: Die NotifyStruct ben�tigt ein Wnd: hWnd um diesem die benutzerdefinierte Message zu senden. Nun wird erstmal das Trayicon registriert, danach wird z.B. Form.BorderStyle ge�ndert und schwups wird das FensterHandle Form.Handle zerst�rt und ein neues erzeugt, siehe .RecreateWnd(). Ein erneuter Aufruf dieser NotifyStruct() wird dann mit dem neuen hWnd arbeiten, also nicht mehr das originale TrayIcon ansprechen. 

Zus�tzlich sollte das uID Member mit einer eindeutigen ID <> 0 belegt werden, ansonsten MUSS n�mlich die Shell das hWnd Member als Identifizierungsmerkmal nutzen. Und wie oben angedeutet kann das mit Delphi TWinControls und Descends zu Problemen f�hren. 

Gru� Hage

**Mathias Simmack** · 24.09.2001, 16:53

Zwei Fragen, Hagen, wenn du gestattest. 
1. Ist "inherited" nun einfach nur �berfl�ssig oder wirklich falsch? 
2. Ich �berlege schon seit einiger Zeit, was passiert, wenn verschiedene Programme die selben Nachrichten � "WM_USER + 99" usw. benutzen? Es k�nnte ja sein, dass jemand mein Programm und das von Ahiram benutzt, und in beiden k�me jetzt die besagte Message vor. Sollte ich also meine Programme um�ndern, um solche Probleme zu vermeiden? Ich denke: ja. 
Mathias. 
PS: Und vielleicht h�ttest du ja auch eine Idee zu meiner Frage hier: 
http://entwickler-forum.de/webx?50@@.ee7127e.ee87828/0 
(Der Delphi-API-Ordner geht n�mlich ein bisschen unter.)Nur wenn du die Zeit hast, nat�rlich

**Mathias Simmack** · 24.09.2001, 17:47

Hm, ich finde "RegisterMessage" nirgendwo dokumentiert. H�ttest du da mal mehr Infos, Hagen? Mathias

**Torsten Grundke** · 24.09.2001, 18:52

Hallo Mathias,

Hagen meint bestimmt die Win-Funktion RegisterWindowMessage().

Tsch��

Torste

**Hagen Reddmann** · 24.09.2001, 19:20

Ja, RegisterWindowMessage ist richtig, sorry.

@Mathias:
1.) FALSCH,
da die Bedeutung von wm_User + 99 = wm_MyTaskIconID nur der Unit die sie definiert hat, bekannt ist. Mit inherited wird nun diese Message an die Vorg�nger Routine weitergeleitet. Da diese ja viel fr�her als Deine wm_MyTaskIconID programmiert wurde konnte sie auch nichts von wm_MyTaskIconID wissen. Wie soll nun die Vorg�nger methode damit umgehen ? Eigentlich sollte sie sie ignorieren, es g�be also �berhaupt keinen Vorg�nger sondern nur den DefaultHandler. Dieser r�hrt sich aber nur bei allgemein fest definierten Messages. Tats�chlich w�rde also mit inherited meistens NICHTS passieren da die Message ignoriert w�rde. Einfach gesagt: wm_user + 99 ist noch niemals irgendwo benutzt wurden und nur DEINE wm_MyTaskIconID ist wm_User + 99. Also bei benutzerdefinierten Messages ist inherited sinnlos. Aber, was ist wenn in Unit Forms o.�. mit wm_AktivateAtomBomb = wm_User + 99; schon eine Message mit der gleichen ID wie wm_MyTaskIconID existierte ?! Nun, mit inherited w�rde dann von procedure .WMMyTaskIcon() das inherited = .WMActivateAtomBomb() aufgerufen. Der Parameter von WMMyTaskIcon.Active = Boolean ist an der selben stelle wie WMActivateAtomBomb.DestroyEarth = Boolean; 

In beiden F�llen w�rde entweder inherited sinnlos sein, da nichts passiert oder sogar gef�hlich, da inherited dann garantiert falsch interpretiert, weil die gerade eben definierte Message und deren Bedeutung dem inherited garnicht bekannt sein kann. 
Oder eben eine komplett andere Bedeutung bes��e, es k�nnte also durchaus eiges zerst�rt werden.

gru� Hage

**Hagen Reddmann** · 24.09.2001, 19:31

Nun, mit RegisterWindowMessage() hat man die M�glichkeit eine ID die wirklich eindeutig ist zu definieren. Oder genauer gesagt zu einem eindeutigen Namen die eindeutige ID vom System zu bekommen. Damit w�rden auch zwei verschiedene Prozesse immer zum gleichen Namen die gleiche ID erhalten. Das ist gut da somit beide Prozesse sich per Messages unterhalten k�nnen, und sich denoch sicher sein k�nnen das beide die gleiche Message-ID benutzen. 

Nachteilig im delphi ist aber, da� keine Variablen als Message ID Bezeichner in der "message" deklaration benutzt werden k�nnen. Das heist um auf eine mit registerWindowMessage() aquirierte ID reagieren zu k�nnen mu� immer die .WndProc() �berschrieben werden und in dieser kann auch keine CASE Msg.Msg OD benutzt werden. Wir m�ssen also immer umst�ndlich WndProc �berschreiben und jede solch registrierte ID mit if Msg.Msg = wm_MyID then ; abfragen. 

Gru� Hage

**Hagen Reddmann** · 24.09.2001, 19:39

Normalerweise ist es REGEL das eine Anwendung die an eine andere Anwendung Messages verschickt NUR solche verschickt die auch klar bekannt und definiert sind. Also eigentlich nur die SystemMessages wie wm_GetText usw. Nat�rlich steht es dem Coder frei das wm_Gettext = 13 anders zu interpretiern, z.B. als wm_ActivateAtomBomb

Die Regeln und die exakte Einhaltung dieser, macht erst dieses Konzept tragf�hig.

Gru� Hage

**Mathias Simmack** · 24.09.2001, 20:15

Gut, dann werd� ich mein TNA-Programm mal �ndern, damit es auch auf Systemen lauff�hig ist und bleibt, auf denen Ahirams Programm l�uft.

)

Mathias

**Mathias Simmack** · 25.09.2001, 08:43

Na das war ja mal relativ einfach, Hagen.

) 
1. Das Unwissen mit dem evtl. mehrfachen Benutzen von Messages � "WM_USER + 99" l�sst sich, denke ich, damit entschuldigen, dass es sich auch Buchautoren manchmal sehr einfach machen. Mein bisheriger TNA-Code stammt aus einem Buch, und da geschah es genau so. Ich muss aber zugeben, dass der Autor nie "inherited" aufgerufen hat. Soviel dazu.

( 
2. Gibt es evtl. eine Art Gegenst�ck zu "RegisterWindowMessage", oder wird diese automatisch beim Beenden des Programms wieder ... sagen wir mal: freigegeben. Ich habe n�mlich nichts finden k�nnen. 
3. Ich musste mein Programm auch gleich noch im DPR-Quelltext �ndern. Ich hatte n�mlich eine Funktion drin, die pr�fte, ob das Programm schon l�uft. Wenn ja, dann hat sie (falls das Tool minimiert war) die Tray-Botschaft verschickt, damit mein Programm quasi in den Vordergrund geholt wird. Na ja, ich hab�s jetzt mit der Botschaft "WM_SYSCOMMAND" und "SC_RESTORE" gel�st, und das klappt ja auch.

) 
So, Ahiram, damit du auch was davon hast, werde ich mich mal als Verk�nder bet�tigen. Bei Fehlern bitte korrigierend eingreifen, Hagen!

) 
Mathias. 
<pre>
type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
  private
    FnotiTray : TNotifyIconData;
  public
  protected
    procedure WndProc(var Message: TMessage); override;
  end;</pre>
<pre>implementation</pre>
<pre>
const
  myTaskbarId = 250901; // eine eindeutige ID
        &n bsp;       &nbs p;       // du kannst z.B. das Datum nehmen (25.09.01)
        &n bsp;       &nbs p;       // oder die Ma�e deiner Freundin ...
        &n bsp;       &nbs p;       // hi hi
        &n bsp;       &nbs p;       // �ne ID "906090"

)
var
  WM_TRAYMSG : UINT = 0;</pre>

<pre>
procedure TForm1.FormCreate(Sender: TObject);
begin
  WM_TRAYMSG := RegisterWindowMessage('AhiramsSuperDuperProgramm') ; // ;o)
  //
  // laut Hilfe ist der R�ckgabewert im Fehlerfall Null
  // also nur mit der TNA verbinden, wenn die R�ckgabe ungleich Null ist
  //
  if(WM_TRAYMSG <> 0) then
    begin
      FnotiTray.cbSi ze := sizeof(TNotifyIconData);
      FnotiTray.W nd := {Form1.}Handle;
      FnotiTray.u ID := PopEyh5TaskbarId;
      FnotiTray.uFla gs := NIF_MESSAGE OR NIF_ICON OR NIF_TIP;
      FnotiTray.uCal lbackMessage := WM_TRAYMSG;
      FnotiTray.hIco n := Application.Icon.Handle;
      FnotiTray.szTi p := 'Zeiterfassung';
      Shell_NotifyIc on(NIM_ADD, @FnotiTray);
      end;
end;</pre>
<pre>
procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  if(WM_TRAYMSG <> 0) then
    begin
      Shell_NotifyIc on(NIM_DELETE, @FnotiTray);
    end;
end;</pre&gt

**Mathias Simmack** · 25.09.2001, 08:44

<pre>
procedure TForm1.WndProc(var Message: TMessage);
var
  i : integer;
begin
  if(Message.Msg = WM_TRAYMSG) then
    begin
      if(Message.lPa ram = WM_LBUTTONDBLCLK) then
        be gin
        &n bsp; frmZeit.Show;
        &n bsp; dmZeit.connectingDB;
        &n bsp; for i := 0 to ComponentCount - 1 do
        &n bsp;   if Components[i] = frmFile then frmFile.FormStyle := fsStayOnTop;
        en d;
    end
  else
    inherited WndProc(Message);
end;
</pre&gt

Announcement

Anwendung beenden

Anwendung beenden

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment