Newsgroup: it.comp.lang.visual-basic
Titolo: [?][API] Quali valori di wparam e lparam *NON* sono utilizzati?

Ciao a tutti.
Ho letto il bellissimo articolo di Moreno sul subclassing --c'e' un
errore di battitura che ti segnalero'-- e ne ho trovato uno bello di
Flavio Polesello che dice praticamente le stesse cose su
http://www.programmazione.it
Ecco, ora che mi e' chiaro come subclassare la mia finestra, mi serve
un consiglio: come trovo un numero da mettere in wparam o lparam che
sicuramente non sia utilizzato e che difficilmente venga utilizzato
entro breve, in modo da non combinare casini?
L'idea di base e' questa:
1. apro il mio programma
2. controllo che non ci siano altre istanze in esecuzione
3. se e' la prima istanza, tutto ok: lavoro. goto fine :)
4. se c'e' un'altra istanza, le passo un messaggio con un riferimento
a quello che mi interessa --tipicamente, nel mio caso, il nome di uno
o piu' files passati nella linea di comando--
5. chiudo l'applicazione perche' deve girare una sola istanza per
volta
fine: sono fiero :)
Rimangono insoluti alcuni problemi:
- quando passo un messaggio alla window procedure, devo passare i
campi wparam e lparam. Naturalmente il problema e' quello di scegliere
valori sicuramente non utilizzati da altri messaggi. Dove mi
consigliate di guardare?
- come faccio a fare un postmessage o un sendmessage alla window
procedure di un'altra applicazione in esecuzione?
- c'e' un modo per controllare che non esistano istanze di
quell'eseguibile --anche da path diversi--?
- tutta sta menata nasce dal fatto che se ho gia' in esecuzione
un'istanza del mio programma e doppio clicco su un'icona di un file
registrato per essere aperto col mio programma, io voglio che venga
aperto nell'istanza vecchia. Vi vengono in mente soluzioni piu'
furbe/pulite o semplicemente preferibili?
Grazie in anticipo.
Saluti che un po' alla volta mi do' alle API e a 'ste cose anche io :)
-- 
      Gianni "bugbarbeq" Rondinini, 25, RA, 242, 152
  VBR - Vero Birro Romagnolo®, diffidate dalle imitazioni!
 Opel/ECC Calibrezio EVO-IV --- Kawasaki "Gas Gas" ZZ-R 1100
 ICQ# 36893168 - IRCNet: bugbarbeq, @ on #linux-it & #NetBSD

quell'eseguibile --anche da path diversi--?
Anche qui devi avere un riferimento preciso e cercare la window, o
altrimenti lo fai creando un file (per esempio in tmp) che segnali che c'e'
gia' un'applicazione aperta (occhio al multitasking).
Salve
            Dbg

gia' un'applicazione aperta (occhio al multitasking).
Ok, infatti avevo pensato di creare una chiave temporanea nel
registro: quando il programma parte, la crea. Quando esce, la elimina.
Naturalmente, aggiorno la chiave ogni tot, perche' se il programma
crasha o viene terminato col task manager, la chiave resta nel
registro e il mio programma non parte piu'...
Saluti.


registro e il mio programma non parte piu'...
No no.
Ci sono problemi col multitasking (per simulare il problema immagina che due
programmi vengano eseguiti esattamente insieme).
Poi in caso di crash o imprevisti vari si creano casini o blocchi.
Secondo me la soluzione e' usare un file (bisogna provare).
L'applicazione quando parte apre un file in scrittura e lockato in
scrittura, dentro ci mette un identificatore (handle o ID), poi legge il
valore contenuto e se corrisponde al suo ID o handle e' autorizzata a
continuare.
Se non corrisponde usa l'handle o ID letto per mandare un messaggio al
programma precedente (verificando prima che esista) e poi si chiude.
In caso di crash o imprevisti vari il file viene sbloccato automaticamente,
o al limite limite basta riavviare win.

o al limite limite basta riavviare win.
Una cosa da niente :) Preferivo evitare di riavviare il sistema
operativo, comunque per il momento la mia applicazione non ha dato
segni di pericolo per la stabilita' del sistema e non mi preoccupo
troppo della cosa.
Ma attendo trepidante che la usi qualche "pisquano" in ufficio per
vedere il potere annientante...


operativo, comunque per il momento la mia applicazione non ha dato
E' al limite, nel 99,99% i file si sbloccano da soli, al contrario delle
chiavi del registro.
Salve
                Dbg

chiavi del registro.
E' gia' qualcosa.
Vado a provare se concludo qualcosa, intanto che aspetto conferma per
il l'hwnd da passare alla post o send message --non so se mi conviene
aspettare la risposta o meno, tutto qui--.


