Newsgroup: it.comp.lang.vo-clipper
Titolo: qualcosa si sveglia ?

buon giorno a tutti e buona pasqua
sul ng internazionale ho letto che presente un nuovo software per vo
qualcuno sa di cosa si tratta ?
penso di aver capito che vi sono anche dei demo
grazie a tutti
rinnovo gli auguri
Aurora Baccio


ciao bella

 penso di aver capito che vi sono anche dei demo
 
ho visto solo due post che parlano di alternative:
- uno su uno sviluppo di Harbour e MiniGui: Harbour è uno strumento
che prende codice Clipper e lo trasporta in codice C che poi viene
compilato da un compilatore C++, usando delle librerie dal relativo
progetto opensource. Comunque penso di aver capito che il progetto
Harbour/xHarbour sia abbastanza fermo da tanti anni
- un altro su un framework per C++ e QT (che comunque è a pagamento),
perciò un linguaggio totalmente differente.
 
Non penso che uno dei due si presti a portare degli applicativi VO.
 
L'unico compilatore che conosco che potrebbe portare nel futuro
applicativi VO è X# (che attualmente sta riscuotendo un notevole
interesse tra i programmatori di FoxPro in quanto anche per FoxPro ogni
sviluppo è stato cessato).
 
Saluti
 
Wolfgang
 
 
-- 
 

Il giorno sabato 20 aprile 2019 08:37:50 UTC+2, 
aurora...@gmail.com
 ha scritto:

Buon giorno e grazie della risposta,
il mio è un duplice problema.
L'attuale applicativo di gestione è estremamente problematico per il solo pensare di trasferirlo in altro linguaggio. Ho provato a trasportare gli archivi da dbf a mysql e francamente ho subito rinunciato.
A questo si aggiunge la prossima scadenza fatturazione elettronica che dovrebbe imporsi anche per la b2c, e vorrei tanto poterlo fare senza ricorrere a dll di terze parti.
Le dico subito che ho provato ad utilizzare X#,ma il problema è sempre e comunque l'assoluta mancanza di documentazione. E la paura di trovarsi alla fine soli ed abbandonati.
A questo punto o mi decido e passo armi e bagagli a c++ (e questo è un qualcosa che non vorrei proprio fare considerato la complessiva logica degli applicativi) oppure costruisco io stessa le dll in questione, cosa non certo semplice ma fattibile.
Ecco, questo è un punto di discussione che spero si voglia sviluppare.
Aurora Baccio

Buon giorno Aurora,
 
penso proprio che si dovrebbe fare aiutare da qualcuno che Le può
consigliare.
 
Saluti
 
Wolfgang

-- 
 

 A questo punto o mi decido e passo armi e bagagli a c++ (e questo è un qualcosa che non vorrei proprio fare considerato la complessiva logica degli applicativi) oppure costruisco io stessa le dll in questione, cosa non certo semplice ma fattibile.
 
Sconsiglierei C++ a priori, e' un linguaggio ostico per chi non ha gia' 
una certa esperienza, poi sia il lato GUI che quello database non sono 
snelli, anzi.
 
Meglio C# che assieme a .NET permette l'accesso, o anche la gestione 
completa di archivi .DBF (via OleDb o ODBC), ed ha un'interfaccia utente 
piu' snella e ormai consolidata. In ogni caso si parla sempre di 
riscrittura completa, cioe' non di una cosa leggera.

 Le dico subito che ho provato ad utilizzare X#,ma il problema è sempre e comunque l'assoluta mancanza di documentazione. E la paura di trovarsi alla fine soli ed abbandonati. 
 
Esiste un programma chiamato FOX dove le danno assistenza tecnica con una modica cifra annuale. Io credo che sia l'unica via percorribile.
A breve inizieremo il passaggio di grossi gestionali in X# da codice VO, compreso l'RDD VO2MYSQL.
 
Io penso che debba investire del tempo/denaro al fine di istruirsi con completezza sul mondo VO/X#
 
Buon lavoro !


