Newsgroup: it.comp.lang.vo-clipper
Titolo: OLE e gestione errori

Ma e' possibile che in una finestra che contiene un oggetto OLE
qualsiasi errore, anche il piu' cretino, possa causare un errore che
necessita di un reset della macchina per poter uscire dal programma?Mi
succede con Vo2.0B4 con qualsiasi ocx e qualsiasi errore. Se va bene
mi appare una finestra Ignore Abort. Premendo Ignore va tutto a posto,
se premo abort il programma mi da un errore perenne (mi pare 4660) e
non mi lascia piu' chiudere la finestra di errore che si ripresenta
all'infinito. In fase di debug questo causa una enorme perdita di
tempo. Qualcuno ha una soluzione?
Ignazio 
GSS©
More than 90 HiRes images in my home page  
http://www.geocities.com/~puddu/
Oltre 200 Immagini di endoscopia digestiva
http://www.areamedica.com

 tempo. Qualcuno ha una soluzione?
Ho avuto la stessa esperienza, soprattutto con gli OCX male documentati
che mi costringevano a fare esperimenti prima di un uso corretto.
Non credo sia colpa di VO che si trova a gestire queste "scatole nere"
che rispondono in maniera imprevedibile e non consentono una corretta
gestione dell'errore.
In fase di test di un programma con un ocx non oso entrare senza il
debugger che offre, tranne nei casi disperati, una via di fuga.
Saluti
Paolo Cherubini
Sent via Deja.com 
http://www.deja.com/
Before you buy.

 gestione dell'errore.
A parte il discorso su VO che non conosco, ma in generale condivido
pienamente il discorso. L'attuale trend verso la programmazione per
componenti non sta dando, secondo me, i risultati sperati.
Non ha niente a che vedere, ad esempio, con i componenti (chips) sui
quali l'elettronica si basa ormai con pieno successo da molti anni.
Forse questo è dato anche dalla diversa serietà (e dai diversi
investimenti di denaro) delle industrie che producono e testano i chip
elettronici rispetto alle dittucole che sviluppano i componenti
software.
Purtroppo il mercato del software diventa sempre più uno strumento nelle
mani di chi vuole fare soldi in fretta e senza troppo impegno di
capitali. Questo almeno in generale.
EMG

 EMG
E' stato facile, in passato, cadere nella trappola degli OCX DLL
esterne e OLE.
Chi ha iniziato a programmare con il DOS si metteva sulla tastiera con
l'obiettivo di risolvere un problema concreto. Costruito il software di
base si procedeva alla "limatura" per offrire prodotti "affidabili".
Con il Windows il discorso e' cambiato.
L'estrema complessita' del sistema grafico ha reso difficile quello che
una volta era ordinaria amministrazione.
Una istruzione banale come:
   @ 10, 15 say "Digitare..." get Var1
   READ
in Windows richiede (a parte l'uso di strumenti standard che non
soddisfano quasi nessuno), una vera e propria contorsione intellettuale.
I dispositivi sono diventati complicati e l'energia del povero
programmatore viene quasi tutta spesa nella gestione dei DC.
La paura di non essere piu' efficiente costringe ad adottare, come
prima reazione istintiva, i prodotti facili, che con pochi click
consentono di realizzare applicativi; si aggiungono due o tre OCX, per
la stampante, per i grafici e per visualizzare i files dati ed ottieni
una bella "americanata" che non serve a nessuno.
Le "terze parti" hanno colto questa opportunita' sfornando una miriade
di OCX venduti a caro prezzo.
Personalmente ho buttato tutto via, dove non arriva VO con le sue classi
standardizzate, arrivano le API di Windows.


esterne e OLE.
Ok, ma discorsi filosofici a parte, non esiste un rimedio? Il problema
esiste con TUTTI gli OCX quindi non puo' essere imputato a una singola
ditta produttrice. E' CAVO che non gestisce bene gli errori in
presenza di OCX, a me perlomeno pare cosi'.
Dite cio' che volete ma alcuni ocx a me sono stati utilissimi.


VO funziona benissimo, e' solo che non sa cosa fare con le pazzie degli
OCX o degli errori che commetti nel programmarli.
Se hai solo bisogno di uscire ecludendo il gestore degli errori di VO
puoi adottare un semplice criterio.
Racchiudi le istruzioni sospette tra
BEGIN SEQUENCE
  istruzioni che causano l'errore
RECOVER
  istruzioni di chiusura per rimediare al crash
END
Usa la funzione di gestione dell'errore che restituendo un BREAK ti
porta direttamente alle righe dopo il RECOVER in cui puoi scrivere
codice per chiudere tutto e non mandare in crash il sistema.
Ti riporto di seguito un esempio in cui oDCO e' un OCX qualunque
inserito in una finestra.
Saluti
Paolo Cherubini
METHOD LancioIlMioOCX() StandardShellWindow
LOCAL bFugaDaOCX AS CODEBLOCK, ;
      oFin AS aOCX
bFugaDaOCX:=ErrorBlock({|oE| FugaIncondizionata(oE)})
BEGIN SEQUENCE
  oFin:=aOCX{SELF}
  oFin:Show()
  // Chiamo dei metodi dell'OCX in modo incorretto
  oFin:oDCO:Xecvv("WW")
  oFin:oDCO:Ldr33ile(12, 15, 17)
  oFin:oDCO:Ldrrgfse("WW")
  oFin:oDCO:Ledgggle("WW")
  oFin:oDCO:Ldrecxce("WW")
  oFin:oDCO:Lojmbtye("WW")
RECOVER
  oFin:EndDialog()
END
FUNCTION FugaIncondizionata(oErrore)
MessageBox(NULL, "OCX in Tilt, scappo via!", "Errore", MB_OK)
BREAK oErrore


 Dite cio' che volete ma alcuni ocx a me sono stati utilissimi.
Il discorso non è sull'utilità (i componenti non sono altro che versioni
evolute del vecchio concetto di libreria) ma sulla qualità in generale
degli stessi che non risulta (attualmente) sufficientemente elevata da
poter sperare di costruirci il futuro dell'informatica (come invece è
successo per l'elettronica e i suoi validissimi componenti).
EMG




OCX o degli errori che commetti nel programmarli.
Ma il programma mi si inchioda anche se l'errore non e' generato
dall'OCX. Mi spiego: se ho una finestra aperta con dentro un OCX e
faccio un'operazione sbagliata (che non c'entra niente con l'OCX) il
programma va in loop di errore infinito e tra l'altro mi mette
l'errore a una riga completamente sballata. Se tolgo l'ocx e ripeto lo
stesso identico errore il programma mi da l'errore ma termina
normalmente. Spero di essermi spiegato.


Racchiudi le istruzioni sospette tra
Grazie mille!
Ignazio 
GSSŠ
