Il 26/01/2011 23.11, Paolo Mantovani ha scritto: > Il 26/01/2011 18:23, M. Manca ha scritto: > [....] >> Data la fuga di massa da OpenOffice.org e le prese di posizione >> dittatoriali di Oracle.... la 3.3 rischia di essere l'ultima rel. di >> OpenOffice.org. > > In questo caso bisognerà capire chi continuerà a sviluppare il codice > visto che LibreOffice usa per intero quello sviluppato da Oracle beh... diciamo quella sviluppata finora da Sun e che Oracle vorrebbe dismettere > > > >> Personalmente punto su LibreOffice, al di la del nome hanno accolto >> l'idea di essere maggiormente compatibili verso VBA e MS > > Inseguire MS sul suo terreno di solito è un'idea molto costosa, > talvolta suicida. > In ogni caso la compatibilità VBA per adesso è più che altro uno > slogan e ho sempre avuto parecchi dubbi sul fatto che possa diventare > realmente utilizzabile. > > Il fatto è che il target di questa feature sono gli utenti che non > conoscono le macro e non le vogliono conoscere ma casualmente hanno a > che fare con documenti MSOffice contenenti macro. > > Questo genere di utenti ovviamente non ha idea di dove mettere le mani > se qualcosa non funziona. > > In altre parole, dal punto di vista dello sviluppatore, una macro dove > il 99% delle istruzioni VBA sono interpretate correttamente sarebbe un > successo inaudito, frutto di un lavoro immenso, e in effetti siamo ben > lontani non dico dal 99% ma probabilmente dal 25% (e sto ragionando > solo su Excel) > > Dal punto di vista dell'utente invece, una macro dove il 99% delle > istruzioni gira correttamente è un fallimento totale perchè quando > l'interprete trova quell'1% di istruzioni incompatibili esce con un > errore e l'utente non sa cosa fare. > > Ma se anche l'utente decidesse di voler mettere le mani nella macro > per vedere di sistemare quel piccolo 1% che impedisce alla macro di > terminare con un successo, si troverebbe in un vicolo cieco perchè il > layer di compatibilità si basa su oggetti "proxy" che mimano il > comportamento degli oggetti corrispondenti in MSOffce. > Questi oggetti proxy però non sono documentati e quindi è inutile > tentare di fare il debug. > > Il caso più frequente quindi è che la macro VBA si blocca in qualche > punto magari solo per un'istruzione e per quell'unica istruzione non > compatibile ti tocca riscriverla daccapo. > il problema è l'utenza aziendale e quella degli sviluppatori per applicazioni verticali su base Office. Effettivamente il modello COM + VBA non è male, certo è confinato a MS WIN. Su questo piano OOo è più indietro sia come diffusione sia come complessità. L'interoperabilità con Excel dovrebbe essere migliorata o almeno dovrebbe essere previsto un traduttore perché modelli, template, fogli belli e pronti, esempi, codice allegato a libri e riviste.... all'80% è per excel, 20% per tutti gli altri. > > e di allontanarsi >> dalle dipendenze di Java. > > sono d'accordo > > Se poi abbandoneranno/riscriveranno il modulo >> UNO con qualcosa di più semplice.... allora non ci sarà più storia. > > Non capisco: UNO è una piattaforma tecnologica, come dire CORBA o .NET > Si tratta di uno strato software con cui non hai normalmente a che > fare, quindi il fatto che sia semplice o complicato non ti dovrebbe > preoccupare. > Forse intendevi dire l'API? in linea di massima UNO penso l'abbiano introdotto per avere portabilità tra win e linux e garantendo la possibilità di programmare macro in vari linguaggi. In effetti volendo interfacciarsi a OOo lo si può fare con molti linguaggi, il problema è che UNO + l'API di OOo sono eccessivamente faraginosi ed anche mal documentati. Poi il codice originale di StarOffice (quando Sun ha comprato la sw house tedesca) se non ricordo male era tutto in C/C++ poi col tempo sono stati inseriti moduli Java. > > > ciao > Paolo M > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: utenti-unsubscr...@it.openoffice.org > For additional commands, e-mail: utenti-h...@it.openoffice.org > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: utenti-unsubscr...@it.openoffice.org For additional commands, e-mail: utenti-h...@it.openoffice.org
