SOFTWARE MODULARE

Buongiorno a tutti.
Per chi appena tornato dalle vacanze auguro di riprendere dolcemente senza troppe rotture.
Per chi invece in vacanza ancora non ci andato auguro una buona continuazione.

Allora oggi sono qui per chiedere se esiste un sistema per rendere un. software creato con XOJO modulare.
Ad esempio il mio sw costruito su diversi moduli, base, contabilita, vendite, magazzino etc. Domani mattina mi sveglio e sviluppo logistica…
Per non a tutti i clienti il modulo logistica serve. Come posso fare ( senza creare due software distinti ) ad integrare un sw esterno solo se il cliente lo desidera ? che tecniche posso adottare ?

In Clipper 5.2 utilizzavo dei moduli OVL ( overlay ) se il file ovl della logistica era presente il modulo base lo rilevava e attivava tutte quelle voci di men che richiamavano le varie procedure. Alcune schede, tipo la scheda cliente, etc mostravano delle funzionalit aggiuntive se appunto il relativo ovl era presente.

Attendo vostre . Grazie…

Ci sono diversi modi di farlo.
Ad esempio potresti utilizzare XojoScript per implementare metodi personalizzati (lo uso per un paio di sw dove ogni cliente ha diversi modi di elaborare alcune cose per cui ha i suoi script personalizzati)

Ma nel tuo caso il metodo più semplice (tenendo conto che hai una struttura complessa fatta di finestre specifiche e altre componenti) è quello di avere un metodo che verifica all’avvio se la funzionalità è attiva e uno che utilizza la stessa funzionalità per aggiungere/levare (dipende da come vuoi lavorare) le relative voci di menu.
Il primo metodo (che usi anche nel secondo) serve a abilitare/disabilitare eventuali pulsanti nell’interfaccia o come “tappo” ad eventuali chiamate.
Il secondo metodo serve a creare i menu nel modo corretto.
Ogni volta che rilasci un nuovo modulo aggiorni il software e attivi i moduli in base a quello che preferisci tra chiamate ad un server, chiave di attivazione, mix tra chiave e server o quello che ti viene in mente.

Ah, i bei tempi del Clipper!!!

Non so sul Mac, ma in ambiente Windows direi che si pu procedere in due modi:

a) ogni modulo un progetto a s stante, che produce il suo eseguibile. C’ poi il progetto principale che pilota le chiamate ai vari moduli che sono abilitati. Al cliente installerai solo gli eseguibili relativi ai moduli abilitati (la presenza dell’eseguibile gi ti pu dire cosa abilitato e cosa non lo ).

b) hai un unico progetto che ti genera un eseguibile che prevede tutto, salvo poi avere da qualche parte un “qualcosa” che ti dice quali moduli sono abilitati, e quindi abiliti solo le voci e i men relativi ai moduli validi, e qui devi fare attenzione a mettere in piedi un sistema che sia sicuro e non crackabile da parte dell’utente.

Ad occhio e croce direi che il primo sistema pi complicato nella gestione delle finestre che si devono integrare con la main window; il secondo pi semplice da sviluppare, ma soggetto a crack, se non trovi una soluzione pi che sicura.

Anch’io ho una situazione simile, un software con diversi moduli e venduto a pacchetti.

Proprio per non dover scrivere software distinti ho fatto cosi:

  1. Ho realizzato il software completo, con tutti moduli e tutte le funzionalit.
  2. In base alle licenze attive dell’utente nascondo o visualizzo le funzionalit e i moduli.
  3. Con lo stesso metodo gestisco anche la versione Freeware (limitata) scaricabile dal sito.

Avendo una versione scaricabile dal sito, ed essendo lo stesso software della versione Full, ho questi vantaggi:

  1. L’utente scarica e prova la versione Freeware.
  2. Se gli piace acquista la licenza direttamente sul sito, con i moduli che gli servono.
  3. Il sito invia la licenza al cliente con i codici che sbloccano le funzionalit acquistate.
  4. Siccome la versione Freeware scaricata lo stesso software della versione Full, non devo obbligarle il cliente a installare altri moduli. Ha gi tutto pronto sul proprio computer, e deve solo inserire i codici che ho inviato.
  5. Per gli aggiornamenti l’utente non deve fare altro che scaricare la nuova versione e installarla sopra quella corrente.

