Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[MsAccess] GANTT (GDI+)
165 views
Skip to first unread message
@Alex
Jan 2, 2020, 6:05:30 AM1/2/20
to
Ho preso spunto da una pubblicazione in un sito interessante Francese che pubblica un lavoro che ritengo di altissimo livello, ovvero una Classe Wrapper verso GDI+.
Questo il sito di Thierry Gasperment:
https://arkham46.developpez.com/articles/office/clgdiplus/
Questa Classe ingloba tutta una serie di strumenti grafici sfruttando la possibilità di lavorare in Memoria con la Grafica quindi consente di avere velocità di esecuzione notevoli, per poi depositare nel controllo Immagine di Access il ByteArray corrispondente all'immagine precedentemente elaborata.
Sfruttando questo sistema quindi è possibile disegnare quasi qualsiasi controllo anche molto elaborato.
In questo caso ho provato a realizzare un GANTT GERARCHICO, ovvero una rappresentazione temporale di attività che possono avere anche una struttura ad Albero gerarchica assimilabile al TreeView.
Personalmente utilizzo per lavoro MsProject, quindi mi sono ispirato alla grafica offerta da questo prodotto.
Tutto viene DISEGNATO RUNTIME, poi viene gestita l'interazione con l'oggetto sfruttando la struttura di Classi e Collection che memorizzano le informazioni necessarie.
Nell'allegato trovare un tutorial minimal in un inglese abbastanza frettoloso...
Il Demo che si trova al Link sotto, ospita già 2 Esempi, le caratteristiche più interessanti sono la possibilità di Relazionare Eventi, a livello grafico, oltre che l'interazione diretta di Spostamento/Ridimensionamento Runtime interagendo direttamente con i BORDI degli eventi disegnati.
LAspetti tecnici che reputo molto interessanti:
1) GESTIONE GERARCHICA
Questa parte è visibile nel 2° esempio e si possono notare gli effetti della programmazione OOP, spostando Oggetti figlio e verificando l'adeguamento dei Limiti Temporali degli Oggetti Padre... [clsItems] e [clsItem]
2) STAMPA del GANTT
Ci sono 2 opzioni, una è "relativamente banale", viene fatta l'esportazione del progetto come Immagine fisica sempre sfruttando il Wrapper.
La seconda opzione credo sia tecnicamente molto interessante, ovvero la gestione della Generazione di un Report basato sull'oggetto Report nativo di Access, sempre disegnando a Runtime con le primitive grafiche di Access, cosa complicata è stato gestire la stampa grafica delle LINEE di relazione Attività...
Allego il LINK per scaricarlo:
https://1drv.ms/u/s!ALe2sGzrs4WCh2o
@Alex
Questo il sito di Thierry Gasperment:
https://arkham46.developpez.com/articles/office/clgdiplus/
Questa Classe ingloba tutta una serie di strumenti grafici sfruttando la possibilità di lavorare in Memoria con la Grafica quindi consente di avere velocità di esecuzione notevoli, per poi depositare nel controllo Immagine di Access il ByteArray corrispondente all'immagine precedentemente elaborata.
Sfruttando questo sistema quindi è possibile disegnare quasi qualsiasi controllo anche molto elaborato.
In questo caso ho provato a realizzare un GANTT GERARCHICO, ovvero una rappresentazione temporale di attività che possono avere anche una struttura ad Albero gerarchica assimilabile al TreeView.
Personalmente utilizzo per lavoro MsProject, quindi mi sono ispirato alla grafica offerta da questo prodotto.
Tutto viene DISEGNATO RUNTIME, poi viene gestita l'interazione con l'oggetto sfruttando la struttura di Classi e Collection che memorizzano le informazioni necessarie.
Nell'allegato trovare un tutorial minimal in un inglese abbastanza frettoloso...
Il Demo che si trova al Link sotto, ospita già 2 Esempi, le caratteristiche più interessanti sono la possibilità di Relazionare Eventi, a livello grafico, oltre che l'interazione diretta di Spostamento/Ridimensionamento Runtime interagendo direttamente con i BORDI degli eventi disegnati.
LAspetti tecnici che reputo molto interessanti:
1) GESTIONE GERARCHICA
Questa parte è visibile nel 2° esempio e si possono notare gli effetti della programmazione OOP, spostando Oggetti figlio e verificando l'adeguamento dei Limiti Temporali degli Oggetti Padre... [clsItems] e [clsItem]
2) STAMPA del GANTT
Ci sono 2 opzioni, una è "relativamente banale", viene fatta l'esportazione del progetto come Immagine fisica sempre sfruttando il Wrapper.
La seconda opzione credo sia tecnicamente molto interessante, ovvero la gestione della Generazione di un Report basato sull'oggetto Report nativo di Access, sempre disegnando a Runtime con le primitive grafiche di Access, cosa complicata è stato gestire la stampa grafica delle LINEE di relazione Attività...
Allego il LINK per scaricarlo:
https://1drv.ms/u/s!ALe2sGzrs4WCh2o
@Alex
RobertoA
Jan 2, 2020, 9:17:28 AM1/2/20
to
Un tantino al di la' delle mie possibilita' come impegno di risorse per
comprenderli a fondo e modificarli, ma verranno sicuramente utili
Molto interessante soprattutto capire cosa si puo' ottenere seguendo
percorsi non battuti frequentemente (pitturare a colpi di api grafiche)
simoca...@gmail.com
Jan 3, 2020, 8:03:15 AM1/3/20
to
> Ho preso spunto da una pubblicazione in un sito interessante Francese che pubblica un lavoro che ritengo di altissimo livello, ovvero una Classe Wrapper verso GDI+.
>
> Questo il sito di Thierry Gasperment:
> https://arkham46.developpez.com/articles/office/clgdiplus/
>
> Questa Classe ingloba tutta una serie di strumenti grafici sfruttando la possibilità di lavorare in Memoria con la Grafica quindi consente di avere velocità di esecuzione notevoli, per poi depositare nel controllo Immagine di Access il ByteArray corrispondente all'immagine precedentemente elaborata.
>
Non sarebbe più interessante riprendere quello per sviluppare una classe con metodi Line/Pset/Circle operanti direttamente su ImageControl nativo?
Le API fanno il miele, ma spesso poi pungono!
Saluti d'inizio anno
@Alex
Jan 3, 2020, 9:18:54 AM1/3/20
to
...
Lebans ha relizzato una Classe che EMULA il copntrollo PictureBox, ma usa GDI32 che poi è una classe equiparabile a GDI+ le differenze sono che una è sviluppata in C l'altra in C++, con differendi approcci OOP... ma direi che sono molto simili.
Mi riferisco a questo:
http://www.lebans.com/imageclass.htm
Se invece è altro me lo sono perso... magari puoi aiutarmi dandomi un riferimento.
> Le API fanno il miele, ma spesso poi pungono!
Si pungono come sempre se non sei APICULTORE..., però ci sono anche ottimi OCX esterni...
> Saluti d'inizio anno
Ciao Simone.
@Alex
>
> M'hai fatto ripensare a quell'antico gioiellino di Lebans, il "PaintProgram" che praticamente senza API (forse solo la conversione twip - pixel) permette di disegnare direttamente sul controllo immagine di Access.
> Non sarebbe più interessante riprendere quello per sviluppare una classe con metodi Line/Pset/Circle operanti direttamente su ImageControl nativo?
Per quanto ne so, sono metodi usabili SOLO nei REPORT... (infatti nel report ho usato proprio questi) sicuro di non intendere quello...?
> M'hai fatto ripensare a quell'antico gioiellino di Lebans, il "PaintProgram" che praticamente senza API (forse solo la conversione twip - pixel) permette di disegnare direttamente sul controllo immagine di Access.
> Non sarebbe più interessante riprendere quello per sviluppare una classe con metodi Line/Pset/Circle operanti direttamente su ImageControl nativo?
Lebans ha relizzato una Classe che EMULA il copntrollo PictureBox, ma usa GDI32 che poi è una classe equiparabile a GDI+ le differenze sono che una è sviluppata in C l'altra in C++, con differendi approcci OOP... ma direi che sono molto simili.
Mi riferisco a questo:
http://www.lebans.com/imageclass.htm
Se invece è altro me lo sono perso... magari puoi aiutarmi dandomi un riferimento.
> Le API fanno il miele, ma spesso poi pungono!
> Saluti d'inizio anno
Ciao Simone.
@Alex
simoca...@gmail.com
Jan 3, 2020, 10:24:19 AM1/3/20
to
> Per quanto ne so, sono metodi usabili SOLO nei REPORT... (infatti nel report ho usato proprio questi) sicuro di non intendere quello...?
>
> Lebans ha relizzato una Classe che EMULA il copntrollo PictureBox, ma usa GDI32 che poi è una classe equiparabile a GDI+ le differenze sono che una è sviluppata in C l'altra in C++, con differendi approcci OOP... ma direi che sono molto simili.
>
> Mi riferisco a questo:
> http://www.lebans.com/imageclass.htm
>
> Se invece è altro me lo sono perso... magari puoi aiutarmi dandomi un riferimento.
https://www.lebans.com/paintprogram.htm
Una chicca in puro VBA che pilota un controllo immagine standard di Access.
Da questa base si potrebbe creare una classe che simula le primitive grafiche di VB per disegnare sull'ImageControl nativo (.MyLine, .MyPset, .MyCircle)
Con ottime garanzie di funzionamento attraverso i secoli (ovvero aggiornamenti a nuove versioni di Win e Access).
Saluti festivi
P:S: Il lavoro sui diagrammi di Gantt è una meraviglia, complimenti.
@Alex
Jan 3, 2020, 10:35:39 AM1/3/20
to
Il giorno venerdì 3 gennaio 2020 16:24:19 UTC+1, simoca...@gmail.com ha scritto:
> > Per quanto ne so, sono metodi usabili SOLO nei REPORT... (infatti nel report ho usato proprio questi) sicuro di non intendere quello...?
> >
> > Lebans ha relizzato una Classe che EMULA il copntrollo PictureBox, ma usa GDI32 che poi è una classe equiparabile a GDI+ le differenze sono che una è sviluppata in C l'altra in C++, con differendi approcci OOP... ma direi che sono molto simili.
> >
> > Mi riferisco a questo:
> > http://www.lebans.com/imageclass.htm
> >
> > Se invece è altro me lo sono perso... magari puoi aiutarmi dandomi un riferimento.
>
>
>
> Mi riferivo a questo:
>
> https://www.lebans.com/paintprogram.htm
Sai che non l'ho mai visto... e questo mi preoccupa... invecchio.
> > Per quanto ne so, sono metodi usabili SOLO nei REPORT... (infatti nel report ho usato proprio questi) sicuro di non intendere quello...?
> >
> > Lebans ha relizzato una Classe che EMULA il copntrollo PictureBox, ma usa GDI32 che poi è una classe equiparabile a GDI+ le differenze sono che una è sviluppata in C l'altra in C++, con differendi approcci OOP... ma direi che sono molto simili.
> >
> > Mi riferisco a questo:
> > http://www.lebans.com/imageclass.htm
> >
> > Se invece è altro me lo sono perso... magari puoi aiutarmi dandomi un riferimento.
>
>
>
> Mi riferivo a questo:
>
> https://www.lebans.com/paintprogram.htm
> Una chicca in puro VBA che pilota un controllo immagine standard di Access.
> Da questa base si potrebbe creare una classe che simula le primitive grafiche di VB per disegnare sull'ImageControl nativo (.MyLine, .MyPset, .MyCircle)
> Con ottime garanzie di funzionamento attraverso i secoli (ovvero aggiornamenti a nuove versioni di Win e Access).
> Saluti festivi
>
> P:S: Il lavoro sui diagrammi di Gantt è una meraviglia, complimenti.
Ciao, grazie.
@Alex
simoca...@gmail.com
Jan 3, 2020, 12:20:36 PM1/3/20
to
> Non posso aprirlo... VERSIONING non compatibile ho solo 365... se hai modo di convertirlo ed inviarmelo privatamente lo guardo perchè mi interessa molto.
>
Saluti
@Alex
Jan 3, 2020, 2:07:08 PM1/3/20
to
...
Veloce sguardo... di fatto costruisce il ByteArray relativo all'area Grafica impegnata dal Controllo Immagine aggiungendo l'header tipico delle BMP nei primi 8Byte(da 40-48 dell'array)... in sostanza disegna sempre in memoria sui Byte.
Se abbiamo compreso di cosa si sta parlando si intuiscono i problemi... ma proviamo a vederli insieme magari mi sbaglio e la sto complicando.
Quelli semplici da vedere a primo impatto:
1) Risoluzione (questo è un grosso problema)
2) Definizione (immagine BitMap a 8bit)
3) Rapporto X/Y che obbliga la dimensione del DOT=3Pixels se ho inteso bene e questo è un Grosso problema
4) Legato alla risoluzione i colori(questo non è un problema sono fin troppi)
5) Oggetti... ipotiziamo l'Event da disegnare, richiede la distinzione dell'Oggetto dal disegno...
Questo perchè la primitiva del Rettangolo deve disegnarlo nei Byte e non nello spazio X/Y... quindi il disegno PUNTO PER PUNTO è veramente complesso e lungo.
6) Eventi ed Interazione, per gestirlo serve convertire i ByteArray della primitiva in Coordinate X/Y equivalenti di tutti i contorni, e di tutti Gli Oggetti, ma il bello è che ad ogni MOVE serve ciclarle SEMPRE tutta la collection degli Oggetti e confrontarte O MOVE sulla Picture.
7) Creare Classi di Primitive Grafice dipendenti dalla Risoluzione quindi Dalla dimensione del ByteArray
Per capire da X/Y il Puntatore del Pixel [lngPixel)
lngTempY = lngY * 76 ' (600 / 8)
lngTempX = lngX / 8
lngPixel = lngTempY - lngTempX ' INDICE DEL BYTE nel BYTEARRAY
8) Il Testo... non vorrei ma serve scrivere codice per costruire i FONTS... e con 3Pixels di definizione...
L'esempio è molto bello dal punto di vista tecnico... ma...
Che dici ho dimenticato qualche cosa di grosso...?
@Alex
> In questo momento ho a disposizione solo un portatile col vecchio Access 2003, se la conversione a tale formato ti va bene postami una mail a cui spedirlo.
>
> Saluti
Nel frattempo un caro amico che ha letto mi ha fatto la cortese conversione, ma sarebbe stato OK la 2003, compatibile con A365.
>
> Saluti
Veloce sguardo... di fatto costruisce il ByteArray relativo all'area Grafica impegnata dal Controllo Immagine aggiungendo l'header tipico delle BMP nei primi 8Byte(da 40-48 dell'array)... in sostanza disegna sempre in memoria sui Byte.
Se abbiamo compreso di cosa si sta parlando si intuiscono i problemi... ma proviamo a vederli insieme magari mi sbaglio e la sto complicando.
Quelli semplici da vedere a primo impatto:
1) Risoluzione (questo è un grosso problema)
2) Definizione (immagine BitMap a 8bit)
3) Rapporto X/Y che obbliga la dimensione del DOT=3Pixels se ho inteso bene e questo è un Grosso problema
4) Legato alla risoluzione i colori(questo non è un problema sono fin troppi)
5) Oggetti... ipotiziamo l'Event da disegnare, richiede la distinzione dell'Oggetto dal disegno...
Questo perchè la primitiva del Rettangolo deve disegnarlo nei Byte e non nello spazio X/Y... quindi il disegno PUNTO PER PUNTO è veramente complesso e lungo.
6) Eventi ed Interazione, per gestirlo serve convertire i ByteArray della primitiva in Coordinate X/Y equivalenti di tutti i contorni, e di tutti Gli Oggetti, ma il bello è che ad ogni MOVE serve ciclarle SEMPRE tutta la collection degli Oggetti e confrontarte O MOVE sulla Picture.
7) Creare Classi di Primitive Grafice dipendenti dalla Risoluzione quindi Dalla dimensione del ByteArray
Per capire da X/Y il Puntatore del Pixel [lngPixel)
lngTempY = lngY * 76 ' (600 / 8)
lngTempX = lngX / 8
lngPixel = lngTempY - lngTempX ' INDICE DEL BYTE nel BYTEARRAY
8) Il Testo... non vorrei ma serve scrivere codice per costruire i FONTS... e con 3Pixels di definizione...
L'esempio è molto bello dal punto di vista tecnico... ma...
Che dici ho dimenticato qualche cosa di grosso...?
@Alex
simoca...@gmail.com
Jan 4, 2020, 5:47:03 AM1/4/20
to
>
> Veloce sguardo... di fatto costruisce il ByteArray relativo all'area Grafica impegnata dal Controllo Immagine aggiungendo l'header tipico delle BMP nei primi 8Byte(da 40-48 dell'array)... in sostanza disegna sempre in memoria sui Byte.
>
> Se abbiamo compreso di cosa si sta parlando si intuiscono i problemi... ma proviamo a vederli insieme magari mi sbaglio e la sto complicando.
>
> Quelli semplici da vedere a primo impatto:
> 1) Risoluzione (questo è un grosso problema)
> 2) Definizione (immagine BitMap a 8bit)
> 3) Rapporto X/Y che obbliga la dimensione del DOT=3Pixels se ho inteso bene e questo è un Grosso problema
> 4) Legato alla risoluzione i colori(questo non è un problema sono fin troppi)
> 5) Oggetti... ipotiziamo l'Event da disegnare, richiede la distinzione dell'Oggetto dal disegno...
> Questo perchè la primitiva del Rettangolo deve disegnarlo nei Byte e non nello spazio X/Y... quindi il disegno PUNTO PER PUNTO è veramente complesso e lungo.
> 6) Eventi ed Interazione, per gestirlo serve convertire i ByteArray della primitiva in Coordinate X/Y equivalenti di tutti i contorni, e di tutti Gli Oggetti, ma il bello è che ad ogni MOVE serve ciclarle SEMPRE tutta la collection degli Oggetti e confrontarte O MOVE sulla Picture.
> 7) Creare Classi di Primitive Grafice dipendenti dalla Risoluzione quindi Dalla dimensione del ByteArray
>
> Per capire da X/Y il Puntatore del Pixel [lngPixel)
> lngTempY = lngY * 76 ' (600 / 8)
> lngTempX = lngX / 8
> lngPixel = lngTempY - lngTempX ' INDICE DEL BYTE nel BYTEARRAY
>
> 8) Il Testo... non vorrei ma serve scrivere codice per costruire i FONTS... e con 3Pixels di definizione...
>
> L'esempio è molto bello dal punto di vista tecnico... ma...
>
> Che dici ho dimenticato qualche cosa di grosso...?
>
> @Alex
Tieni presente che ai tempi in cui utilizzai questa utility usavo monitor 800x600 (l'avevo sfruttato per implementare una Firma digitale per corrieri mi pare) e l'uomo era sbarcato da poco sulla Luna ;-)
Rivisto oggi su un monitor da 24 pollici denuncia i suoi limiti: le problematiche che hai individuato sono d'improbabile soluzione, o comunque senza certezze sul risultato finale (anche perchè poni l'asticella delle features richieste molto in alto).
Rileggendo il sorgente peraltro non m'è chiaro il motivo dell'imposizione del DOT=3 px che già costituisce un limite bloccante.
Comunque tanto di cappello alla fantasia di Lebans!
Saluti da Simone!
@Alex
Jan 4, 2020, 1:01:16 PM1/4/20
to
Ho provato velocemente a fare qualche verifica ma proprio non comprendo nemmeno io il motivo dei 3x3Pixels/dot, ma il codice è chiaro non modifica la larghezza krizzontale ma è costretto a riempire nel verticale (-2 ÷ +2) per ottenere il DOT...
Sono veramente belle applicazioni di tecnica.
@Alex
Sono veramente belle applicazioni di tecnica.
@Alex
sv
Jan 5, 2020, 6:18:19 AM1/5/20
to
E' corredato da una barra menu per la navigazione.
Il tutorial è inglobato come allegato nel database: si accede dalla voce
Help del menu.
--
sv
@Alex
Jan 5, 2020, 7:17:24 AM1/5/20
to
Grazie Salvino ottimo, efficiente come sempre.
@Alex
@Alex
0 new messages