Concordo con Alessandro,
credo che l'unica strada che abbiamo noi "vecchi" programmatori VO sia 
X#. Tra le altre cose X# prevede un programma che leggendo un AEF Vo 
genera codice X#. Ho visto questo prodotto all'opera a Bolzano alla 
riunione con Robert e mi pare già abbastanza maturo, era necessario solo 
qualche correzione ai percorsi delle risorse. So che Robert ed il suo 
staf ci stanno lavorando sodo. X# è oramai alla release candidate 1.
L'assistenza è veloce e puntuale, i gruppi di discussione (uno anche in 
italiano) contemplano risposte in giornata.
Per mia scelta da anni ho deciso di abbandonare le GUI di VO ed i DBF 
(da quasi 20 anni) e scrivere direttamente codice X#, di VO uso, per 
comodità e forse anche prigrizia, solo le funzioni, le macro ed il tipo 
ARRAY. Non ho alcun problema. Le applicazioni sono velocissime, a 32 e 
64 bit (cosa non da poco).
X sharp si integra in Visual Studio, ma ha anche un suo IDE molto più 
produttivo per chi viene da VO chiamato XIDE che lavora stupendamente 
per le applicazioni desktop (winform). Inoltre XSharp dà la possibilità 
di usare direttamente l'enorme massa di DLL scritte in CSharp che 
permettono di fare di tutto e di più, io uso ICSharpCode.SharpZipLib.dll 
per la gestione dei file zip, ExifLibrary.dll per leggere i tag exif 
delle immagini, ADODB.dll per inviare mail a server SSL, 
RSSolo4ItalianSilvia per far leggere testi ai miei programmi.
 
Buon lavoro
 
Danilo


Ciao Danilo,
 
la migrazione da VO a X# può essere una cosa molto semplice e veloce,
come potrebbe essere un lavoro a grosso e impegnativo per chi ha
sfruttato le potenzialità di VO creando codice impossibile da migrare
perchè non ammesso in ambito .NET.
Inoltre il passaggio da ANSI a Unicode potrebbe creare dei problemi
perchè un carattere non è più un byte.
 
Perciò in mancanza di esperienza una consulenza potrebbe rispiarmiare
parecchio lavoro e frustrazione.
 
Saluti
 
Wolfgang

-- 
 


Buon giorno a tutti, e ringrazio per i consigli che avete voluto gentilmente prestare.
Il 90% della mia attività è in campo medico, ed ho ricevuto in eredità degli applicativi funzionanti ed efficienti tutti in VO con archivi dbf.
Di questi applicativi i medici e gli operatori non solo sono soddisfatti, ma sono tremendamente restii al cambiamento, anche se potrebbe tradursi in un miglioramento.
La nascita della ricetta elettronica ha complicato questo rapporto, per cui sono stata 'costretta' insieme ad un altro collega a creare una dll in c# che si interfaccia con i web service sogei e lavora in simbiosi con l'applicativo vo. In pratica è vo che elabora i dati e quindi li passa con un file xml alla dll, la quale provvede alla trasmissione ed alla ricezione. Questa dll è efficiente anche in Puglia, in Campania, in Toscana ed in Piemonte.
La stessa dll mi permette di trasmettere i dati relativi al 730.
Quindi in questo momento ho applicativi funzionanti anche in .net anche se in maniera non diretta.
Il problema nasce quando vo, già carente di pubblicazioni , viene abbandonato. Ma nascono nuove esigenze, certamente più complicate della ricetta elettronica, e non è tanto semplice parlare di fatturazione elettronica, in quanto occorre pensare non solo ai web service, ma anche e soprattutto al sdi, alla conservazione, al backup dei dati.
Io ringrazio coloro che sollecitano il passaggio a X#, ma come acutamente osserva il signor Riedmann non è tanto semplice passare da un linguaggio ad altro, soprattutto se l'applicativo vo opera in un campo delicato come la medicina, dove occorre sempre e comunque l'esattezza.
Inoltre X#, e non mi stancherò si ripeterlo, manca di documentazione esattamente come VO, e con tutto il rispetto e la fiducia che posso avere nei confronti del programma FOX, niente e nessuno vieta che ad un certo punto il programma venga abbandonato, come sembra sia successo per VULCAN. Lasciando le tapine come me letteralmente a cercare i sassi. E questo è successo per vo.
Invece di pensare a creare nuovi linguaggi non sarebbe meglio potenziare vo ? Creando documentazione ? Perchè abbandonarlo ? Mi  viene detto che dalla versione 2.5 alla 2.6 e poi alla 2.7 qualcuno ci ha guadagnato. Quindi perchè abbandonare una realtà ? 
Basterebbe come documentazione tradurre in italiano l'attuale help, già questo per chi mastica male l'inglese è un grosso aiuto.
Basterebbe mettere in rete degli esempi, basterebbe creare degli ocx, gratuiti o a pagamento, funzionanti. Basterebbe creare documentazione.
Io non credo a X#, e con me sono d'accordo coloro che come me hanno applicativi in vo, soprattutto nel campo medico, dalla Sicilia al Trentino.
E la paura è sempre quella, essere abbandonati per la strada senza alcuna documentazione, come hanno fatto coloro che hanno sfruttato senza ritegno VO.
Aurora Baccio

