Newsgroup: it.comp.lang.c++
Titolo: SetForegroundWindow e windows 98

	Qualche astuto programmatore della microsoft ha pensato che
chi programma non debba avere diritto a fare cio' che desidera, anzi
lo pensa da anni, solo che ora ha raggiunto il top.
La funzione SetForegroundWindow, che fino a win95 portava una finestra
in primo piano (o una MessageBox con il parametro apposito), e' stata
declassata, ed ora si limita a far lampeggiare l'icona del programma
per chiedere l'attenzione dell'utente.
Ovviamente il programma potrebbe non avere un icona.
Ovviamente l'utente potrebbe tenere la barra invisibile e cosi' non la
vedrebbe.
Ovviamente i bug se li cercano in microsoft, e cosi' a volte facendo
click sull'icona lampeggiante l'applicazione anziche' andare in primo
piano va ad icona!
Ci troviamo cosi' con un lungo ammasso di funzioni-spazzatura, e
cioe':
SetForegroundWindow
SetFocus
SetActiveWindow
BringWindowToTop
delle quali piu' nessuna fa' quello che ci si aspetterebbe dal loro
nome.
Qualcuno ha idea di come spingere un processo e la sua finestra in
primo piano, come accadave fino a w95, e vorrebbe dirmelo prima che la
microsoft istituisca la pena capitale per chi tenta di portare una
applicazione in primo piano?
Per favore rispondete anche per EMail.
please remove NOSPAM from email address to write me.
/-------------------------------------------------------\
| DataDuck 5.1  Configurable DataBase and Plug-in Win95 | 
| also for Windows 3.1 and NT. Aim your Web browser at  | 
| 
http://www.prog.arch.unige.it/~aoddera/Homeao.htm
     | 
| to get your own copy!                                 | 
\-------------------------------------------------------/

...

Secondo me, gli analisti della Microsoft perdono meta' del loro tempo a
cercare di rendere difficili e complicate cose che potrebbero essere di una
semplicita' estrema.
Tempo fa, dovendo implementare un dialogo di scelta directory, avevo fatto
affidamento sulla DlgDirList(). Senonche', sotto win95, riporta i nomi di
directory nel modo DOS (8.3), mentre sotto NT funzionava bene. Ormai avevo
impostato il codice sulla DlgDirList(), cosi' ho fatto prima a riscriverla
che non a cercare altre soluzioni.
Poco tempo fa ho letto quanto postato da Alex (vera miniera di informazioni)
sull'API SHBrowseForFolder().
Mi stavo quasi ricredendo sulla MS. Purtroppo, la suddetta funzione ritorna
solo il nome dell'ultima directory (in pratica, quella selezionata) e non il
path completo. Chissa' cosa avranno pensato alla MS: se uno deve scegliere
una directory, che gliene importa da dove proviene?
Controsenso: nell'help della struttura BROWSEINFO e' specificato che il
buffer puntato da pszDisplayName viene assunto essere pari a MAX_PATH.
Certo, poi ti fanno rientrare dalla finestra offrendoti di usare una
funzione BrowseCallbackProc.
Non era piu' semplice tornare gia' il percorso completo lasciando all'utente
la decisione di scartare i dati superflui o, al limite, aggiungere un flag
per rendere operativa questa scelta?
Per il tuo problema, mi spiace, non sono in grado di aiutarti :-|
Anche perche' non ho ancora avuto il coraggio di aggiornare il sistema a
win98 :-(
Se e' una tua applicazione prova a fargli gestire un messaggio di notifica
e, al ricevimento, prova ad usare SetWindowPos() o addirittura la stessa
SetForegroundWindow() (dall'interno dell'applicazione che deve essere
portata in primo piano).
Ho solo voluto aggiungere un mio sfogo a dimostrazione di simpatia e
comprensione ;-)
Nazzareno Paolini

 per rendere operativa questa scelta?
Non capisco. SHBrowseForFolder non ritorna un ptr ad un ITEMIDLIST con 
informazioni sull'item selezionato? In quel caso dovrebbe bastare una 
chiamata a SHGetPathFromIDList() per ottenere il path completo. 
Ciao,
Antonello
-- 
// ------------------------------------------------------------------
// Antonello Salvatucci
// Software Engineer
// LEGO Media - Kloevermarken 120, 7190 Billund DENMARK
// 
// antonello at digi. lego. com             
http://www.lego.com


Hai ragione, scusa la mia ignoranza :-)
Avevo fatto la prova su quanto postato senza approfondire e mi era sembrato che il path
dovesse tornare nel buffer passato nella struttura.
Causa la mancanza di tempo (e la non impellente necessita'), non mi ero nemmeno soffermato
a guardare le funzioni correlate :-(
Ok, grazie.
Ciao
Nazzareno

per rendere operativa questa scelta?
Sí, forse "era piú semplice" che lo shell ad esempio trattasse
sempre con stringhe per identificare gli oggetti dei suo namespace,
invece di quella rappresentazione interna "id list" che a volte puó
costringere a "tradurre" a e da stringa. Tuttavia, ci sono parecchi
vantaggi nell'uso generalizzato delle ID list, in particolare quelli di
efficienza ed univocitá di identificazione nel namespace.  Chi
programma in C++, tutto sommato, non lo fa certo perché vuole
la _semplicitá_ -- se non ha CLAMOROSAMENTE sbagliato il
linguaggio, vorrá dire che cerca invece potenza, efficienza, e
generalitá architetturale.  Le interfacce della libreria di Shell, come
tante altre di Windows, sono molto complesse (forse troppo), ma
spesso lo sono per ragioni, appunto, di efficienza, potenza, e
generalitá.  Visual J++, con le Windows Foundation Classes, e
Visual Basic, offrono ambienti di sviluppo di uso spesso MOLTO
piú semplice di quanto non si possa ottenere in C++, con solo un
piccolo sacrificio di potenza ed efficienza, sacrificio accettabile
per la grande maggioranza delle applicazioni, e sono quindi degli
ambienti di sviluppo, secondo me, molto piú appropriati in tanti,
ma TANTI casi.
Ah, un ultimo dettaglio ancora sulla libreria dello shell: mi pare
che una discreta documentazione sia fornita nel libro di Nancy
Cluts, "Programming the Windows 95 User Interface", il quale
a sua volta, se non sbaglio, é disponibile (oltre che in forma
cartacea da Microsoft Press e, in Italia, Mondadori Informatica)
anche come parte dell'MSDN -- non sono sicuro di quali versioni
MSDN lo comprendano, ma penso che sia in quella in linea a
www.microsoft.com
 e in quella su CDROM che fa parte del
prodotto Visual C++ (accetto volentieri correzioni in merito, e
magari puntatori piú precisi su dove trovarlo entro il CDROM o
il sito MS).  Mi pare che meriti approfondire le varie SHxxx, per
chi vuole programmare in C++, offrire una ricca e familiare
interfaccia all'utente, e magari non dovere reinventare l'acqua
calda -- e il testo della Cluts é un buon punto di partenza.
Alex