NUOVO AMBIENTE SCRIPT AREA TECNICA

[joe]

Ciao Luigi, buona serata a tutte/i.

Con le scuse per la ripetizione della mia richiesta, alla quale è già stata sicuramente data risposta.

Come utile ripasso ed il riportare a sintesi ... concetti sparsi e difficili da reperire tra ormai oltre 2000 messaggi.

Premetto che con le precise istruzioni di Lugi, la GRIGLIA c'è.

Funziona in un nuovo progetto completamente vuoto cioè costruito partendo da zero.

Dunque c'è solo il Form che contiene la griglia con il suo scorrimento verticale econ la possibilità di evidenziare gli estratti.

Per poter far funzionare tutte le "istruzioni" (come EstrazioneFin, Estratto, Posizione, ecc ecc)

Quali sono componenti necessari che bisogna aggiungere al progetto?

 

[lotto_tom75]

Sera a tutti ho aggiornato twinbasic all'ultima versione 280 e la dll all'ultima versione 29 ma... rispetto a prima adesso l'errore native line 142 mi si ripresenta molto + spesso e anche con meno carico elaborazionale... (es. prima sopportava 8 numeri e 2 ruote unite a girare... e adesso nemmeno 5 numeri e 2 ruote unite a girare...). Avete notato anche voi peggioramenti... in tal senso con i nuovi aggiornamenti? ps: ho notato la stessa cosa non solo con i miei script e programmini di test (es. robot boss ecc..) ma anche con lo smess e alcuni programmini al suo interno tipo quello di rubino ad es.

 

[LuigiB]

Ciao Luigi, buona serata a tutte/i.

Con le scuse per la ripetizione della mia richiesta, alla quale è già stata sicuramente data risposta.

Come utile ripasso ed il riportare a sintesi ... concetti sparsi e difficili da reperire tra ormai oltre 2000 messaggi.

Premetto che con le precise istruzioni di Lugi, la GRIGLIA c'è.

Funziona in un nuovo progetto completamente vuoto cioè costruito partendo da zero.

Dunque c'è solo il Form che contiene la griglia con il suo scorrimento verticale econ la possibilità di evidenziare gli estratti.

Per poter far funzionare tutte le "istruzioni" (come EstrazioneFin, Estratto, Posizione, ecc ecc)

Quali sono componenti necessari che bisogna aggiungere al progetto?

Partire col progetto totalmente vuoto richiede di inserire tutti i moduli del progetto TestCosnumer e in piu gestire l'inizializzazione della libreria non lo consiglio , la cosa piu semplice è che tu importi il tuo form dentro il progetto dello smess e fai come sta facendo Rubino o Legend , in questo modo il progetot parte e le operazioni di inizializzazione sono gia tutte gestite tu ti puoi dedicare esclusivamente al tuo form.
Quindi esporta il progetto su cui hai lavorato in una cartella , apri lo smess e importa il form che ti serve

crea uan nuovacartelal Joe (non è indispensabile ma è utile per organizzare )



dopo di che segui le semplici istruzioni del pdf per aggiungere un menu a twinbasic e richiamere il tuo form , basta aggiungere solo il menu standard non devi per forza mettere anche quello colorato , ci vuole un secondo ..

fatto questo poi ti potrai concentrare sul tuo form con le tue funzioni.

 

[LuigiB]

Sera a tutti ho aggiornato twinbasic all'ultima versione 280 e la dll all'ultima versione 29 ma... rispetto a prima adesso l'errore native line 142 mi si ripresenta molto + spesso e anche con meno carico elaborazionale... (es. prima sopportava 8 numeri e 2 ruote unite a girare... e adesso nemmeno 5 numeri e 2 ruote unite a girare...). Avete notato anche voi peggioramenti... in tal senso con i nuovi aggiornamenti? ps: ho notato la stessa cosa non solo con i miei script e programmini di test (es. robot boss ecc..) ma anche con lo smess e alcuni programmini al suo interno tipo quello di rubino ad es.

purtroppo il problema è di TwinBasic , io non ho mai provato se lavorando con l'eseguibile lo da lo stesso ..bisognerebbe provare ..il fatot è davvero fastidioso ma non ci possimao fare nulla.

 

[lotto_tom75]

purtroppo il problema è di TwinBasic , io non ho mai provato se lavorando con l'eseguibile lo da lo stesso ..bisognerebbe provare ..il fatot è davvero fastidioso ma non ci possimao fare nulla.

Per vedere se implementato nello smess possa risolvere alcuni problemi di memory... ho provato ad aggiungerlo ad una copia dello smess... Ho letto il relativo PDF di aiuto ma purtroppo non ho chiaro affatto di come si faccia...
Ho aggiunto il menu e poi cliccato sopra e ho aggiunto i due form (frmParametri) del mio programmino in una cartella analoga a quelle tue, di legend e di rubino ma quando cerco di creare l'istanza di collegamento tra la nuova mia voce di menu robotbossv167 e il relativo script principale di avvio MyScript mi da l'errore sotto riportato. Qualche lume in + sarebbe provvidenziale per provare a concludere questo test d'implementazione smess . Grz

 

