Newsgroup: it.comp.programmare.win32
Titolo: Scambio di informazioni tra applicazione e GUI

Salve ragazzi,
                  avrei una domanda sullo scambio di informazioni tra
processi in ambienti windows. Utilizzando Linux ho avuto modo di scaricare
un sacco di applicativi a linea di comando per i quali è stata sviluppata
una GUI che altro non fa che interfacciarsi graficamente con l'utente per
poi costruire ad hoc la linea di comando.
    Ora la mia domanda è la seguente e per meglio spiegarmi farò un esempio:
 vogliamo sviluppare un'applicativo per effettuare un banale FTP e abbiamo a
diposizione una utility (ad esempio, ftp.exe) con quale passando una linea
di comandi opportunamente costruita posso effettuare qualsiasi trasferimento
abbia mai sognato di fare :).
Parallelamente vogliamo costruire una GUI per ftp.exe, ossia, qualcosa tipo
Form, textbox per Username, Password, IndirizzoRemoto, Scelta dei File,
ecc...
Ecco finalmente la domanda.
Mentre mi è chiaro come lanciare ftp.exe con parametri e "riscuotere" anche
l'error level al termine che mi da l'esito dell'operazione, non so come fare
se, ad esempio, non volessi accontentarmi solo dell'errorlevel.
Ho fatto l'esempio dell'FTP perchè mi è facile con un altro esempio meglio
la mia domanda. Se volessi che la mia GUI visualizzi lo stato di avanzamento
dell'upload/download (10%, 30%, ecc...) e volessi poter interrompere tale
operazoine, come potrei far dialogare GUI con ftp.exe?
Prima di rispondermi è doveroso aggiungere un'ultima cosa. Non ho una
utility tipo ftp.exe che voglio gestire: sono nella situazione che sia
ftp.exe che la GUI sono interamente programmate da me e quindi, avrei la
facoltà di modificare ftp.exe a mio piacimento. In pratica voglio fare un
applicativo testuale potente ma dotarlo anche di una GUI usabile e volevo
sapere se vi erano delle tecniche/meccanismi noti e accreditati per far
questo senza "fare schifezze".
Grazie mille sopratuttto per la pazienza avuta nel leggere il post un po'
lunghetto.
Buona Giornata
Adriano

 [...]
1. Se il programma in questione (es.: ftp.exe) non l'hai scritto tu, e
quindi non hai notizie certa del fatto che possa fornire informazioni di
quel che sta facendo mentre lo sta facendo (es: una percentuale di
progresso), allora fai prima a riscrivertelo.
2. Il mondo Unix differisce da quello Windows per molti aspetti, e questo e'
una caso esemplare, perche' riguarda la filosofia dei due sistemi. Sotto
Unix un programmatore sviluppa per altri programmatori, per cui rende il suo
software usabile da altri programmi e documenta il tutto. Sotto Windows, di
solito, si programma per l'utente finale, per cui l'applicativo dovrebbe
gia' avere una GUI. Quando si genera una utility a linea di comando sotto
windows, di solito non si hanno la stessa "accuratezza" e pulizia che si
hanno sotto Unix (e' una mia opinione).
3. Se dovessi scrivere un sw che deve funzionare sia tramite GUI che da
linea di comando, scriverei una libreria intermedia (lib statica o DLL) con
tutta la parte operativa (es.: le primitive di comunicazione secondo il
protocollo FTP). Poi svilupperei due programmi: una console application per
l'utility a linea di comando, ed una applicazione a finestre per la GUI.
Entrambi i programmi utilizzano la librearia comune per ottenere il loro
scopo.
Ciao. Federico.

 ha scritto nel messaggio
news:EPUPb.278875$e6.10...@twister2.libero.it...


> Qualcuno ha qualche idea?
Dall' FTP.exe ottieni l'handle della finestra della GUI e le invii comandi
con Send/PostMessage() . Addirittura, per l'avanzamento potresti ottenere
l'handle dello stesso gadget di avanzamento e aggiornarlo con una
SendMessage direttamente. Perň č consigliabile inviare un comando alla
finestra principale e lasciare che sia questa a interpretarlo di conseguenza
(mi sembra piů organico).
Esistono tecniche di comunicazione piů avanzate, come ad esempio l'utilizzo
dei mapped-file tramite DLL , perň se devi passare solo un comando, la
Send/PostMessage() dovrebbe andare bene.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 dei mapped-file tramite DLL , però se devi passare solo un comando,
    Sai dove posso trovare in MSDN o altro un po' di documentazione sui
mapped-file?
    In linux/unix mi sa che si usano dei file speciali che altro non sono
che delle code LIFO/FIFO. C'è l'analogo anche in Windows?
Grazie Fabio, grazie a tutti voi e Buona Giornata
Adriano


I mapped file a grandi linee sono delle aree di memorie virtuali che possono
essere condivise ottenendone un handle, poiché la memoria è virtuale,
normalmente un puntatore alla memoria valido in un'applicazione non è valido
nell'altra. In effetti, esiste anche un'API per ottenere un puntatore valido
passato da un'altra applicazione... Insomma le tecniche sono diverse...
dipende dagli scopi.


 con Send/PostMessage() . [...]
Sei sicuro?!?
Credo che Adriano stia parlando di FTP.EXE a linea di comando,
quindi si tratta di una console-application, che e' windowless.
In questo caso l'unica possibilita' e' una redirezione dell'output...
Ciao.
Federico.

 Sei sicuro?!?
 Esatto Federico, hai colto il problema. io vorrei che FTP.exe o altre a
linea di comando abbiano la possibilità di notificare eventi o lo stato di
alcune operazioni ma a priori non debbano "conoscere" le applicazioni GUI.
Io vorrei il contrario, scrivere la GUI che sa "come gestire" e "cosa
chiedere/ricevere" da ftp.exe
Grazie mille :)


 linea di comando abbiano la possibilità di notificare eventi o lo stato
