Newsgroup: it.comp.lang.visual-basic
Titolo: Problemi con la creazione di un file .bat (Spero di non essere OT)

Debbo creare un file .bat, esso deve avviare un programma (windows) e "fare
click" su due bottoni presenti nell'unico form del programma.
I due bottoni si attivano usando la tastiera con i tasti ALT+I e ALT+E... ed
ecco il problema: come inserire queste due operazioni sul file bat?
Un'ultima cosa... finita l'esecuzione del file .bat, la finestra dos aperta
su windows dovrà chiudersi da sola... come si fa?
Grazie infinite a chi saprà e vorrà rispondermi!

 finestra dos aperta su windows dovrà chiudersi da sola... come si fa?
Se ha un OS Win9x vai sul corrispondente file .pif (che viene creato quando
un file batch viene eseguito per la prima volta in ambiente Win)
e -Programma-Chiudi al'uscita (o nome simile...)
--
Dark Hado
"Pensare non è essere d'accordo o in disaccordo: questo è votare."
Robert Lee Frost

 wrote in message
4D489.231515$Jj7.5...@news1.tin.it...



 le istruzioni sono giuste ma i tempi di esecuzione no  ....
dopo la shell devi mettere un ritardo per dare il tempo a windows di
caricare il programma e magari un appactivate prima del sendkeys
ciao

 caricare il programma e magari un appactivate prima del sendkeys
giusto...oppure usi una shell sincrona

> giusto...oppure usi una shell sincrona
 in che modo scusa?
ciao :))


Naturalmente i comandi devono essere "temporizzati", hai fatto bene a
precisarlo
Mi scuso per la mancanza ;-)


 wrote in message
BS689.232236$Jj7.5...@news1.tin.it...


 End Sub
Non penso che funzioni senza uno sleep....
puoi fare la prova con notepad :
Shell "notepad", vbNormalFocus
SendKeys "ciao"
Un *.vbs in queststo caso sarebbe comunque piu
piccolo e funzionale di un bat o di VB.
Sub delayedSendKeys(str)
     WScript.Sleep 500
     WshShell.SendKeys str
End Sub
Dim WshShell, oCalc, oNotepad
Set WshShell = CreateObject("WScript.Shell")
Set oCalc = WshShell.Exec("calc")
WScript.Sleep 1500
Set oNotepad = WshShell.Exec("notepad")
WScript.Sleep 500
WshShell.AppActivate oCalc.ProcessID
delayedSendKeys "1{+}1~"
delayedSendKeys "^C"
delayedSendKeys "%{F4}"
WshShell.AppActivate oNotepad.ProcessID
delayedSendKeys "1 {+} 1 = ^V"
WScript.Sleep 1500
delayedSendKeys "%{F4}"
WScript.Sleep 500
delayedSendKeys "n"
delayedSendKeys "%{F4}"
--
Fosco

 correttamente.
Si ,hai ragione, interessante...
"interrompe l'esecuzione in modo che il sistema operativo possa
gestire altri eventi"
--
Fosco
Il Sito piu' cool ???
http://groups.yahoo.com/group/x-men-italy/files/LO/quoting.txt

 gestire altri eventi"