entro breve, in modo da non combinare casini?
Non ha senso, ne è attuabile trovare valori non usati per lParam e wParam.
Piuttosto usa un messaggio personalizzato: ti definisci un messaggio tuo
così sei libero di usare tutti i valori che vuoi per lParam e wParam.
I messaggi personalizzati li definisci semplicemente con
Const WM_MYMESSAGE = WM_USER + nnn
dove nnn è un intero a piacere.
Ciao

Const WM_MYMESSAGE = WM_USER + nnn
Ti amo... Questo e' quello che aspettavo di sentirmi dire... :)
Ora mi sento meglio.
Saluti.


 procedure di un'altra applicazione in esecuzione?
Cerca su MSDN IPC = Interprocess Communication.
Ciao.

Cerca su MSDN IPC = Interprocess Communication.
Ok, do' un'occhiata.
Grazie anche a te.
Saluti.
-- 
      Gianni "bugbarbeq" Rondinini, 25, RA, 242, 152
  VBR - Vero Birro RomagnoloŽ, diffidate dalle imitazioni!


 completo.
E' una buona idea, avendo cura di gestire gli eventuali valori lasciati
per errore nel registro.
Oppure utilizzare una Mailslot (vedi MSDN) ed utilizzare il messaggio
sempre come avviso.
Ciao.

aspettare la risposta o meno, tutto qui--.
Secondo me e' meglio che studi, conoscere le fondamenta di win e' importante
e abbastanza enorme.
Salve
            Dbg

   VBR - Vero Birro Romagnolo®, diffidate dalle imitazioni!


Ottimo!
Anche se ci sono problemi collaterali, tipo porta gia' occupata, nessun
protocollo installato, qulache altro che ti manda messaggi su quella porta,
ecc.
Salve
                Dbg
giorgio1 ha scritto nel messaggio


 ha scritto nel messaggio
news:mnbb6.116440$eB2.8...@news.infostrada.it...


protocollo installato, qulache altro che ti manda messaggi su quella porta,
Il mio programma verra' sicuramente utilizzato solo in azienda da me,
perche' se interessasse a qualcun altro sarebbe troppo bello --e
redditizio...--.
Quindi sono *sicuro* che ho almeno il TCP su tutte le macchine e
utilizzando quello sono piu' che a posto. Di porte libere ce ne sono
tante, comunque e' anche vero che e' sufficiente controllare
all'apertura se quella che scelgo io e' libera ed eventualmente
spostarsi su un'altra salvandosi da qualche parte --ad esempio, nel
registro-- per quale si e' deciso.
Il discorso del Winsock non mi dispiace per niente, anzi mi interessa
assai, visto che dovevo approfondirlo per un altro progetto che
partira' tra poco. Penso che provero' con quello e vado a leggermi i
vecchi post di Skunk.


e abbastanza enorme.
Ho studiato tanto e so quello di cui parliamo. Pero' a farlo in VB con
le API non mi viene per niente naturale :\
Faro' tante altre prove...


lo Spy++ non vedo arrivare niente.
????? che vorresti vedere? se vuoi essere sicuro manda messaggi dall'effetto
evidente, tipo WM_CLOSE.
Auguri
Salve
                Dbg

Auguri
Grazie.
E grazie anche per l'aiuto.


E grazie anche per l'aiuto.
Prego.
Io ho ancora gli incubi quando penso a quando ho voluto a tutti i costi
affrontare i problemi del multitasking e multithread e di passare i dati da
un'applicazione ad un altra (mi son detto "questa non e' progresso, e' solo
il solito bordello modernizzato").
Salve
                Dbg

 furbe/pulite o semplicemente preferibili?
Identifica la tua Window, MDI suppongo, utilizzando la Caption e la Classe
(ThunderMDIClient o simili ... guarda con Spy++) e ricavane l'Handle,
sfruttando p.e. la funzione "FindWindowLike".
Io faccio un PostMessage utilizzando l'Handle della MDI della vecchia
istanza, come messaggio un WM_DROPFILES, simulando quindi un drag-n-drop di
file, ma non sono riuscito a capire come fare ad inserire il puntatore
giusto in wParam, mentre per lParam dovrebbe essere certo un byval 0&.
Si consideri che la MDI è subclassata e filtra i messaggi di drag-n-drop,
accettando il trascinamento di file (questo fra l'altro ne aggiunge la
funzionalità anche da Gestione Risorse etc.)
Qualcuno sa come fare un puntatore al nome del file per poi "spararlo" nel
PostMessage?