[LuigiB]

tu non hai un form ma uno script , quindi d è piu facile ... devi vedere come funzionano i due modulidegli script di test è facilissimo e poi sostituire in uno dei due il codice del tuo modulo.

nella funzione col riquadro rosso incolla il tuo codice , sopo di che potrai lanciare lo script dal primo script di test

 

[lotto_tom75]

tu non hai un form ma uno script , quindi d è piu facile ... devi vedere come funzionano i due modulidegli script di test è facilissimo e poi sostituire in uno dei due il codice del tuo modulo.

nella funzione col riquadro rosso incolla il tuo codice , sopo di che potrai lanciare lo script dal primo script di test

Vedi l'allegato 2256052

No luigi ho un mio form frmParametri modificato che ti ho mostrato nelle precedenti immagini (pag 123) e che devo importare e collegare in qualche modo... nello smess e che qui sotto comunque ti riporto...




aggiornamento... sono riuscito a caricare i form lo script primario e a rimuovere gli errori che non consentivano nemmeno l'apertura dello smess solo che adesso se clicco sul relativo menu robotbossv167 non mi apre il mio form parametri modificato nè null'altro... riguardante quello. Tutto il resto rifunziona regolarmente...



se clicco sulle voci cerchiate relative a robotboss non da + errore... ma non si apre nemmeno... nulla

 

[LuigiB]

il tuo form parte da uno script ...

 

[lotto_tom75]

il tuo form parte da uno script ...

 

[Rookie]

Buongiorno a tutti! Leggendo e riflettendo sulla oramai grande (e viepi’ dinamicamente montante) mole di messaggi afferenti alla rappresentazione dei dati ottenuti piuttosto che alla raccolta degli stessi dati, suggerisco di separare ció che é riferito all’aspetto grafico del progetto SMESS da ció che invece dipende dall’API per ottenere i dati necessari e che concretizza il progetto stesso.

Per un semplice motivo, se abbiamo i dati, possiamo confezionarli e impacchettarli ad libitum, ma se i dati non possono essere raccolti in maniera precisa e veloce, anche il miglior programma per rappresentare le inferenze serve a nulla.

Stabilito che sono i dati il core su cui tutto si basa, sarebbe bene capire quando le varie funzioni giá scritte saranno (forse lo sono già) sufficienti per la stragrande maggioranza dei casi.

Una volta che questo stato dell’arte é acclarato e oggettivato allora si potrà pensare al make-up, cioè al completamento dell’eleganza nel rappresentare al meglio ciò che i dati raccolti possono o devono raccontare all’utilizzatore.

A mio avviso, Se non si procede a questa separazione i tempi per raggiungere una sufficiente maturitá del progetto, finiranno per crescere esponenzialmente estenuando le persone interessate a vario titolo.

Ovviamente, quanto ho appena scritto é il mio personale pensiero rispetto al tema sempre piú ricorrente…

 

[Rookie]

Vedi l'allegato 2256076

Vedi l'allegato 2256075

Caro Tom, sono felice che tu abbia raggiunto un buon livello di padronanza tecnica, ma anche per il fatto che quanto intercorso tra me, te e @i legend, ante litteram, ovvero l’idea primordiale che ha portato alle varie richieste fatte a @LuigiB per poter accedere alle sue librerie dedicate a SPAZIOMETRIA, senza reinventare l’acqua calda, e quindi grazie al coinvolgimento determinante di Luigi, rimasto folgorato dall’ambiente twinBasic, data la sua immediata fruibilitá e semplicitá (e non necessita di installazione), e anche per andare oltre l’ancora ottimo suo Package Lotto, che ha reso tutto questo possibile.

L’unica macchia o pecca in tutto questo e’ ció che Luigi non si augurava di constatare, ovvero di rimanere solo nello sviluppo, ma non era semplice convertire quanto aveva già fatto per renderlo fruibile esclusivamente dallo SMESS, sopratutto per il linguaggio con cui queste funzioni sono state implementate.

Ma ogni beneficio ha il suo costo relativo. Forse Luigi ha spianato la strada per costruire qualcosa che va oltre, oltre un programma stand alone su un pc locale, per esempio rendendo la sua API fruibile attraverso il web e quindi richiamabile da qualsiasi linguaggio e sistema operativo.

