Newsgroup: it.comp.lang.vo-clipper
Titolo: Conferenza xBase.Future a Colonia

Salve a tutti,
 
sto scrivendo da Colonia dove mi sono recato per la conferenza
xBase.Future 2016.
 
La conferenza quest'anno aveva una novità: data la nascita di un nuovo
compilatore xBase gli organizzatori hanno dato ampio spazio al nuovo
prodotto - e il team di sviluppo attualmente composto da quattro
persone molto note nell'ambito Visual Objects/Vulcan.NET era presente
con tre persone: Robert van der Hulst, olandese e capogruppo, Nikos
Kokkalis, greco e specialista di compilatore, e Fabrice Foray, francese
e esperto di integrazione Visual Studio.
 
Robert nella sua relazione iniziale ha sottolineato che il nuovo
prodotto era un prodotto europeo, e open source, e dovrebbe diventare
un progetto di community, attualmente portato avanti dal loro gruppo.
 
La licenza prevede che il prodotto sarà completamente libero da usare,
sia per scopi commerciali e non, e le sorgenti delle librerie saranno
pubblicate su Github, e accessibili a tutti gli interessati con licenza
Apache 2. Il compilatore al momento sarà disponbile in forma di
sorgente solo agli abbonati.
 
Arriviamo al finanziamento del progetto: per portare avanti lo sviluppo
e coprire le spese, la XSharp BV con sede in Olanda, vende delle
subscription annuali, dal prezzo di Euro 999 (Euro 499 fino al 31
maggio 2016), che non solo danno accesso alle sorgenti del compilatore
stesso, ma anche a un supporto diretto del team di sviluppo non solo
per X#, ma anche per Visual Objects e Vulcan.NET.
 
Robert ha chiesto anche l'aiuto agli interessati, sia in forma di
contribuzione di codice, di portavoce, che anche di finanziamento sotto
forma di sottoscrizione dell'abbonamento FOX (Friends of X# - amici di
X#) ai prezzi sopra citati.
 
A partire da subito, il compilatore X# supporta l'uso delle librerie
Vulcan.NET (chiamato da loro BYOR - bring your own runtime), fino a che
le loro librerie saranno pronte - programmato per ottobre 2016.
 
Personalmente uso X# da qualche mese, e ho in uso presso clienti
qualche programmino realizzato in X#.
 
Questo per intanto le novità più importante - non esitate a chiedermi
se avete bisogno di informazioni.
 
Wolfgang
 
P.S. sto mettendo in funzione anche un piccolo sito 
www.xsharp.it
, e
anche un newsgroup italiano è già disponibile su un mio server.
 
 
-- 
 

Credo che X# sia una novità importante per garantire la sopravvivenza delle 
applicazioni VO e Vulcan.
Ieri ho sottoscritto FOX ed inizierò a giocare col nuovo prodotto, che da 
una prima occhiata mi ha dato un'ottima impressione.
Il fatto che l'ambiente di sviluppo non cambi, XIDE e un VIDE ricompilato, 
non ti costringe ad imparare cose nuove, per il resto non cambia nulla.
 
Attendiamo con impazienza la prima versione stabile.
 
Danilo
 
"Wolfgang Riedmann"  ha scritto nel messaggio 
news:dnqhcm...@mid.individual.net...


Io ho scaricato la 1° public beta e mi sembra che X# prometta bene. sto guardando tutte le evoluzioni del prodotto con grande interesse in quanto vorrei portare sotto .net un mio vecchio programma scritto in CLIPPER.
 
Da quello che sto vedendo direi che sia molto più integrato al sistema Microsoft di quanto non lo fosse Vulcan e questo per merito di Roslyn che praticamente permette di creare nuovi compilatori sfruttando tutte le caratteristiche di .net.
 
Dal momento che userò X# solo per motivi personali penso che non sottoscriverò FOX. Mi piacerebbe in futuro, non appena preso confidenza col mondo .net poter contribuire con del codice di uso generale.
 
Wolfgang, mi sembra molto valida l'idea di creare un newsgroup italiano ed il sito 
xsharp.it
.
 
Fabrizio 

Ragazzi, ho sottoscritto Fox e con la beta 4 direi che siamo ad un passo da 
avere una versione definitiva.
Tenetemi aggiornato delle nuove iniziative.
 
Danilo
 
ha scritto nel messaggio 
news:991e55f7-5d48-4ed6...@googlegroups.com...


 Fabrizio 
 
 
 
-- 
 

 oppure combinare vari PDF in uno unico).
 
Infatti è il sistema che avevamo utilizzato circa 15 anni fa nella mia ditta dove avevamo programmi CLIPPER che utilizzavano funzioni esterne scritte in VO.
 
saluti
 