Buongiorno Aurora,
 
VO è un linguaggio da considerare "morto", nel senso che si basa su un compilatore superato e non credo che mai nessuno investirà soldi per questo linguaggio.
 
Il porting verso X# è l'unica soluzione per recuperare il proprio codice. Altri linguaggi di programmazione non hanno avuto questo bel vantaggio !
X# certo potrebbe anche cessare di esistere ma non dimentichi che è .NET pertanto se proprio un domani la dll generata da X# comunque viene "vista" come un normale linguaggio .NET ed utilizzata in C# o 
VB.NET
.
 
I DBF sono indubbiamente superati e l'unico modo per utilizzarli ancora con buone performance è via RDD che X# da a disposizione. Diversamente butta via tutto, non vedo altra scelta (via ODBC o altri mezzi è lentissimo).
 
Nel passaggio ad X# non solo recupera il vecchio codice ma avrà sia la possibilità eventualmente di migrare pian piano a .NET, sia di utilizzare la sua dll che ha scritto in C# per lo scambio dati direttamente con i webservices. Portando tutto in X#, l'unico limite è il winform che non è compatibile con la Datawindow.
 
Per quanto riguarda la fatturazione elettronica, visto il settore, le consiglio di contattare Aruba business il quale fa pagare una cifra (annuale) abbastanza  bassa per ogni medico, il quale comunque si dovrà in qualche modo profilare attraverso lei.
Essendo noi anche intermediari dell'Agenzia delle Entrate, siamo stati contattati da una software house sua collega proprio per studiare un sistema "economico" da applicare nel suo ambito, purtroppo però noi non teniamo l'archiviazione sostitutiva ma la demandiamo allo stesso sito dell'Agenzia.
Il problema nel suo caso è che ogni medico dovrebbe entrare nel proprio cassetto fiscale e registrarsi al fine di tenere anche l'archiviazione delle fatture. 
Scritto in poche righe si fa anche fatica a spiegarsi, come dice Wolfgang dovrebbe farsi aiutare da qualcuno che può darle una mano.
 
Per quanto riguarda la documentazione di VO, esistono dei libri anche in italiano fatti abbastanza bene, sicuramente meglio dei libri tradotti in C.
Dovrebbero essere ancora disponibili in giro.
 
Buon week end



Buon pomeriggio Alessandro,
io di documentazione per vo conosco solo un libro tradotto dall'inglese edito da Infomedia, che non vale nemmeno la carta su cui è scritto.
Ho altri due libri scritti in inglese, anche questi poco validi.
Se esiste altra documentazione la prego di scrivere i titoli e gli autori.
Quanto al linguaggio morto, credo che lei sia in errore grossolano.
Nessun linguaggio è morto sino a quando esiste chi lo fa vivere. E non credo nemmeno che i dbf siano superati. 
Sfido lei a realizzare quel che attualmente lavora in VO con C#.
Per quanto riguarda la fatturazione elettronica, allora sono qualche passo avanti a lei perchè ho integrato l'interfaccia aruba nel mio applicativo per cui non abbiamo bisogno del cassetto fiscale.
E tutto questo con VO.
Le chiedo scusa se le sembro scortese, ma non sopporto chi denigra il lavoro altrui.
Aurora Baccio

Buongiorno Aurora,
 
qui non c'è nessuno che denigra il lavoro degli altri, mi dispiace che pensi questo, il mio intento era darle un consiglio, evidentemente non apprezzato.
 
Mi sono permesso di darle alcuni consigli per tre motivi : questo è un neswgroup creato per questo scopo, conosco personalmente tutti a parte lei, e poi essendoci già passati avrei potuto aiutarla, anche offrendole gratuitamente un bel set di manuali VO in italiano, ma evidentemente lei non è interessata e non apprezza. Mi scuso se in qualche modo posso aver irritato la sua sensibilità.
 
Per questo motivo non le dirò altro e la lascio al suo lavoro.
 
Saluti.