Evitate il più possibile l'uso di doevents nel vostro codice...
risparmierete ore e ore di debug dato che il comportametne di doevents
specialmente per i "ritardi" è aleatorio! :(
Piuttosto usa l'api sleep...

 specialmente per i "ritardi" è aleatorio! :(
Mi permetto di dissentire. Sono perfettamente d'accordo se dici che
non serve in un ciclo di ritardo (che non dovrebbe esistere in ogni
caso, in una interfaccia ad eventi ben progettata).
Ma DoEvents è essenziale, per esempio per non inchiodare il sistema
mentre il tuo prog esegue delle routine lunghe. In un mio prog, ad
esempio, eseguo delle ricerche e dei confronti fra stringhe e substringhe,
per svariati milioni di operazioni in totale; senza dei DoEvents ben
piazzati, l'intero sistema sarebbe inutilizzabile mentre quel prog gira,
invece così può lavorare in background anche per un'oretta, e venir
fuori da solo quando ha finito. Io, nel frattempo, anche se il sistema
è lento, seguito a lavorare (o a leggere il newsgroup, o magari il
sito del Dr Zap... ;-P ).
In più, nel problema in esame, che, ricordo, verteva sulla necessità di
inviare delle sequenze di tasti ad un'applicazione esterna, è necessario
lasciare al sistema (e all'appl.) la possibilità di rilevare ed eseguire i
comandi inviati. In questo contesto sono necessari sia l'AppActivate
(perché la SendKeys invia i comandi all'app. attiva) che i DoEvents.
Bye, G.

 caso, in una interfaccia ad eventi ben progettata).
Naturalmente subito dopo averlo scritto mi sono venuti in mente
due o tre controesempi, ma che vuoi, la vita è anche questo. :-)
In ogni caso, per un ciclo di ritardo io userei Timer (la funzione,
non il controllo) combinata come dici tu con la Sleep... e un
DoEvents per buona misura ;-).
Bye, G.

 DoEvents per buona misura ;-).
Il doevents è micidiale perchè in generale scombina il "naturale" svolgersi
degli eventi in un programma VB!
L'unica utilizzo lecito dei doevents imho è nei lunghi cicli... ma nei cicli
btw non hai il problema del sovrapporsi degli eventi dato che vb non è
multithreading!;)
Mai deve essere utilizzato per generare attese (al limite per liberare le
risorse ma non per introdurre attese) perchè il suo comportamente in termini
di attesa è aleatorio e dipende dal carico e dalle caratteristiche della
macchina e dell'OS! ;)

 degli eventi in un programma VB!
Non l'ho capita. A meno che... mi viene un dubbio: siamo
sicuri che ti prendi cura di disabilitare tutti i comandi quando
_non devono_ poter essere attivati ?
Bye, G.

"Paperino" <non...@lo.dico> ha scritto

Non ha tutti i torti, anche se il tuo dubbio diventa un ... buon consiglio
(ma anche una barba matusalemmica da applicare).
Se la coda degli eventi è già stata composta, il Doevents li esegue, anche
se l'oggetto che li ha scatenati (meglio sarebbe dire "messi in coda") è
disabilitato.
A proposito (?), vedi come si mettono in coda gli eventi Click e GotFocus di
un CommandButton quando vi si clicca sopra col mouse. Vedi poi come lo fanno
quando il bottone viene attivato con Alt+carattere_sottolineato...

 quando il bottone viene attivato con Alt+carattere_sottolineato...
Vero, si inverte l'ordine. Se clicco su un pulsante che non ha il focus,
l'ordine è (copio e incollo dalle prove):
 Sono in MouseDown
 Sono in GotFocus
 Sono in Click
 Sono in MouseUp
Mentre con Alt+car è:
 Sono in Click
 Sono in GotFocus
 Sono in KeyUp
 Sono in KeyUp
Non ci avevo mai fatto caso... 8-|
Bye, G.

 Spiegami meglio, non ho capito. O perlomeno non mi è mai capitato.
Vado a memoria (ma non sottoscrivo perchè non ho ri-verificato), insomma,
questo è un esempio.
Immagina il LostFocus di un oggetto e il GotFocus di un altro, questa
dovrebbe essere la sequenza (analogamente all'incongruenza di prima, _non è_
sempre vero!)
Immagina, comunque, che la sequenza sia davvero questa. Se l'evento
LostFocus prevede una serie di istruzioni (cosa, IMHO, assolutamente
deprecabile!) e magari c'è un DoEvents (= restituisci il controllo al
sistema ed esegui le "cose" in coda), niente di più facile che venga dato il
controllo all'evento GotFocus, prima che le istruzioni del LostFocus siano
terminate. Tutto, ovviamente, se l'evento GotFocus è già stato messo in coda
nella pila/stack degli eventi di VB.
Lo so, parrebbe incredibile, quindi non mi portare in giro. :-)
Mi riservo di scrivere e provare un esempio che lo dimostri.

 Non ci avevo mai fatto caso... 8-|