di...
Sinceramente non so se la SendMessage() non funzionebbe in un programma
compilato per Console (pensavo che l'unica differenza fosse il fatto che, al
lancio dell' .EXE , venisse creata una console automaticamente, senza che
sia il programmatore a farlo).
Guarda, puoi sempre compilare un'applicazione col sistema Win32 (nessuno ti
obbliga a creare una finestra) e poi ti apri la tua bella console. Vedi
funzioni GetStdHandle() e AllocConsole() .
Ecco come funzionerebbe:
Al lancio dell ' FTP.EXE , controlli se esiste una console valida
(GetStdHandle) , in quanto l'utente potrebbe lanciarlo da shell e allora non
ti serve una *nuova* console.
Se non esiste, la crei tu stesso -> AllocConsole() e (eventualemente)
CreateConsoleScreenBuffer() . Nel caso l'utente avvii il programma con il
click del mouse.
Fai una FindWindow() alla ricerca della tui GUI.
Ti comporti di conseguenza.
Semplice, no ? :)


 ha scritto nel messaggio
news:80Z181Z209Z243Y...@usenet.libero.it...

Ciao Fabio,
              grazie per la risposta, è veramente valida. Non vorrei
sembrarti inopportuno, ripeto, le tue dritte mi saranno preziose in altri
ambiti sicuramente! Il mio unico problema è che, in quello che voglio
sviluppare, la situazione è un po' invertita! In pratica non voglio che,
restando nell'esempio di ftp.exe, quest'ultima sappia nulla
dell'applicazione GUI.
 Sappia nulla = conosca la struttura/interfaccia dell'applicativo GUI e,
soprattutto, sia lei a controllarlo.
Piuttosto vorrei che l'applicativo GUI possa "intercettare" e/o ricevere
informazioni da ftp.exe una volta lanciato. Sarebbe bello poterci pure
comunicare, del tipo, inviare un BREAK per, ad esempio, interromere un
upload in corso.
Grazie ancora Fabio e Buona Giornata



--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

mi e' capitato un po di tempo fa di vedere un esempio che faceva cio'
con CreateProcess lanciava l'applicazione console e inoltre apriva una
pipe su stdin e stdout ... 
mi sembra la maniera piu elegante ... 
non avendo avuto occasione di utilizzare questa tecnica in prima
persona le indicazioni che ti do nonsono cosi dettagliate ...
Ciao
Luca



    Veramente molto interessante. Peccato che non so come aprire e gestire
un pipe :). Faccio qualche ricerca.. :) Grazie Mille


 questo senza "fare schifezze".
ftp.exe è tuo, la GUI è tua... fai 2+2! Perché non ne fai un unico
programma anzichè due separati? Cmq i meccanismi di IPC (= InterProcess
Comunication) in Windows non mancano affatto: c'è il DDE (un po'
vecchiotto però), ci sono le mailslot e le pipes, c'è il messaggio
WM_COPYDATA (imho il più semplice di tutti)...
ciao.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 WM_COPYDATA (imho il più semplice di tutti)...
    Ciao Uomo del Codec :D, grazie per il tuo suggerimento. La divisione
nasce dal fatto che voglio fare programmi indipendenti tra di loro di modo
da porterli attaccare a cascata un po' come quando in unix si fa qualcosa
tipo:
    ps aux  | grep --color emacs | more
mi piacerebbe potermi documentare su mailslot e pipes. Sai dove posso
guardare? Grazie mille.
P.S. Cos'è un codec? Te lo hanno tramandato i tuoi .avi? :D


[...] c'è il messaggio WM_COPYDATA (imho il più semplice di tutti)...
Il WM_COPYDATA e' poco conosciuto ed usato, ma in certe situazioni e'
davvero la soluzione piu' comoda, semplice ed anche elegante.
Nel caso di applicazione GUI + Console non si può usare, perche'
l'applicazione Console non ha loop dei messaggi...
Ciao. Federico.

> P.S. Cos'è un codec? Te lo hanno tramandato i tuoi .avi? :D
bella questa! :-)