Newsgroup: it.comp.appl.access
Titolo: Piazzare controlli a run-time su form vuota, e reagire agli eventi

Dispongo di una form vuota, che indica diciamo la sala di un ristorante
Vorrei piazzare sulla form dei command button, scegliendoli da una lista 
di record esistenti, dei tasti che indicheranno i tavoli
Quindi ho il mio bel archivietto di tavoli dall'1 al 10
Ogni tavolo ha la sua dimensione, il suo colore, la sua caption, ecc..
Dalla form 'SelezionaTavolo' vorrei selezionare il tavolo 8 che 
magicamente dovra' apparire sulla form 'salaRistorante'
Allora le domande sono:
- se la form 'salaRistorante' non dispone del command button per 
indicare il tavolo da aggiungere, come crearlo 'al volo'?
- come fare per 'trascinarlo' o 'spostarlo' usando il puntatore del mouse?
- per questi controlli, come definire gli eventi cui reagiranno e 
metterci del codice?

La premessa è che se i controlli non ci sono... non li crei... dando per scontato che lo sviluppo funzionerà con Runtime o Compilato.
 
Ne consegue che devi piazzare nella maschera i controlli in quantità sufficiente sapere di quanti sono i Tavoli massimi.
 
Ora la maschera in questione deve essere NON ASSOCIATA ma devi leggere il recorder di prenotazione SALA per configurarla.
 
Cicli il rs  ed assegni i controlli al record.
 
Qui hai 2 strade... se sai usare le classi io già pubblicai un codice qualche tempo fa su un campeggio...
Costruisci la classe Tavolo con le sue proprietà ed ad ogni Record istanzi una classe tavolo che inserirsi nella collection Tavoli.
Alla classe assegni un controllo libero del tavolo... e nella classe definirei il controllo con WithEvets per gestirne gli eventi, e realizzerei eventi di classe ribaltati nella Form passando la classe stessa.
 
Codice compatto e semplice... OOP.
 
Altra strada, senza le classi, ti impone di scrivere codice INDICIZZATO ovvero con INDICI specifici per Tavolo in modo da non scrivere una funzione per Tavolo ma una funzione unica, qualsiasi essa sia, che sapendo di che Tavolo si tratti reagisca.
 
Per questo sarai obbligato ad avere anche i NOMI CONTROLLI(TAVOLI) indicizzati, io definirei anche la proprietà TAG=Indice
Tavolo_1
Tavolo_2
....
Tavolo_n
 
Tutte le funzioni avranno come parametro Indice.
Nei controlli poi devi gestire gli eventi ma ti basta creare u a funzione pubblica nella maschera e chiamarla
Su Click()="=nomefunzione()"
 
La funzione rileva il controllo Attivo e da seguito alla chiamata delle funzioni indicizzate.
 
Per la posizione la devi salvare nella tabella... e quando cicli il rs la leggi e formatti ci controlli.
 
Ovviamente io farei tutto a classi per preferenza logica, ma siccome comprendo non sia un sistema alla portata di tutti hai anche l'altra opzione...
 
P.s. per non avere limiti di controlli potresti fare tutto con le API e GDI+ è un lavoretto semplice pratico... ma ognuno fa quello che riesce.
 
@Alex

Questo era il DEMO del sistema di gestione CAMPEGGIO:
https://1drv.ms/u/s!ALe2sGzrs4WChnk
 
 
Quì trovi un esempio di un personaggio che forse pochi hanno avuto modo di conoscere (un ottimo programmatotre):
http://www.baldyweb.com/Samples/DragFloorPlan.zip
 
 
Ovviamente anche questo esempio approccia con le classi, perchè questa è la TIPICA applicazione in cui si può sfruttare la programmazione ad oggetti.
 
@Alex


 
 
 
Sono scettico sulla possibilità d'usare questo sistema al posto di WithEvents in modulo di classe, poichè in questo tipo d'applicazione sarà necessario gestire i parametri generati dall'evento MouseMove:
 
MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)
 
Utilizzando:  Click()="=nomefunzione()"
 
Non dovrebbe essere possibile.
A mio avviso, solo Classi per Tavoli, Mappe parcheggi e campeggi in MS Access.
 
Saluti


