Newsgroup: it.comp.programmare.win32
Titolo: Shell_NotifyIcon e messaggi che non arrivano.

Spero che  ci sia qualcuno che sappia  indicarmi della documentazione,
NIENTE VB  e NIENTE  C++, non  ho voglia di  portarmi dietro  anche il
runtime delle MFC o equivalenti.
Problema
Definisco e registro una window class
         wndclass.style         = CS_HREDRAW | CS_VREDRAW;
         wndclass.lpfnWndProc   = PopProc ;
         wndclass.cbClsExtra    = 0 ;
         wndclass.cbWndExtra    = 0 ;
         wndclass.hInstance     = hInstance ;
         wndclass.hIcon         = LoadIcon (NULL, IDI_APPLICATION) ;
         wndclass.hCursor       = LoadCursor (NULL, IDC_ARROW) ;
         wndclass.hbrBackground = (HBRUSH)(COLOR_BTNFACE +1);
         wndclass.lpszMenuName  = NULL ;
         wndclass.lpszClassName = logonName ;
         if(!RegisterClass (&wndclass))
         {
             MessageBox(NULL,"Registrazione fallita",logonName,MB_ICONERROR);
             exit(1);
         }
poi creo la finestra 
         popw = CreateWindow (popitName, popitName,
                              WS_CAPTION | DS_3DLOOK
                              | DS_MODALFRAME | DS_SYSMODAL | WS_CLIPCHILDREN |
                              WS_CLIPSIBLINGS,
                              CW_USEDEFAULT, CW_USEDEFAULT,
                              300, 150,
                              NULL, NULL, hInstance, NULL);
e fin qui tutto bene.
Poi creo una icona nel tray con ShellNotify Icon. Preparo la struttura
NOTIFYICONDATA nic
         nic.uCallbackMessage = 0xDEADBEEF; 
         nic.cbSize = NIC_SIZE;
         nic.hIcon = trayIcons[TRAY_MAIL];
         nic.hWnd = popw;
         nic.uFlags = NIF_MESSAGE | NIF_ICON | NIF_TIP;
         nic.uID = 1;
         memcpy(nic.szTip, logonName, strlen(logonName));
	/* 
         * wrapper intorno a Shell_NotifyIcon, trayIcond è
         *  un array di HICON
         */
        trayInsert(popw,trayIcons[TRAY_MAIL]);
che funziona benissimo, l'icona appare e si lascia modificare.
Alla fine però quando si arriva al fatidico ciclo
         while (GetMessage (&msg, popw, 0, 0))
         {
             TranslateMessage (&msg) ;
             DispatchMessage (&msg) ;
         }
il programma si germa nella GetMessage(). E l'icona nel tray non invia
alcun tipo di messaggio.
In cosa  sbaglio ?  0xDEADBEEF non  è un CallBackMessage  valido ?  La
finestra  che  deve ricevere  i  messaggi  dell'icona  deve essere  un
dialog?
Altra curiosità. Creando a da programma una finestra con 2 textbox e 2
pulsanti il  tab non mi  fa cambiare "controllo" (child  window), devo
spostare il focus tra i textbox col mouse. E' perché la finestra non è
un dialog ?
+----------------------------------------------------------------+
| Gian Uberto Lauri * "So, are you working on fixing that bug    |
| 
sa...@eng.it
      *  *now* or leaving it until later ?" - YES  |
+----------------------------------------------------------------+
| Attenzione: rispondo ad ogni invio di pubblicità non richiesta | 
| o spam di qualsiasi altro genere con un messaggio al provider  |
| di competenza. Ai sensi della legge sulla privacy NON avete il |
| permesso di utilizzare i miei dati per questi scopi.           |
+----------------------------------------------------------------+

 un dialog ?
Hai specificato lo stile WS_TABSTOP per ogni controllo?
Puo` anche darsi che la gestione del focus sia gestita in parte dal
codice "nascosto" delle dialog (non ho mai controllato), ma in quel caso
basta catturare WM_CHAR e scrivere un po' di codice usando GetWindow.
---
Bye! Lorenzo Lutti
http://www.geocities.com/SiliconValley/Peaks/6258/

> finestra non è un dialog ?
LL> Hai specificato lo stile WS_TABSTOP per ogni controllo?
Si.
LL> Puo` anche darsi che la gestione del focus sia gestita in parte dal
LL> codice "nascosto" delle dialog (non ho mai controllato), ma in quel caso
LL> basta catturare WM_CHAR e scrivere un po' di codice usando GetWindow.
Non ne vale  la pena. Quando tutto funzionerà  quella finestra si farà
vedere una sola volta al giorno, e mi basta il mouse :)



Esatto. Le dialog-box gestiscono i messaggi WM_KEY* per la navigazione (e 
il tasto di default). 
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)

 writes:
VM> Hai registrato la classe come logonName e creato la finestra come 
VM> popitName. Se le due stringhe non coincidono, la finestra non viene creata 
VM> correttamente.
Sorry,  errore  mio, mi  era  sembrato  di  aver allineato  il  codice
nell'articolo  (nel  sorgente invece  non  occorre  in  quanto le  due
variabili puntano alla stessa costante)
VM> offset (anche perchè l'id del messaggio potrebbe essere troncato a 16 bit) 
Offset corretto a beef ed ha funzionato. 
VM> Attenzione! Adesso le altre finestre funzionano perchè popw vale NULL.
C'è  una  sola finestra,  anzi  nemmeno  lei  (mi serve  una  finestra
invisibile per  la sua window  procedure).  Ora il  programma funziona
bene,  grazie  al  fatto che  ho  aggirato  un  problema che  mi  dava
CreateProcess() utilizzando la  system() (di unixiana memoria) fornita
dal supporto runtime di Cygnus.
Il problema con CreateProcess() è (anzi era, ora mi interessa solo in
modo accademico):
- Se lanciavo una CreateProcess() dentro WinMain tutto OK.
- Se lanciavo una CreateProcess() - stessi parametri - nella 
  window procedure, crash!