Forse Aurora non avendo mai avuto esperienza seria di programmazione con 
X# non capisce quale mondo le si presenta davanti.
Da quando ho abbandonato VO che, inutile girarci intorno è morto oramai 
da almeno 10 anni, (è dalla versione 2.8 che nessuno fà più nulla e non 
credo che ci sarà più nessuno disposto ad investite tempo e risorse su 
di lui).
Da quando ho abbandonato VO, dicevo, e sono passato prima a Vulcan e poi 
a X# (passagio assolutamente indolore) mi si è aperto un mondo, ho 
trovato cose già fatte che a farle con VO, se mai ci fossi riuscito, 
avrei dovuto sputare sangue.
La documentazione: essendo X# in linguaggio Dot net di documentazione se 
ne trova quanta se ne vuole in tutte le lingue. Non capisco proprio la 
reticenza a voler migliorare. Non capisco proprio.
Con X# ho realizzato applicazioni "importanti" per desktop, servizi 
windows, "enormi" applicazioni web, media center, lettori di testi, non 
credo che con VO avrei mai potuto farle, e se anche ci fossi riuscito 
quanto mi sarebbe costato?
 
Danilo

Buon giorno Aurora,
 
Personalmente ritengo VO pur sempre un linguaggio molto valido, e anche
i miei applicativi sono per la maggior parte in VO, e passo la maggior
parte del mio tempo di programmazione usando VO.
 
Purtroppo con VO ci sono parecchi problemi:
- l'azienda che lo ha mantenuto e venduto negli anni passati ha chiuso
le porte, e perciò i diritti sono ritornati alla CA che non sa neanche
di averli. Per questo un futuro aggiornamento è impossibile per motivi
di copyright
- VO è un compilatore che usa le API di Windows direttamente, e
Microsoft ne ha fermato lo sviluppo già tanti anni fa, puntando su
.NET e concentrandosi su quello. In effetti, guardando in giro, quasi
tutte le librerie di terze parti per lo sviluppo software in ambito
Windows sono disponibili solo per .NET.
 
VO in questo senso si condivide le sorti con Visual Basic (codice di VB
non è compatibile con 
VB.NET
, perciò un aggiornamento non è
possibile), Visual FoxPro (terminato anche lo sviluppo), e altri
linguaggi per Win32.
 
Per quanto riguarda la documentazione in VO: sembra che il mercato più
grosso di VO sia stato quello tedesco, e ho dei libri eccellenti in
tedesco, che mi pare non siano neanche stati tradotti in inglese.
L'unico dovrebbe essere questo:
https://www.amazon.de/Ca-Visual-Objects-Programming-Ivo-Wessel/dp/156990
 
3514
 
Purtroppo il mercato sembra abbastanza piccolo, e anche per X# la cosa
si sembra ripetere.
Devo ammettere che non sono riuscito a trovare un libro valido su
WPF/MVVM (senza collegamento con X#!), magari è proprio perchè non
esiste un mercato abbastanza grande per coprire le spese e fare un
guadagno.
 
Per quanto riguarda X#, ho iniziato a lavorare su un wiki (in inglese),
che si trova qui: 
http://docs.xsharp.it
 perchè mi sembra la forma
ideale per i tempi odierni.
 
Per quanto riguarda la fiducia in X#: a differenza di VO X# è
effetivamente open source, e attualmente riscuote un interesse non
indifferente tra gli utenti di Visual FoxPro. Tutto questo lo dovrebbe
rendere più sicuro e longevo.
 
Per me la scelta di X# è quasi obbligata perchè è l'unica strada per
portare avanti tutto il mio codice in VO (oltre della mia preferenza
personale del linguaggio XBase).
 
Sinceramente penso che anche per Lei X# sarebbe l'unica soluzione
fattibile senza riscrivere e riconcepire tutti i suoi applicativi in
VO. Inoltre l'ambiente .NET e la stretta parentela con C# permette
l'integrazione tra parti in C# e X# (cosa che anche io stesso ho fatto
varie volte).
 
Saluti
 
Wolfgang
 
-- 
 