Esempi mooolto carini entrambi
Quello del Baldiweb e' esattamente quel che mi servirebbe fare
Non mi e' ancora ben chiaro come vengano inseriti gli oggetti nel 
progetto, non credo sia stato popolato il db e poi la routine visualizza 
tutto quel che trova in archivio, sono circa 700 oggetti nell'esempio 
proposto, come li ha messi dentro?
Anche se sono un bel po' di oggetti, Le prestazioni, per quell'esempio, 
non sono incoraggianti
Nel mio caso ho circa un centinaio di command button da visualizzare, ma 
su un i7 con ssd e ram in abbondanza mi sarei atteso qualche secondo di meno
 

 Saluti
 
Assolutamente corretto... gli eventi Parametrizzati rendono improbabile la semplificazione.
 
Ovviamente per optare per le Classi è indispensabile padrioneggiarle, altrimenti si moltiplicano gli Eventi nel Codice FORM, ma centralizzando poi le chiamate a Funzioni indicizzate... altrimenti c'è da morire...
 
Riconfermo che le Classi in questo caso sono la soluzione migliore.
 
@Alex

 su un i7 con ssd e ram in abbondanza mi sarei atteso qualche secondo di meno
 
Si ma lui disegna anche il LOCALE... con oggetti... cosa che francamente trovo solo un ESERCIZIO dimostrativo.
 
COn 100 CommandButton deve essere quasi istantaneo, fai attenzione a MUOVERE/DIMENSIONARE poi rendere VISIBILE TUTTO che è una cosa non scontata ma che ha la sua importanza.
 
Fossi in te io disegnerei fisso o con una BMP il Locale, se fosse rettangolare sarebbe semplice se ha superfice più complessa serve un po più di lavoro per definire i MARGINI da attivare al MouseMove... ma in quel caso devi memorizzare una serie di Punti che corrispondono a INIZIO FINE dei Segmenti di linea dei Muri... quindi se hai la BMP devi in ogni caso trovare X/Y e memorizzarli... se lo disegni con le LINEE è più semplice da Memorizzare ma sempre da fare.
 
@Alex

 non sono incoraggianti
 
 
Il tipo non ha disabilitato l'aggiornamento dello Schermo:
 
 
Application.Echo False
 
Me.RecordSource = conParentTableName
 ...................
OpenProject
 
Application.Echo True
 
 
Vedrai che le prestazioni migliorano notevolmente.
 
Saluti

E gestione errori altrimenti si rischia di bloccare tutto...
 
@Alex

bello ma troppo sofisticato e pesante da gestire.
 
io ho risolto  con un solo controllo immagine.
 
mi creo e salvo un'immagine totale della tastiera con le sotto immagini dei tavoli  che mi servono, poi la carico nella maschera e rilevo la pressione del tasto con l'evento del controllo immagine :
 
 MouseDown(Button As Integer, Shift As Integer, x As Single, Y As Single)
 
scalando opportunamente x,y mi trovo la riga e la colonna del tasto premuto.
 
semplice e efficace , un solo evento da gestire, funziona a runtime.

Sofisticato lo riterrei estremamente soggettivo, mentre pesante assolutamente no, quando si lavora con le classi si usano pointer in memoria e sono estremamente veloci e performanti.
La programmazione ad oggetti si basa su questi metodi... ci fanno i Giochi in OOP e quelli sono i più avidi di risorse.
 
La comodità di scrivere una classe Oggetto e riusarla riduce drasticamente il codice da scrivere e concentra le eventuali modifiche in una classe sola.
 
Non parliamo di quanto si incrementa lo spazio in memoria richiesto dal tuo applicativo quando carichi la tua BMP... di svariati MB... se non decine di MB... per rivedere la questione di PESANTEZZA cui accennavi.
 
Detto ciò con la tua ipotesi la possibilità di interazione grafica è sostanzialmente azzerata... tieni presente che magari voleva anche gestire spostamenti di tavoli, come mi pareva chiedesse al primo 3D, e/o aggregazioni di 2 tavoli singoli da 4 in un tavolo da 6 o 8 ... fare una festa con una tavolata unica ecc..
 
Come sempre serve valutare:
Propria Capacità
Necessità
Obbligo(verso il cliente)
 
@Alex
 


Troppo semplice: in questo genere di applicazioni è necessario poter personalizzare ogni singolo oggetto (colori, dimensioni, posizioni) e poterne "creare" di nuovi.
La soluzione che proponi è molto rigida.
 
Saluti
 
 
 


Interessante pure questo
Uno scheletrino di codice e' possibile vederlo?
Magari se c'e' un po' di ciccia intorno meglio ancora