- Se nella window procedure chiamavo CreateThread() e dentro 
  quella la CreateProcess() questa falliva educatamente e 
  GetLastError ritornava un numero assurdo. Questo per via
  dei security descriptors ?
VM> Esatto. Le dialog-box gestiscono i messaggi WM_KEY* per la navigazione (e 
VM> il tasto di default). 
Bon,  non  ci  spendo un  minuto  in  più  finché  non trovo  un  buon
compilatore di risorse sotto gcc...


 confermato l'opinione che avevo su Windows.
Suvvia, non essere cattivo... ci sono motivi piu` giusti per criticare
Windows. :)
Mi sembra che 64K messaggi siano piu` che sufficienti, considerando
anche tutti i sotto-codici di cui dispongono molti messaggi...


> confermato l'opinione che avevo su Windows.
LL> Suvvia, non essere cattivo... ci sono motivi piu` giusti per criticare
LL> Windows. :)
LL> Mi sembra che 64K messaggi siano piu` che sufficienti, considerando
LL> anche tutti i sotto-codici di cui dispongono molti messaggi...
Concordo pienamente sul fatto che 64K messaggi bastino.
La  mia opinione  su Windows  è questa  (messa in  chiaro,  non voglio
offendere  nessuno):  "I  difetti   di  Windows  si  dividono  in  due
categorie: le scelte progettuali  idiote -vedi scheduler dei processi,
gestione della coda  dei messaggi alla finestra [risolta  a partire da
'98 per fortuna], socket asincroni, interfaccia grafica nel ring 0...-
e  scelte da  giuste a  buone realizzate  coi piedi,  come  mettere un
parametro  a 32  bit dove  è obbligatorio  a 16,  il  comportamento di
VirtualAlloc (a me è sempre toccato  fare 1 chiamata per il reserve ed
una per  il commit,  alla faccia  di quello che  dice Richter  nel suo
libro). Sia chiaro,  nessun S.O. è esente da difetti,  ma credo che ce
ne siano molto pochi ad essere presuntuosi, e detesto i presuntuosi :)
Ne approfitto per cambiare domanda :
Con i compilatori di MS o Borland ci sono problemi a vare una chiamata
a CreateProcess() nella window procedure ?
Io col gcc ho avuto dei problemi che ho elencato in un altro post :
	- Chiamata nel thread della window procedure --> CRASH
	- Chiamata in un thread avviato con CreateThread --> 
	  chiamata fallita gentilmente.
A me viene  il dubbio che (almeno col gcc) il  thread della WP() abbia
un   security   descriptor   diverso   dal  thread   che   esegue   la
WinMain(). Opinioni ?
[btw, uso il gcc perché a) il tool è nato per usi personali, se altri lo
 vogliono ben vengano, la licenza è GPL b) ho trovato bello e pronto un
 sorgente per il dialogo col POP server senza doverlo riscrivere, ma coi
 socket di Windows non va, occorre una implementazione per Windows dei
 socket di Berkeley]


 WinMain(). Opinioni ?
Onestamente non saprei, il gcc lo uso solo sotto a Linux. :)


> a CreateProcess() nella window procedure ?
LL> Perche` dovrebbero esserci? Almeno, io il piu` delle volte i processi li
LL> creo li` e non ho mai avuto problemi.
Grazie. Era una informazione  che mi serviva. Evidentemente il runtime
del GCC è ancora deboluccio sotto  Win32 quando si cerca di creare una
applicazione Win32 pura. Nota a margine, sfruttando la system() con la
libreria di compatibilità verso Unix non ho avuto rogne... Mah!!!
LL> Onestamente non saprei, il gcc lo uso solo sotto a Linux. :)
Mah,  lo   avevo  preso   in  ufficio  principalmente   come  antidoto
all'intossicazione da VB (il  dottore mi ha prescritto LISP quotidiano
e del C saltuariamente :) ). Poi ho visto che compilava un esempio del
Petzold ed ho intrapreso un  toy project, concluso con successo. Prima
avevo lavorato  col Watcom (bel  compilatore, bella IDE,  debugger non
all'altezza)  e VC++  (il debugger  faceva il  suo dovere  e  l'ide si
accorge se qualche editor ha cambiato i file)
Riferimenti
[1] Programmazione avanzata in windows, J. Richter, pag. 64-70
[2] Programmazione avanzata in windows, J. Richter, pag. 387. Nota, la
    parola  follia  nell'originale  è  "madness" (quella  da  sedativi
    potenti e camicia di forza).


 per pulire i 16 bit alti :).
Questo senz'altro. ;-)
P.S. Complimenti per il messaggio, l'ho letto e ho risposto con vero
piacere.


>>>>> "LL" == Lorenzo Lutti <lorenz...@DOHtiscalinet.it> writes:
LL> comunque in situazioni "normali" ha piu` o meno la stessa efficienza del
LL> "random boost" di Windows (sostanzialmente ogni tanto viene data piu`
LL> priorita` a caso a qualche processo, anche quelli a bassa priorita`).
Hmmm, non c'è alcun dubbio, è che avere a disposizione una certezza, almeno
per me, mette in una situazione di maggior comfort. Vero anche che random
nei computer è in realtà pseudorandom, e quindi c'è una quasi certezza che
il random boost colpisca un task.
Grazie  per i  complimenti, ricambio!!   Vengo  da Unix  e sono  stato
draftato per lavorare sotto Windows,  conoscerlo meglio non mi fa male
e se tolgono i difetti ancora meglio.