Buon giorno,
ringrazio tutti coloro che discutono, e ringrazio in maniera particolare Alessandro col quale mi scuso. Non avevo nessuna intenzione di offenderlo, e se è stato fatto me ne dispiace e chiedo venia.
Ho la tendenza ad accalorarmi, anche quando scrivo, e questo è per me un argomento importante.
Chiedo ad Alessandro di dare il suo contributo ad una discussione in cui ognuno ha il diritto di esprimere la propria opinione.
So perfettamente che non intendeva denigrare il mio lavoro. Ci Mancherebbe.
Per quanto riguarda il resto credo che il signor Riedman abbia centrato il problema. Ma credo altrettanto fermamente che sta a voi che conoscete bene VO togliere di mezzo tutte quelle ragnatele che ne bloccano lo sviluppo.
Io invio mail direttamente da vo con allegati.
Io lavoro con le tavolette grafometriche della Wacom con VO.
Io lavoro con i web service della sogei con vo.
Tutto questo con delle dll che si interfacciano con vo e tramite shellexecute adempiano a quanto richiesto.
E in materia di vo sono certamente un pivellina poichè ho iniziato circa tre anni fa e non ho la mia idea di come lavora. Inoltre so che vi sono decina di funzioni che non ho mai utilizzato perchè non ho la minima idea di come utilizzarle.
In questo io, e sono sicura tanti altri che prima accedevano a questo simposio, sono pronta a scommettere ed investire.
Non me ne voglia Alessandro, ma vo non muore.
Per quanto riguarda la documentazione, è bello avere un libro da sfogliare quando ne hai bisogno. 
Anche se lavoro con i pc, i server,i nas, i router e le allegate diavolerie, resto fedele al buon vecchio libro da sfogliare quando ti serve. 
Ripeto, perchè qualcuno che conosce bene l'inglese non si premura di tradurre l'help di vo ? Io ne ho tradotto solo le parti che mi interessano. E continuo a farlo quando la cosa mi serve. Ma si tratta di traduzione fatte on line e poi adattate. 
Aurora Baccio

 
Scusate il mio intervento da completo esterno a questo newsgroup, a cui 
mi sono iscritto solo perché sono un utente Harbour (proveniente da 
Clipper e ancor prima dBase III+)
 
Io penso che si stia facendo confusione fra "compilatore" e "linguaggio".
 
Esistono i linguaggi che sono una cosa, ad esempio c, c++, cobol, xbase 
e esistono i relativi compilatori.
Per i linguaggi c e c++ ne potrei elencare almeno 6 diversi attualmente 
usabili. E ne potrei elencare almeno uno, da me posseduto diversi anni 
fa, che non è più in commercio.
 
Stesso discorso per il linguaggio xbase: a fronte dell'originale 
interprete dBase III+ è stato sviluppato prima il compilatore Clipper, 
poi degli spin-off come VO, Visual dBase, Alaska xBase++, flagship... 
per arrivare agli opensource Harbour e xHarbour... e in ultimi Vulcan e X#
 
Perché queste evoluzioni? Perché nuovi compilatori... in effetti con VO 
è possibile fare tante cose e Aurora ce lo dimostra chiaramente!
 