Non puoi e non serve.
Se il puntatore e' di un'altro processo e' inutilizzabile.
La memoria di ogni processo e' separata, allo stesso indirizzo ci sono cose
completamente diverse.
Salve
            Dbg
Marco ha scritto nel messaggio



Beh questo piu' che un problema e' una soluzione...
Certo, rendi incompatibile il tuo programma con un eventuale nuovo software,
ma per quello basta creare una chiave di registro in cui scrivere la porta
se non e' quella di default.
L'idea e' questa:
Il mio programma parte, si lega alla porta e resta in attesa.
Una seconda istanza del mio programma parte, tenta il bind e si schianta.
A questo punto manda un messaggio alla prima istanza sulla porta che ha
trovato chiusa e si suicida.
Ecco risolto il problema del passaggio dati, dell'attivazione delle due
istanze e di tutto il resto.
Ciaotutti,
Alessandro

il solito bordello modernizzato").
Piu' o meno e' la stessa cosa che sto pensando io: tutto chiaro in
testa, tutte cose concettualmente facili, tutto bello e piacevole da
realizzare. Finche' non cominci a farlo davvero =)


 controllare se un'altra istanza e' in esecuzione. Non avendo mai usato
Per controllare se un'altra istanza è in esecuzione basta controllare la
proprietà App.PrevInstance



No, non funziona se lanci l'eseguibile da 2 directories diverse.


anche ultimamente.
Mica vero, il fatto che non rilevi programmi lanciati da cartelle diverse e'
un caso particolare che puo' essere insignificante o perfino ben accetto.
Basta esserne a conoscenza.
Salve
            Dbg

Basta esserne a conoscenza.
Dall'MSDN:
*****
PrevInstance
This property returns a value that indicates whether a previous
instance of an application is already running.
Syntax
object.PrevInstance
Parameters
object 
Object expression that evaluates to an App object. 
Remarks
You can use this property in a Load event procedure to specify whether
a user is already running an instance of an application. Depending on
the application, you might want only one instance running in Windows
CE at a time.
*****
Se ci fosse scritto che viene rilevato soltanto nell'ambito della
stessa directory di lancio, sarebbe meglio.
Oppure non ci hanno pensato quando hanno creato la proprieta'
PrevInstance dell'oggetto App e dopo hanno ritenuto di non modificare
piu' il behaviour di tale proprieta'.
Boh... Comunque rimango ancora il problema di vedere se il mio
eseguibile sta eseguendo ;)
Scherzi a parte, l'escamotage che abbiamo studiato insieme sul gruppo
per vedere se l'applicazione e' gia' in esecuzione e' efficace, ma mi
sembra un po' fuori luogo dover impazzire cosi' tanto.


dell'app.
Capito alla grande. Stavo ravanando nelle mie scartoffie per trovare
un'idea furba per gestire "a mano" un semaphore, non sapendo che il
sistema te li mette a disposizione :)


sistema te li mette a disposizione :)
Tieni conto che sono oggetti globali, cioe' vengono visti da tutte le
applicazioni, se per colmo di sfortuna qualche altra applicazione ne ha
creato uno con lo stesso nome gli effetti sono imprevedibili.
E' facile che in caso di errore del programma l'oggetto rimanga attivo e in
quel caso ti si pone il problema sopra.
Sto costruendo una classe che gestisce i file *.INI, per provarla lancio
otto programmi che leggono una chiave da un file, aumentano il valore di uno
e lo scrivono nel file e fanno dei controlli di sequenza numerica corretta,
il tutto in loop continuo.
Nei test termino brutalmente i programmi (per fare prove 'cattive' il lock
del file viene tentato solo per poche volte e per poco tempo, dopo di che
fallisce (cosa che in pratica sara' evitata)), poi apro e chiudo altre
applicazioni, per rendere il multitasking 'irregolare'.
In una giornata di prove non mi e' mai capitato che di dovere riavviare win
o sistemare a mano qualcosa, riavviato un programma di test (mentre gli
altri programmi continuavano a lavorare) qualsiasi condizione erronea veniva
recuperata.
Il lock dei file e' complesso, fastidioso, ma efficace, sicuro, e
praticamente sempre recupera le condizioni di crash.
Poi naturalmente uno magari decide di evitare complicazioni e di fare scelte
piu' semplici e magari con qualche limitazione.
Salve
                Dbg

piu' semplici e magari con qualche limitazione.
Vero. Pero', visto che prima o poi perdero' il tempo necessario a
sistemare questo problema, scegliero' di fare la cosa piu' sicura e
meglio strutturata, cercando, magari, di isolarla il piu' possibile
dal resto del programma in modo da renderla riutilizzabile.