Qualcosa di universalmente fruibile. Solo Rispettando la convenzione delle chiamate alle sue funzioni… il che renderebbe possibile fare mega ricerche, velocissime, anche da un semplice tablet connesso a internet, visto che tutto girerebbe comodamente su un server, senza distribuire DLL, archivi, etc…
Perché questo é nelle cose, ed é sopratutto il futuro dove tutto girerá dentro le nuvole e i servers che costituiscono giá la Cloud Era. Il futuro non sono i pc, ma vivere connessi attraverso i dispositivi creati per questo scopo…
Ma queste sono cose che Luigi può valutare autonomamente.

 

[joe]

Buongiorno a tutti! Leggendo e riflettendo sulla oramai grande (e viepiú’ dinamicamente montante) mole di messaggi afferenti alla rappresentazione dei dati ottenuti piuttosto che alla raccolta degli stessi dati, suggerisco di separare ció che é riferito all’aspetto grafico del progetto SMESS da ció che invece dipende dall’API per ottenere i dati necessari e che concretizza il progetto stesso.

Per un semplice motivo, se abbiamo i dati, possiamo confezionarli e impacchettarli ad libitum, ma se i dati non possono essere raccolti in maniera precisa e veloce, anche il miglior programma per rappresentare le inferenze serve a nulla.

Stabilito che sono i dati il core su cui tutto si basa, sarebbe bene capire quando le varie funzioni giá scritte saranno (forse lo sono già) sufficienti per la stragrande maggioranza dei casi.

Una volta che questo stato dell’arte é acclarato e oggettivato allora si potrà pensare al make-up, cioè al completamento dell’eleganza nel rappresentare al meglio ciò che i dati raccolti possono o devono raccontare all’utilizzatore.

A mio avviso, Se non si procede a questa separazione i tempi per raggiungere una sufficiente maturitá del progetto, finiranno per crescere esponenzialmente estenuando le persone interessate a vario titolo.

Ovviamente, quanto ho appena scritto é il mio personale pensiero rispetto al tema sempre piú ricorrente…

Sono piuttosto in accordo con quanto scritto.

I dati sono "la ciccia" poi come li si cucina ... può essere abbastanza relativo.

Questo richiama appieno a quanto avevo scritto a Tom.

L' interfaccia grafica è importante se poi il risultato del suo contenuto è importante.

Per esempio lo script che avevo preparato per alimentare la griglia ...

supera ampiamente il risultato che la griglia può contenere.

E questo la trasforma in una inutile complicazione e limitazione all'esposizione dei risultati.

Ma ... a me interessa saperla far funzionare se non per questo ... per altro.

 

[LuigiB]

Buongiorno a tutti! Leggendo e riflettendo sulla oramai grande (e viepiú’ dinamicamente montante) mole di messaggi afferenti alla rappresentazione dei dati ottenuti piuttosto che alla raccolta degli stessi dati, suggerisco di separare ció che é riferito all’aspetto grafico del progetto SMESS da ció che invece dipende dall’API per ottenere i dati necessari e che concretizza il progetto stesso.

Per un semplice motivo, se abbiamo i dati, possiamo confezionarli e impacchettarli ad libitum, ma se i dati non possono essere raccolti in maniera precisa e veloce, anche il miglior programma per rappresentare le inferenze serve a nulla.

Stabilito che sono i dati il core su cui tutto si basa, sarebbe bene capire quando le varie funzioni giá scritte saranno (forse lo sono già) sufficienti per la stragrande maggioranza dei casi.

Una volta che questo stato dell’arte é acclarato e oggettivato allora si potrà pensare al make-up, cioè al completamento dell’eleganza nel rappresentare al meglio ciò che i dati raccolti possono o devono raccontare all’utilizzatore.

A mio avviso, Se non si procede a questa separazione i tempi per raggiungere una sufficiente maturitá del progetto, finiranno per crescere esponenzialmente estenuando le persone interessate a vario titolo.

Ovviamente, quanto ho appena scritto é il mio personale pensiero rispetto al tema sempre piú ricorrente…

le valurto e sono felice di dirti che non me ne importa un fico secco finche esistera windows questo programam girerà tranquillmente insieme a twinbasic che è fatto per windows ..vecchi e cari programmi desktop .. never die ...
quell oche mi fa incazzare di twinbasic sono i suoi problemi di memoria . .dovevamo impostare la cosa in dotnet .. che alla fine è solo un po' piu difficile da instalalre e da apprendere ma manco troppo ... la libreria in dotnet si puo usare senza problemi è che bisogna riscrivere tutto il contorno .. e sinceramente non mi va..



per rspondere a Joe , la griglia puo contentere tutto perche in realta contiene solo le 30 50 righe visibili a video , sei tu che ne devi gestire la visulaizzazione a partire dai tuoi dati...

 

[LuigiB]