Siccome non sono il "bastian contrario" che a volte mi si dipinge, anzi,
come ho più volte avuto modo di dire, sono un "onesto", devo ammettere (ma
ribadisco che l'incongruenza è provata) che un "senso" (non certo una
giustificazione) può esserci:
Com'è noto, l'operatività standard di Windows (anche qui, non sempre
rispettata), indipendentemente da VB, è che l'evento Click di un oggetto
(diciamo un CommandButton che siamo sicuri...) venga scatenato non al
MouseDown, ma al MouseUp, a condizione che questo si verifichi sullo stesso
oggetto che ha "attivato" il MouseDown (ovviamente, molti uTonti, pigiano
qui, poi, in un attacco di tremito, mollano là e ti chiamano perchè
"cliccando sul tal bottone non succede niente"). Credo che questo sia stato
fatto (e mi sembra una buona idea) per consentire all'operatore di avere
qualche istante in più (il tempo di reazione del suo indice, se superiore a
quello della materia grigia) per ... cambiare idea se si accorge di aver
sbagliato oggetto.
Immagino, questo davvero non lo so, ma si può provare in VB, che invece il
GotFocus (giustamente, direi) venga scatenato al MouseDown (che senso
avrebbe lasciare come controllo corrente uno diverso da quello sul quale ho
già cliccato?).
Bene, nel caso di un bottone "attivato" con Alt+carattere_sottolineato e
correntemente senza fuoco, l'evento MouseDown, ovviamente, non si verifica,
quindi (e qui è sbagliato!) nemmeno il GotFocus che, sempre IMHO, viene in
qualche modo "forzato" (per non saper nè leggere, nè scrivere) dall'evento
Click. Ecco perchè, nel caso descritto, il GotFocus avviene dopo il Click.
Non so, forse ho detto un ammasso di eresie, ma a me così pare.
In ogni caso, io adotto sempre questa regola: Le istruzioni di "vera"
elaborazione, vanno solo nell'evento Click, mai nel GotFocus e, più in
generale, non dare mai per certo che il GotFocus si verifichi prima del
Click e, come scrivevo nell'altro post, non dare mai per certo che l'evento
LostFocus si verifichi prima del GotFocus di un altro oggetto. Mai mettere
istruzioni di "vera" elaborazione, nell'evento LostFocus. Il Validate mi è
stato "regalato" con una versione successiva di VB. Ormai avevo risolto
senza di lui: non l'ho mai usato.

 Mi riservo di scrivere e provare un esempio che lo dimostri.
Quando vuoi.
**********
Approfitto per rispondere all'altro post: sono d'accordo al
cento per cento, soprattutto con l'ultima parte.
Ad una ulteriore prova, l'ordine degli eventi in caso di click del mouse č:
- alla pressione del mouse, MouseDown, che scatena
    l'eventuale GotFocus
- al rilascio del mouse, prima il Click, poi lo stesso MouseUp.
- al rilascio del mouse _fuori del tasto_, c'č il solo MouseUp.
Bye, G.

 End Sub
Perfetto... ma quello è normale :-). Voglio dire, mi aspettavo
proprio quel funzionamento, e DoEvents serve proprio a quello.
Fai conto di voler interrompere un Do Loop o un For Next
di quelli luuuunghi, cliccando su un pulsante: all'interno del loop
devi controllare una var Bool, che cambia di valore cliccando
il pulsante, giusto ? Se _non_ metti il Doevents, potresti non
avere la possibilità di far funzionare la cosa.
Se invece quel comportamento non ti sta bene, beh, è proprio
quello che io evito disabilitando le parti dell'interfaccia che in
quel dato momento potrebbero interferire con l'elaborazione
in corso. Sarà una barba, ma è così che s'ha da fare...
Bye, G.

 avere la possibilità di far funzionare la cosa.