Fabrizio


 esterne scritte in VO.
 
questo non lo avevo mai sentito! Personalmente avevo parecchi
applicativi che condividevano i database tra Clipper e VO, ma nessun
applicativo DOS che chiamava funzioni VO.
 
Saluti
 
Wolfgang
 
 
-- 
 

 --

 Che differenza c'è tra Winform e le altre usate da VO ?
 
VO usa un framework originalmente scritto da Glockenspiel (società
irlandese) che si basa direttamente sulle API di Win32, e Vulcan usa
nelle VOGUI lo stesso codice trasportato in .NET, senza cambiare
l'interfaccia grafica. Perciò un applicativo Vulcan che usa le VOGUI
ha la stessa estetica e lo stesso funzionamento di un applicativo VO.
 
Saluti
 
Wolfgang
 
 
-- 
 

 copia con licenza sul mio PC )
 
VO e X#/Vulcan riescono anche a collaborare in maniera molto più
stretta: in X# (come peraltro anche in C# e Vulcan.NET) riesci a creare
delle DLL COM che riesci a usare direttamente da VO:
 
oPDFHelper	:= IPDFHelper{}
oPDFHelper:ExtractFromPDFDocument( cInput, cTarget, nDaPag, nAPag )  
 
con la relativa interfaccia in X#
 
[ComVisible(true)];
[Guid("CFBF592B-DCEF-4B61-88F6-B2517C985785")];
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)];
public interface IPDFHelper
 
[DispId(101)];
method ExtractFromPDFDocument( cSourcePDF as string, cSaveAsPDF as
string, nFromPage as int, nToPage as int ) as logic
 
Saluti
 
Wolfgang
 
-- 
 

 ha la stessa estetica e lo stesso funzionamento di un applicativo VO.
 
Altra ragione per vedere da subito le classi .net


 --
 

Scusate se mi intrometto nella discussione DBF Sql.
 
Senza dubbio i DBF in certi contesti erano più veloci di qualche database 
sql ma a mio opinabile giudizio hanno però alcune controindicazioni troppo 
gravi:
 
1 l'accesso ai dati in rete richiede una risorsa condivisa; questo apre a 
problemi di sicurezza certo non piccoli, ed a problemi di configurazione 
fragile.
2 l'accesso remoto come sopra.
3 gli indici sono fragilissimi e se i database sono corposi fermare tutti 
per ricostruire gli indici non è proprio simpatico. In ufficio avevo una 
applicazione delle posta con milioni di record e la ricostruzione degli 
indici richiedeva più di un'ora, periodo nel quale gli operatori erano 
bloccati, con un danno per la operatività della struttura insostenibile.
4 mancando istruzione del tipo update... where costringe a cicli di 
elaborazione noiosissimi
5 mancando possibilità di legare più tabelle per interrogazioni complesse 
costringe anche questo ad elaborazioni noiose e spesso critiche.
 
Non so, per me la possibilità di fare query a volte anche complesse in una 
riga di codice invece di scrivere spesso pagine di codice è impagabile, se 
poi si sceglie il database giusto la velocità non è affatto minore, anzi al 
contrario.
 
Oh, come premesso questa è solo una mia opinione e come tale del tutto 
contestabile.
 
Buon fine settimana.
 
Danilo
 

 Altra ragione per vedere da subito le classi .net
 
si, se hai la possibilità di partire da nuovo... Ma in questo caso la
mia decisione è di tagliare tutte le cose vecchie e usare WPF con MVVM.
 
Saluti
 
Wolfgang
 
-- 
 

Ciao Danilo,
 
sicuramente hai ragione.
 
La sempicità d'uso dei DBF è però imparagonabile sia per il posto
singolo che per la piccola rete di 2-3 PC e volumi di dati bassi (come
la maggior parte delle mie installazioni).
 
Inoltre l'accesso sequenziale da un comfort elevato agli utenti con la
sua ricerca incrementale velocissima.
 
Saluti
 
Wolfgang
 
P.S. ho oltre 15 anni di esperienza con i vari SQL come MySQL, Oracle,
MS SQL, e li uso in vari progetti molto frequentemente - perciò penso
che so di cosa parlo.

-- 
 

 condivisione in rete dei DBF.    
 
Multithreading è la possibilità di usare più processi contemporanei
all'interno di un singolo programma, per esempio l'esecuzione di una
stampa mentre l'utente sta lavorando - e questo senza lanciare un altro
programma. In .NET questo viene usato per aumentare le risposte del
programma, cioè che la GUI rimane attiva mentre per esempio i dati
vengono caricati da una fonte esterna e lenta.
 
Saluti
 
Wolfgang
 
-- 
 

 Danilo
 

 
 
Penso che farò proprio come dici.


Ciao Wolfgang,

ok.