riguardo la verifica che giustamente va fatta la dll esegue solo dei compiti e restituisce dei risultati l'aspetto grafico è gia separato dalle funzioni , è chiaro che per testarle un 'interfaccia va fatta cioe bsogna fare il proprio form con la propria funzione e vedere se i dati restituiti sono coerenti , oppure anche senza form bisogna provare le stesse funzioni dal classico script...

 

[Rookie]

le valurto e sono felice di dirti che non me ne importa un fico secco finche esistera windows questo programam girerà tranquillmente insieme a twinbasic che è fatto per windows ..vecchi e cari programmi desktop .. never die ...
quell oche mi fa incazzare di twinbasic sono i suoi problemi di memoria . .dovevamo impostare la cosa in dotnet .. che alla fine è solo un po' piu difficile da instalalre e da apprendere ma manco troppo ... la libreria in dotnet si puo usare senza problemi è che bisogna riscrivere tutto il contorno .. e sinceramente non mi va..



per rspondere a Joe , la griglia puo contentere tutto perche in realta contiene solo le 30 50 righe visibili a video , sei tu che ne devi gestire la visulaizzazione a partire dai tuoi dati...

Per quanto riferisci rispetto a .NET penso che nulla osta ad utilizzarlo… sopratutto per coloro che si trovano nella loro area di confort con questo framework. In attesa che tB implementi una efficace gestione delle risorse, un problema che si ravvisa se si dispone di non ingenti quantità di GB di RAM installata. Sul mio pc Windows cavia ho sostituito i due moduli da 8 GB con due da 16 e sembra che il problema si attenui di molto. Certo non è una soluzione ma conferma la buona architettura dell’IDE di tB.

 

[Rookie]

riguardo la verifica che giustamente va fatta la dll esegue solo dei compiti e restituisce dei risultati l'aspetto grafico è gia separato dalle funzioni , è chiaro che per testarle un 'interfaccia va fatta cioe bsogna fare il proprio form con la propria funzione e vedere se i dati restituiti sono coerenti , oppure anche senza form bisogna provare le stesse funzioni dal classico script...

Io mi riferivo a quanti utilizzano la tua DLL che s’impelagano nel make up grafico. Tu lo hai saggiamente già separato per lasciare la scelta sul come presentare i risultati. Volevo focalizzare solo l’importanza dei dati corretti e veloci nell’ottenerli rispetto alla loro visualizzazione! Forse non sono stato chiaro ma era questo il senso delle mie parole!

 

[happy]

quell oche mi fa incazzare di twinbasic sono i suoi problemi di memoria . .dovevamo impostare la cosa in dotnet .. che alla fine è solo un po' piu difficile da instalalre e da apprendere ma manco troppo ... la libreria in dotnet si puo usare senza problemi è che bisogna riscrivere tutto il contorno .. e sinceramente non mi va..

Perfettamente in sintonia con quanto espresso da Luigi.

Luigi ha già implementato più di quello che era necessario ( la rottura di .... è twinBasic! ), per quanto mi riguarda penso che Luigi abbia fornito agli interessati la canna da pesca ora ognuno può decidere se pescare o meno, per me adesso si tratta solo di studiare e approfondire la conoscenza del vb6.
E' già è una grande cosa che la libreria sia utilizzabile anche in .NET, così non resterà confinata nel recinto del vb6.

Grazie Luigi, nel mio piccolo hai aperto una nuova finestra di possibilità ludiche.

Buona continuazione a tutti

"C'è chi dice e non fa
C'è chi fa e non dice"



p.s.
il controllo dei dati risultanti dalle elaborazioni avverrà automaticamente con il passare del tempo e dall'uso più o meno intenso che ne faranno gli utilizzatori .

 

[Rookie]

Perfettamente in sintonia con quanto espresso da Luigi.

Luigi già implementato di più quello che era necessario ( la rottura di .... è twinBasic! ), per quanto mi riguarda penso che Luigi abbia fornito agli interessati la canna da pesca, ognuno può decidere se pescare o meno
Personalmente penso che adesso si tratta solo di studiare e approfondire la conoscenza del vb6.
Poi già è una grande cosa che la libreria sia utilizzabile anche in .NET, in quando non resterà confinata nel recinto del vb6.

Grazie Luigi, nel mio piccolo hai aperto una nuova finestra di possibilità ludiche.

Buona continuazione a tutti

"C'è chi dice e non fa
C'è chi fa e non dice"

Però ci sono anche coloro che non fanno e non dicono come pure coloro che fanno e dicono senza che tu abbia ricordato di annoverarli…

 

[LuigiB]

comunque tramite la funzione Statistca Combinazioni che ho implementato io nello smess si puo verificare se i dati statistici combacino , io ho usato la funzione StatisticaSingoloEsito

 

[happy]

Però ci sono anche coloro che non fanno e non dicono come pure coloro che fanno e dicono senza che tu abbia ricordato di annoverarli…

___