Paperino, non intendo certo "banalizzare" quanto dici, ma è piuttosto ovvio
e (si spera) tutti lo dovremmo sapere.
Quello che non appare immediatamente comprensibile (ammesso che sia anche
noto) è che il GotFocus del nuovo oggetto sia già in coda (e venga quindi
eseguito col DoEvents), ovvero nato e presente anche se in attesa, prima che
le istruzioni del LostFocus (con o senza DoEvents) siano concluse, anche se
completamente assenti (il che sarebbe solo un caso particolare che non muta
la logica). Specifico: Per me non è immediatamente comprensibile.
Personalmente (per carità, non ho pretese di "progettazione di ambiente")
avrei creato e messo in coda il GotFocus (che ha tutti i diritti di esistere
perchè ho cambiato oggetto) _solo dopo_ la fine del LostFocus. Sarebbe
bastato parcheggiare il riferimento al controllo che sovrà diventare quello
attivo. In questo senso, io non ho difficoltà ad ammetterlo e a dirlo: non
mi piace. Tutto qui.
Aggiungo: Quel mio "Sarebbe bastato parcheggiare il riferimento al controllo
che sovrà diventare quello attivo" parte da un presupposto di una vera
integrazione e contatto fra i vari sviluppatori dell'ambiente. IMHO
(cacchio, mi sto ripetendo) in M$ ci sono tante stanze, tutte chiuse a
chiave e con tanto di guardia all'esterno. Nessuno sa cosa accade nelle
altre stanze e uscirà dalla propria solo quando avrà concluso la sua parte
di commessa. Un fattorino passa da ogni stanza, porta i viveri e pulisce il
water. No, i panni sporchi, no. Serve a far aumentare la produttività. Alla
fine preleva il prodotto. No, non lo porta da Bill per l'assemblaggio, ma da
poche persone "fidate" che hanno esclusivamente quel compito e non conoscono
(le fughe di notizie progettuali, si sa, nel mercato sono perdite immense)
le caratteristiche della commessa principale. Costoro, ovviamente,
scompariranno immediatamente dopo in qualche fiume disperso nella Cina
centrale.
Morale (un peletto esagerata, lo faccio apposta, ma _per me_ concettualmente
vera): Non è così certo che chi provvede a pubblicare/esporre/scatenare
l'evento GotFocus di un controllo, si preoccupi più di tanto di come lavori
(e se esiste) l'evento del LostFocus di un controllo che si sta facendo
nella stanza accanto. Per questo, tranquillo nella coscienza, non impegna
troppe energie per strutturare l'evento LostFocus del proprio controllo. Se
poi la gestione e la "cascata" degli eventi viene gestita da altri, per
tutti i controlli, beh, allora non ci sono dubbi: questi ultimi sono
assolutamente pazzi.

 assolutamente pazzi.
Non sono sicuro di quello che dico, quindi prendi le mie parole
con delle molle da due metri, ma penso che nel caso specifico
il focus sia gestito direttamente o indirettamente dal S.O., non
dai singoli controlli. Quindi... è anche peggio. :-(((
In questo caso, ci sarà pure una logica recondita, ma a me sfugge.
Bye, G.


Io disabilito tutti quelli che possono essere disattivati... ma quando sul
form hai una griglia (a volte non si può farne a meno) e qualche altro
controllo ti assicuro che l'inserimento di qualche doevents ti fa impazzire!
:(
Il mio messaggio originale voleva dire: diffidate dei doevents se questi
"sembrano" risolvere il vostro problema: spesso ne risolvono uno e ne
introducono dieci.
Utilizzateli solamente in loop controllati (l'ambiente per il quale sono
stati progettati). Per il resto ci sono i vari sleep o refresh! :)
Ciao