2013-05-10 13 views
5

Ho un controllo lblDate nel controllo utente MainScreen. Vorrei modificarlo in un metodo della classe Date, che è in un altro progetto AoWLibrary. Non posso fare riferimento perché AoWLibrary dipende dal primo progetto.Modifica controllo Windows Form da un altro progetto

ho provato a fare lblDate statico, ma il compilatore mantenuto gettando errori a me, e io ho una proprietà pubblica tale data non può sembrare per accedere a:

public Label LabelDate 
    { 
     get { return lblDate; } 
     set { lblDate = value; } 
    } 

In classe Date, ho bisogno di metodo CalculateDate pubblico per modificare la proprietà Text di lblDate

public static void CalculateDate() 
    { 
     GameDate = month.ToString() + "/" + displayDay.ToString() + "/" + year.ToString(); 

    // LabelDate.Text = GameDate; 
    // This is essentially what I need to do 
    } 

Inoltre, non riesco nemmeno a lblDate accesso in altri controlli nello stesso progetto.

+2

è possibile modificare i controlli da un'altra classe se si dispone di un oggetto istanziato nella classe controller. – lexeRoy

+0

Il progettista non lo fa automaticamente? –

+0

Puoi mostrare il codice (o un campione di codice sarebbe sufficiente) dove chiami un altro modulo? – lexeRoy

risposta

1

Così, l'idea generale è che è necessario tenere traccia di ciò che è di portata. Ci sono molti modi per fare ciò che si vuole fare, ma ognuno di essi si basa su oggetti che si riferiscono l'un l'altro correttamente in modi che potrebbe non essere ancora completamente compreso. Non preoccuparti, tutti devono lavorare su questo a un certo punto.

Il motivo per cui il compilatore si è lamentato quando si è tentato di rendere statico quel membro è perché l'etichetta stessa non è statica. Essendo legato a una singola istanza di MainScreen, non ha significato in un contesto statico, che è per definizione uno scope senza alcun riferimento intrinseco a un particolare MainForm.

La classe Date è, ovviamente, anche un contesto completamente diverso, ma i membri non statici hanno accesso a un'istanza di Date. Non c'è alcun percorso tra questi due contesti finché non lo crei. La rotta statica in realtà avrebbe funzionato (guarda il pattern Singleton: l'idea è che memorizzi la prima e l'unica istanza di una classe staticamente e riferisciti ad essa da un'altra parte) ma probabilmente non è un buon progetto. Altri modi per farlo sono passando a Date un'istanza di MainScreen (preferibilmente attraverso un'interfaccia) o persino LabelDate stesso. Tutti questi potrebbero ottenere i due pezzi necessari per parlare insieme.

Tuttavia, vorrei suggerire di pensare a dove è stato memorizzato il tuo stato di gioco. È nella biblioteca o nell'assemblea consumante? Se si tratta del primo, si potrebbe voler pensare di creare un modello completo GUIless dei dati che deve essere archiviato e manipolato nella classe della libreria e consumare solo i dati già pronti così come sono nell'applicazione principale. L'altra alternativa è che il tuo modello risiede nell'applicazione principale e richiama semplicemente la tua libreria, se necessario. In questo caso, probabilmente dovresti per ora chiedere alla biblioteca le risposte (o al massimo ascoltare gli eventi nella libreria) e NON aspettarti che torni all'applicazione da sola (se ottenere o fornire informazioni).

Nel capire come eseguire questa operazione, è probabile che i problemi di gestione dell'ambito siano molto più facili da gestire. Anche un po 'di buona architettura può fare molto.

Ma se questo è tutto un po 'schiacciante, non sottolineo troppo. Sembra che tu lo stia facendo per divertimento, che è un ottimo modo per imparare. Ti imbatterai in problemi di questo tipo e non farai un buon design o uno non buono, ma in entrambi i casi stai lottando con concetti importanti e ne uscirai meglio.

+0

Ho appena controllato Singleton e l'ho implementato nel mio codice e sono molto contento di come funziona. Grazie per il tuo consiglio. Dovrebbe essere di grande aiuto per me. –

0

la proprietà LabelDate appartiene alla classe del tuo MainScreen di userControl, ma non stai installando alcun userControl .. Quale istanza di MainScreen ti aspetti di modificare?

si dovrebbe fare

this.controlMainScreen.LabelDate = GameDate; 

considerando che si dice nei vostri commenti, che avete

FormMain.Designer.cs there is: this.controlMainScreen = new Adventurers_of_Wintercrest.UserControls.MainScreen(); 
+0

In FormMain.Designer.cs c'è: this.controlMainScreen = new Adventurers_of_Wintercrest.UserControls.MainScreen(); Non è questo che deve accadere? –

+0

Vedere la mia modifica. Ciò funzionerà, naturalmente, assumendo che il tuo codice sia in FormMain (non hai mai specificato dove si trova) –

+0

Il primo bit che ho postato è in MainScreen.cs, che si trova nello spazio dei nomi Adventurers_of_Wintercrest.UserControls. Il secondo bit è in Date.cs, che si trova nello spazio dei nomi AoWLibrary. –

0

preferirei consigliamo di effettuare il metodo GameDate per restituire una stringa quindi chiamare da il tuo progetto principale che è essenzialmente per cosa sono destinate le librerie. es .:

public static string CalculateDate() 
{ 
    return month.ToString() + "/" + displayDay.ToString() + "/" + year.ToString(); 
} 

//in your main project 
LabelDate.Text = myLibrary.CalculateDate(); 

Per accedervi da altri controlli nello stesso progetto, è necessario utilizzare un delegato - Fornire un delegato che svolge l'aggiunta, dichiarare il delegato e richiamare la funzione dal CaculateDate. Esempio:

public delegate void dateSet(string); 

public void setDate(string date) 
{ 
    labelDate.Text = date; 
} 

poi nel metodo CaculateDate:

labeldate.Invoke(new MainForm.dateSet(), GameDate); 
+0

Dove dovrebbe andare il delegato? –

+0

Il delegato deve essere dichiarato nel progetto principale in cui esiste l'etichetta. –

Problemi correlati