Risoluzione dei problemi relativi allo sviluppo in fase di progettazione
Aggiornamento: novembre 2007
Quando si crea una fase di progettazione personalizzata per componenti e controlli Windows Form, è possibile che si verifichino i seguenti problemi:
Impossibile eseguire il debug in fase di progettazione
Errore del compilatore: "Impossibile trovare il tipo o il nome dello spazio dei nomi 'nome tipo'."
Errore di progettazione: "Impossibile creare il componente 'nome componente'."
Errore di debug: "Operazione cross-thread non valida: è stato eseguito l'accesso al controllo 'nome controllo' da un thread diverso da quello da cui è stata eseguita la creazione."
Errore di progettazione: "Impossibile aprire una finestra di progettazione per il file perché contiene una classe non ereditata da una classe che possa essere progettata in modo visivo."
I glifi restano dopo l'eliminazione del componente
Il comportamento predefinito della finestra di progettazione viene oscurato dal comportamento personalizzato
Eventi della finestra di progettazione generati in maniera non intenzionale
Impossibile serializzare gli insiemi
Impossibile acquisire un riferimento UndoEngine per la finestra di progettazione
L'ambiente di progettazione non riconosce le modifiche alle proprietà del componente
Sintassi di DesignerAttribute
Aggiornamento dell'ambiente di progettazione dopo l'inserimento di modifiche al componente o alla finestra di progettazione
Avviso FxCop su un Windows Form appena generato: DoNotInitializeUnnecessarily
Classi parziali e Progettazione Windows Form
Controlli personalizzati preesistenti causano un comportamento imprevisto nella finestra di progettazione
Uno smart tag in una finestra di progettazione di hosting genera un'eccezione
L'icona del componente non viene visualizzata nella Casella degli strumenti
Impossibile eseguire il debug in fase di progettazione
Esistono due sistemi per eseguire il debug del codice in fase di progettazione:
Effettuare chiamate a MessageBox.Show in punti strategici del codice.
Associare un'altra istanza di Visual Studio per eseguire il debug dell'ambiente di progettazione della prima istanza.
Per ulteriori informazioni, vedere Procedura: accedere ai servizi per la fase di progettazione.
Errore del compilatore: "Impossibile trovare il tipo o il nome dello spazio dei nomi 'nome di tipo'"
È consigliabile fare riferimento all'assembly System.Design. I tipi correlati alla finestra di progettazione sono collocati nell'assembly System.Design, che include tipi negli spazi dei nomi System.Windows.Forms.Design e System.ComponentModel.Design.
Accertarsi inoltre di importare gli spazi dei nomi necessari utilizzando la parola chiave Imports o using. Per ulteriori informazioni, vedere Procedura: accedere al supporto in fase di progettazione in Windows Form.
Errore di progettazione: "Impossibile creare il componente 'nome componente'"
Questo errore potrebbe essere visualizzato quando si crea un componente o un controllo nell'area di progettazione dalla Casella degli strumenti. Nella tabella riportata di seguito sono illustrate le due possibili cause di errore.
Causa |
Descrizione |
Note |
|---|---|---|
Costruttore predefinito mancante |
Il componente o controllo deve disporre di un costruttore predefinito, ovvero un costruttore privo di parametri. |
Perché nell'ambiente di progettazione sia possibile creare un'istanza del tipo prescelto, è necessario un costruttore predefinito. |
Il componente è un tipo generico |
Il componente o controllo non può essere un tipo generico, denominato anche tipo modello o con parametri. L'ambiente di progettazione non supporta i tipi generici. |
Se il tipo generico deriva da UserControl e si tenta di eseguirlo in UserControl Test Container di Visual Studio, verrà visualizzato il seguente errore: Impossibile creare UserControl 'nome' Anche se i componenti e i controlli non possono essere tipi generici, essi possono utilizzare tali tipi. |
Errore di progettazione: "Il valore non può essere null. Nome parametro: 'nome componente'"
Questo errore potrebbe essere visualizzato quando si crea un componente o un controllo nell'area di progettazione dalla Casella degli strumenti. È molto probabile che il problema sia dovuto al tentativo di utilizzare un componente o un controllo generato per un assembly a 64 bit. L'ambiente di progettazione di Visual Studio non supporta i componenti a 64 bit.
Errore di debug: "Operazione cross-thread non valida: è stato eseguito l'accesso al controllo 'nome controllo' da un thread diverso da quello da cui è stata eseguita la creazione."
Se si utilizza il multithreading nelle applicazioni Windows Form, accertarsi di effettuare chiamate ai controllo in modalità thread-safe. L'eccezione viene generata dal debugger e non viene visualizzata in fase di esecuzione, ma è fortemente consigliabile risolvere il problema non appena lo si individua. Per ulteriori informazioni, vedere Procedura: effettuare chiamate thread-safe a controlli di Windows Form.
Errore di progettazione: "Impossibile aprire una finestra di progettazione per il file perché contiene una classe non ereditata da una classe che possa essere progettata in modo visivo"
Il file con il componente o il controllo può contenere più definizioni di classi, ma è necessario che la prima classe del file sia progettabile dallo sviluppatore. La prima classe del file deve implementare l'interfaccia IComponent oppure deve derivare dalla classe Component o da una classe che deriva da Component.
I glifi restano dopo l'eliminazione del componente
Se la finestra di progettazione personalizzata consente la creazione di oggetti Adorner, è necessario eliminarli nel caso in cui la finestra di progettazione risulti esterna all'ambito. Chiamare BehaviorServiceAdornerCollection.Remove nel metodo Dispose della finestra di progettazione, in modo da cancellare gli oggetti Glyph nonché gli oggetti Adorner e Behavior correlati. Per ulteriori informazioni, vedere Procedura: estendere l'aspetto e il comportamento di controlli in modalità progettazione.
Il comportamento predefinito della finestra di progettazione viene oscurato dal comportamento personalizzato
La finestra di progettazione del controllo predefinita crea un'icona che copre l'intero controllo nell'area di progettazione, denominata icona del corpo. Se la finestra di progettazione del controllo personalizzata crea un'icona con gli stessi limiti dell'icona del corpo, esso oscurerà l'implementazione sottostante di Behavior associata all'icona del corpo. In questo modo viene impedita la visualizzazione di funzionalità predefinite quali smart tag e glifi di ridimensionamento.
Non è possibile passare messaggi tra oggetti Behavior e pertanto non è possibile gestire un messaggio del mouse e inoltrarlo a eventuali oggetti Behavior sottostanti. Quando si implementa un'icona che copre l'intero controllo, si è interamente responsabili per l'aspetto e il comportamento della progettazione personalizzata.
Eventi della finestra di progettazione generati in maniera non intenzionale
Se la finestra di progettazione personalizzata associa i gestori eventi a eventi di progettazione quali ComponentRemovedActiveDesignerChanged e SelectionChanged, è necessario disconnettere i gestori eventi nel metodo Dispose della finestra di progettazione.
Se tale operazione non viene eseguita, può derivarne un comportamento non intenzionale in fase di progettazione. Nell'elenco riportato di seguito sono illustrati alcuni sintomi che potrebbero verificarsi:
Finestra di messaggio di errore: "Errore durante l'elaborazione del comando."
Finestra di messaggio di errore: "Riferimento a un oggetto non impostato su un'istanza di oggetto."
Chiamata inappropriata dei gestori eventi al momento dell'eliminazione dei componenti o della chiusura delle finestre di progettazione.
Impossibile serializzare gli insiemi
Se si desidera serializzare la proprietà dell'insieme del controllo o del componente personalizzato, applicare l'oggetto DesignerSerializationVisibilityAttribute e impostarlo su Content. Per ulteriori informazioni, vedere Procedura: serializzare insiemi di tipi standard mediante DesignerSerializationVisibilityAttribute.
Impossibile acquisire un riferimento UndoEngine per la finestra di progettazione
Se si tenta di acquisire un riferimento al servizio UndoEngine durante il caricamento di un form, il metodo GetService restituirà null.
Il servizio UndoEngine non viene creato né attivato fino a che la fase di caricamento del form non sarà stata completata. Dopo che il form è stato caricato, le successive chiamate al metodo GetService restituiranno un riferimento a UndoEngine.
In generale, un riferimento diretto a UndoEngine dovrebbe essere richiesto raramente. I casi in cui potrebbe essere necessario dipendono solitamente da un'azione dell'utente e si verificano dopo che è avvenuto il caricamento della finestra di progettazione.
L'ambiente di progettazione non riconosce le modifiche alle proprietà del componente
L'ambiente di progettazione non riconosce le modifiche al componente o al controllo se le proprietà vengono impostate direttamente. Per generare eventi quali ad esempio ComponentChanged, è necessario impostare il valore delle proprietà del componente mediante il metodo PropertyDescriptor.SetValue. In tal modo è possibile notificare all'ambiente di progettazione la modifica della proprietà, consentendo il corretto aggiornamento dell'area di progettazione e dei controlli PropertyGrid. Per ulteriori informazioni, vedere Procedura: estendere l'aspetto e il comportamento di controlli in modalità progettazione.
Sintassi di DesignerAttribute
Per associare la finestra di progettazione personalizzata al controllo in essa progettato, è possibile applicare l'oggetto DesignerAttribute al controllo.
È necessario specificare in maniera precisa i parametri di DesignerAttribute, altrimenti l'ambiente di progettazione non consentirà il caricamento della finestra di progettazione personalizzata.
Aggiornamento dell'ambiente di progettazione dopo l'inserimento di modifiche al componente o alla finestra di progettazione
Quando si apportano modifiche agli aspetti di progettazione di un componente, è necessario rigenerare il progetto del componente. Se inoltre è aperto un altro progetto Windows Form che utilizza questo componente, è probabile che sarà necessario aggiornare il progetto per visualizzare le modifiche. Di norma, è necessario chiudere e riaprire la finestra di progettazione contenente il componente.
Avviso FxCop su un Windows Form appena generato: DoNotInitializeUnnecessarily
In Progettazione Windows Form viene generato il codice riportato di seguito per i progetti Applicazione Windows Form in C#.
private System.ComponentModel.IContainer components = null;
A seconda delle regole FxCop attive, è possibile che venga generato l'avviso "DoNotInitializeUnnecessarily" in quanto il valore predefinito di Common Language Runtime per le proprietà di riferimento è null.
Se nella finestra di progettazione il campo components non è stato inizializzato su null, nel compilatore C# verrà generato il seguente messaggio di avviso:
"Impossibile assegnare un valore diverso a Form1.components. Il valore predefinito è null."
È possibile eliminare l'avviso FxCop con SuppressMessageAttribute, tuttavia possono verificarsi problemi di manutenzione se il nome della classe viene modificato. Si consiglia pertanto di ignorare l'avviso FxCop.
Classi parziali e Progettazione Windows Form
Per impostazione predefinita, Progettazione Windows Form consente di produrre codice di serializzazione della finestra di progettazione in un file dedicato separato dal file principale del componente. In un progetto Applicazione Windows Form, ad esempio, la definizione relativa alla classe Form1 viene suddivisa in due file, come illustrato nella tabella seguente.
File (nomi file in linguaggio C#) |
Funzione |
|---|---|
Form1.cs |
File di classe principale |
Form1.Designer.cs |
Codice creato dalla finestra di progettazione |
File (nomi file in linguaggio VB) |
Funzione |
|---|---|
Form1.vb |
File di classe principale |
Form1.Designer.vb |
Codice creato dalla finestra di progettazione |
Non è in genere necessario modificare il codice creato da Progettazione Windows Form. In alternativa, modificare il file di classe principale.
In Progettazione Windows Form viene utilizzata la parola chiave partial per dividere l'implementazione di Form1 in due file separati. In tal modo si evita che il codice creato dalla finestra di progettazione venga frammisto al codice dello sviluppatore. Per ulteriori informazioni sulla parola chiave partial, vedere Classi e metodi parziali (Guida per programmatori C#) e Partial (Visual Basic).
In Progettazione Windows Form non è supportata la divisione di una definizione di tipo progettabile in più di due implementazioni partial. Questa restrizione comprende la creazione di un nuovo file di classe che contiene una terza definizione parziale del tipo, nonché l'aggiunta di una terza definizione di classe parziale del tipo sia nel file principale che nel file della finestra di progettazione. I membri definiti in tal modo non saranno visibili in Progettazione Windows Form.
Controlli personalizzati preesistenti causano un comportamento imprevisto nella finestra di progettazione
Se nella finestra di progettazione vengono invalidati i tipi, la classe ComponentSerializationService esegue un ricaricamento parziale in modo da aggiornare la finestra di progettazione con i tipi aggiornati. Nelle versioni di Visual Studio che precedono Visual Studio 2005 invece la finestra di progettazione viene ricaricata completamente. Il ricaricamento parziale che viene eseguito con Visual Studio 2005 è più veloce rispetto al ricaricamento completo e consente inoltre di mantenere lo stack di annullamento.
I componenti e i serializzatori corrispondenti creati prima di Visual Studio 2005 potrebbero non supportare un ricaricamento parziale. I componenti e i controlli possono causare un comportamento imprevisto perché creati per eseguire la deserializzazione solo durante un ricaricamento completo. Tra i sintomi sono inclusi overflow dello stack, blocchi o regioni vuote in Progettazione Windows Form quando sono presenti controlli preesistenti.
È possibile ripristinare il ricaricamento completo aggiungendo l'impostazione riportata di seguito al file devenv.exe.config. Se Visual Studio 2005 è stato installato nel percorso predefinito, questo file è contenuto nella cartella C:\Programmi\Microsoft Visual Studio 8\Common7\IDE.
<appSettings>
<add key="EnableOptimizedDesignerReloading" value="false" />
</appSettings>
Uno smart tag in una finestra di progettazione di hosting genera un'eccezione
In caso di hosting di una finestra di progettazione al di fuori di Visual Studio, è possibile che gli smart tag generino un'eccezione NullReferenceException. Per risolvere questo problema, fornire un riferimento IUIService nella finestra di progettazione e implementare la proprietà Styles. Nell'interfaccia IDictionary esposta dalla proprietà Styles assegnare una nuova classe Font come elemento specificato dalla chiave "DialogFont", come illustrato nel frammento di codice riportato di seguito.
Styles["DialogFont"] = new Font(...);
L'icona del componente non viene visualizzata nella Casella degli strumenti
Quando si utilizza ToolboxBitmapAttribute in Visual Studio per associare un'icona al componente personalizzato, la bitmap non viene visualizzata nella Casella degli strumenti per i componenti generati automaticamente. Per vedere la bitmap, ricaricare il controllo utilizzando la finestra di dialogo Scegli elementi della Casella degli strumenti.
Vedere anche
Attività
Procedura: accedere ai servizi per la fase di progettazione
Concetti
Errori in fase di progettazione in Progettazione Windows Form