Sostanzialmente perché i sistemi operativi aggiungono nuove 
funzionalità, nuovi sistemi operativi sono ora disponibili (quelli sui 
mobile, ad esempio), nuovi paradigmi di interazione sono stati 
introdotti (touch, voice), nuovi protocolli sviluppati... per non 
parlare delle infinità di nuove tecnologie (ad esempio i database noSql, 
a grafi, ad oggetti, a chiave-valore oppure l'intelligenza artificiale...)
E volendo usare queste nuove funzionalità occorre avere delle librerie 
che si possano interfacciare.
 
E quindi arrivo al punto: nel 2019 posso essere sicuro al 100% che 
esiste almeno una libreria open-source .Net che mi permetta di usare 
queste tecnologie, così come sono sicuro che esista per il linguaggio 
python o per go.
Posso essere sicuro che questa libreria esista per VO? O che se esiste 
oggi continui ad essere disponibile e aggiornata nei prossimi mesi?
shellexecute è una possibile soluzione. Lo uso anche io per scambiare le 
fatture elettroniche con aruba... ma non ne vado fiero ed è stato solo 
un ripiego.
 
Concludo: per evitare di accumulare troppo "technical debt" penso sia 
necessario uscire dalla propria zona di confort e verificare le 
possibili alternative. Da quello che capisco leggendo il thread ci sono 
già sviluppatori italiani che hanno usato X# per il porting di 
applicazioni VO e penso che se l'hanno fatto è perché pensano di trarne 
beneficio, fosse solo la possibilità di accedere all'immenso archivio di 
librerie .Net disponibile.
 
Io ci rifletterei per bene...
 

 Abbiamo avuto il medesimo problema, se le può interessare abbiamo scritto, impiegando moltissime risorse, in collaborazione con altri un RDD per DBF 2 MySQL.
 
Questa RDD è per X# immagino....

 perciò un linguaggio totalmente differente.
 
Immagino il riferimento sia a copperspice, che si basa su un fork di un 
vecchio qt... Il linguaggio di programmazione in effetti è c++
 

 oggi continui ad essere disponibile e aggiornata nei prossimi mesi?
 
Il problema di questi ambienti, vale per VO come per tutti gli altri, e' 
che ad un certo punto "muoiono" e non sono piu' supportati.
 
Che muoiano non sarebbe un problema, se posso continuare ad utilizzarlo 
cosi' come'e', tanto e' sempre possibile integrare nuove funzionalita' 
usando altri linguaggi.
 
Il problema e' che diventano incompatibili con i nuovi sistemi e questo 
ti costringe ad abbandonarli e passare ad altro.
 
Io sviluppavo in Clipper e gia' c'erano problemi con Win7, ho continuato 
integrandolo con parti in C# usando VFPOleDb, poi sono passato a 
XBase++, ed infine solo C#, con la conseguenza che ormai non ho 
preferenze per il formato dei dati, in pratica il formato dbase non lo 
uso piu'.

 di vo ? 
 
anche questo è un problema di copyright: nessuno di noi lo detiene e
ha il diritto di diffondere copie, sia pure in un altra lingua.
Usare una traduzione internamente si può, ma non si può distribuire
neanche parzialmente.
 
Saluti
 
Wolfgang
 
 
-- 
 

 Questa RDD è per X# immagino....
 
no, scritto in puro VO.
 
Saluti
 
Wolfgang
 
 
-- 
 

 aggiornata nei prossimi mesi?  
 
a questo scopo uso parecchie librerie scritte in X# che usano o il
framework stesso oppure librerie .NET di terze parti. I miei
applicativi VO poi usano queste librerie tramite COM - e una di queste
è proprio l'interfacciamento con il portale SoftwareHubSystem per la
fattura elettronica.
 
Poi ce ne sono altri per interfacciarsi a SQLite, PostgreSQL e SQL
Server senza usare ODBC, oppure per leggere e scrivere i file XLSX
senza Excel installato, oppure usano le classi .NET per spedire mail
con SSL.
 
Saluti
 
Wolfgang
 
-- 
 


Immagino che non sia usabile direttamente in Harbour... è comunque 
interessante. Per caso è open-source?

Buonasera,
 
l'RDD è scritto in VO2.8 ed è stato messo a punto in diverso tempo al fine di poter veramente sostituire i DBF facendo minimi interventi sul codice.
Il progetto è nato in quanto avevamo un gestionale molto utilizzato che ci ha dato molte soddisfazioni, ma funzionante con i DBF. I DBF secondo le nostre esigenze ci stavano veramente stretti. O trovavamo una soluzione oppure avremmo dovuto riscrivere tutto.
 
Abbiamo tentato diverse strade per cambiare il database compreso provare un RDD che utilizza ADO. Il problema che abbiamo subito riscontrato sono le prestazioni su grosse mole di dati. Abbiamo clienti che utilizzano tabelle nell'ordine dei 5/10 milioni di record.
Dopo varie messe a punto e cambi di "logica" siamo riusciti ad ottenere un RDD per MySQL veramente performante. Certo in alcuni casi abbiamo dovuto mettere mano al codice, ma considera che abbiamo intere gestioni che non abbiamo nemmeno toccato.
 
L'RDD è comunque limitato, per esempio non permette la SetFilter, volendo sarebbe possibile implementarla ma a noi non serviva.
Altra cosa che non abbiamo sistemato sono gli indici discendenti o indici con formule strane. Naturalmente funziona per indici composti ma non se si utilizzano funzioni particolari.
 
Abbiamo anche dovuto fare un piccolo intervento su Report Pro.
 
Il progetto non è Open Source e non so se è adattabile ad Harbour, non lo conosco.
E' nostra intenzione, salvo ritardi, entro fine anno passerà ad X#, e pian piano passare tutto il nostro codice e tutti i progetti che abbiamo in VO.
Il nostro intento è andare verso un unico linguaggio di programmazione.
 
Alessandro


Grazie Alessandro per la risposta.
 

Buona sera,
io sono riuscita senza grosse difficoltà a trasferire l'archivio pazienti (circa 47.000 record) in mysql, e senza problemi ho trasferito l'archivio dati cartelle cliniche (circa 350.000 record).
Nessun problema nell'utilizzo dei due archivi tramite codice.
Il problema mi è nato nel momento in cui debbo visualizzare i dati del singolo paziente nell'applicativo vo.
L'unica soluzione trovata è stata quella di un dbf provvisorio.
Per quanto concerne l'elenco pazienti non sono riuscita a visualizzarli in data datadialog.
A questo punto ho messo tutto da parte e continuo con i dbf.
Non ho milioni di dati, ma anche io penso che i dbf siano ormai datati.
Ma non so come risolvere la semplice visualizzazione dell'elenco pazienti.
Ho visionato alcune applicazioni redatte da Enio Donci ( che ho ereditato con la documentazione) e mi è sembrato di capire che che i miei problemi sono anche i suoi. 
E qui reitero il mio problema : non esiste documentazione.
Sicuramente X# non ha queste problematiche ma resta la mia domanda : la documentazione cartacea esiste ?
Io sono pronta ad investire ( economicamente e il mio tempo) ma debbo anche tenere conto del fatto che i miei clienti non possono fermarsi perchè io non ho il modo di risolvere il più stupido dei problemi per mancanza di documentazione. E tutti voi sapete che i problemi sorgono sempre in fase operativa.
Grazie
Aurora Baccio

Buongiorno Aurora,
 
secondo me la scelta del Database va fatta anche in funzione della 
operatività che poi si andrà a fare.
Noi produciamo software che finiscono in una azienda con un server e con 
diverse postazioni.
Sono programmi di Logistica, trasporto, ERP e quant'altro. Facciamo tante 
cose.
 
In questo caso SQL ormai secondo il nostro parere è d'obbligo.
 
Nel suo caso però se il prodotto va installato su un singolo PC o al massimo 
3/4 postazioni non so se valga la pena passare ad un DB client/server.
Forse tutto sommato io resterei sui DBF che comunque su un singolo PC (in 
localhost) sono sicuramente più veloci che utilizzare SQL.
Quello che manca al DBF è la gestione fatta bene del BLOB. Con RDD DBFCDX 
non era male mi pareva funzionasse abbastanza bene con pochi limiti.
 
Credo invece che cominci a stare stretto VO. Come diceva Wolfgang si basa 
sulle API di Windows, e resta limitato in questo ambito.
Utilizzare .NET ha enormi vantaggi, pensi per esempio se domani deve fare 
una web app. Utilizza le stesse classi scritte per il suo programma win, 
senza contare che Microsoft ha puntato tutto su .NET e tutto lo sviluppo che 
c'è stato in questi ultimi 10 (o forse più) anni è andato li.
 
Una banalità : se deve accedere ad una cartella ad SFTP al posto di FTP, con 
VO non può farlo salvo utilizzare una dll di terze parti, magari scritta in 
.NET.
Allora che senso ha non passare a .NET ?
 
X# ed il suo team di sviluppo è l'unico che ha fatto un tools (supportato) 
che porta il suo programma scritto da VO in .NET, io non sono a conoscenza 
di utenti Visual Basic o altri linguaggi che lo abbiano fatto.
Naturalmente questo implica dover anche riscrivere qualche pezzo di 
programma ma poi, si apre un mondo.
 
Veniamo alla documentazione. Purtroppo è vero che non si trova molto ma 
consideri che stiamo comunque parlando di .NET.
Tutto il codice scritto in C# per esempio è traducibile in X#. Il CLR è 
quello, tanto che se utilizza un tool per vedere cosa c'è dentro, rivede il 
suo codice scritto in C# (o VB).
Qualsiasi cosa vuole realizzare come minimo trova esempi scritti in C# 
(utilizzabili in X#).
Con X# può anche fare copia incolla di codice C#, compilarlo in una dll e 
poi farla vedere al suo progetto senza nessun limite.
 
Noi comunque sono tanti anni che utilizziamo VO, abbiamo utilizzato Vulcan 
ed ora passeremo ad X#.
C'è da dire che sono tanti anni che siamo iscritti al loro servizio di 
assistenza e frequentiamo quanto più possibile incontri e forum.
 
Buon lavoro.
 
ha scritto nel messaggio 
news:e97f10d8-c90b-4b51...@googlegroups.com...


 Aurora Baccio
 
 
 
--