In genere per ogni modulo acquistato genero un codice licenza diverso. Ogni codice licenza legato all’intestazione del cliente, all’indirizzo, citt, e al modulo acquistato. All’interno del software uso una maschera per inserire l’intestazione del cliente e tutti i codici licenza. All’avvio verifico e attivo i vari moduli acquistati.

Poi ogni situazione differente. Io ho scelto di gestirla in questo modo per comodit, tutto automatizzato, non devo fare nulla durante l’acquisto, anche le licenze vengono inviate automaticamente dal sito. Circa l’80% delle volte gli utenti scaricano e acquistano senza nemmeno chiedere informazioni. Questo mi da la possibilit di dedicarmi quasi unicamente allo sviluppo di nuove funzionalit o nuovi software, e quasi per nulla alla gestione degli ordini.

Considera che il mio software “piccolo”, scaricabile da un sito, facilmente utilizzabile. Non so quanto questa soluzione possa essere valida per un gestionale tipo il tuo. Spero comunque di averti dato qualche idea in pi.

Allora, adesso il gestionale 80 mbyte; per compilarlo ci metto circa 6-7 minuti;
se ci aggiungo logistica, distinta base, produzione, gestione dipendenti etc arrivo sicuro sicuro a 160 mbyte;

Al momento mi sono creato una replica del gestionale con form che inserisco solo se utilizzate nella parte che st sviluppando. Appunto, ad esempio st sviluppando la parte della logistica ho incluso solo le form clienti/fornitori, depositi, vettori, tabelle di magazzino etc.
Poi le unir nel gestionale e… in quel momento vedr la dimensione lievitare come la pasta per la pizza…

Mi sarebbe piaciuto tanto avere moduli esterni per non compilare appunto il gestionale di dimensioni cos tali da far piangere me, il mac e la mia pazienza.

La soluzione di attivare i moduli o disattivarli in base alla licenza era gi stata presa in considerazione.

Nedi, richiami semple la classe per la protezione se per quello…
Ma non vorrei, visto che un gestionale ERP e purtroppo solo per dirtene una, quando emetti un ddt apri davvero un bel p di procedure … solo per dirtene una, il controllo del fido, e quindi i movimenti contabili, i documenti in un altro recordset perch devi conteggiare gli importi della merce gi consegnata, lo scadenziario perch ci sono scadenze non ancora maturate, il magazzino, i listini prezzi, i listini prezzi dei clienti, le provvigioni e le relative tabelle, gli eventuali premi di fine anno, le promozioni e porcamucca santa …

Se alcune di queste tabelle fossero gestite su un’app a se, vuol dire che tutte le volte che devo mettere mano ad una di queste form, che ne so, per cercare un valore piuttosto che un’altro … ciao mamma il pc impazzisce.

Fortunatamente, ho una classe di oggetti che ho chiamato listbox che richiama l’elenco della tabella con campi definiti su una tabella che ho chiamato pragma. quindi apro la form, leggo pragma, creo la listbox, etc. per quando capita di dover inserire dati al volo ( per esempio una nuova destinazione merci per il cliente, un nuovo cantiere, una nuova targa di automezzo etc… ) allora li, devo per forza aprire la form giusta della tabella giusta.

In xojo diversamente che da visual basic non posso richiamare una finestra ( form ) con il nome contenuto in una variabile, devo per forza inserire tutte le form con i relativi nomi in un ciclo select case, e quindi se la form non nella app con il piffero che il compilatore digerisca il tutto lo stesso.

Comunque, va be… per il resto tutto bene… prender l’esempio di Antonio, l’app avr tutto ma il cliente vedr solo quello per cui abilitato. Per l’abilitazione sar un webcs a controllare il tutto con delle chiavi di attivazione ottenute con il numero di serie della macchina ( poi vediamo come fare per la multiutenza ).

Devo anche tenere presente che ho implementato un sistema di protezione su ogni form che permette all’utente o non permette di inserire, modificare, visualizzare, eliminare i dati.