Comment mettre à jour l'interface UserControl au moment de la conception en fonction de la valeur de la propriété?

Question

J'ai créé un UserControl avec la propriété publique suivante:

[Browsable(true)] 
public string Text 
{ 
    get { return pnlLookupTable.GroupingText; } 
    set { pnlLookupTable.GroupingText = value; } 
} 

pnlLookupTable est, comme vous l'aurez deviné, un contrôle Panel. Je peux changer la valeur de la propriété Text dans la fenêtre Propriétés et elle est reflétée dans le balisage comme il se doit. Toutefois, la vue de conception du contrôle UserControl à l'intérieur d'une page n'affiche pas GroupingText mis à jour pour le panneau. Comment puis-je obtenir cela?

EDIT:

Sur demande, voici toute la classe à laquelle appartient cette propriété. Vous pouvez voir qu'il n'y a rien de spécial se passe:

using System; 
using System.Collections.Generic; 
using System.ComponentModel; 
using System.Linq; 
using System.Web; 
using System.Web.UI; 
using System.Web.UI.WebControls; 

public partial class LookupTable : System.Web.UI.UserControl 
{ 
    [Browsable(true)] 
    public string Text 
    { 
     get { return pnlLookupTable.GroupingText; } 
     set { pnlLookupTable.GroupingText = value; } 
    } 
} 

Et voici la partie pertinente du fichier .ascx:

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="LookupTable.ascx.cs" Inherits="LookupTable" %> 
<asp:Panel ID="pnlLookupTable" runat="server" GroupingText="Lookup Table"> 
    <%-- Irrelevant content here. --%> 
</asp:Panel> 

J'ai changé quelques identifiants et d'autres choses futiles pour protéger la nature exclusive de la code.

Je devrais également réitérer que je regarde un formulaire Web en mode de conception qui a mon contrôle ajouté, et je change la propriété de texte. Je veux voir la modification de GroupingText du Panel visuellement dans le concepteur.

Answer 1

Je dois penser un peu en arrière au code UserControlDesigner ...

histoire courte: Je ne pense pas qu'il soit possible.

Et voici la longue histoire:

D'après ce que je me souviens, les contrôles utilisateur situés dans des fichiers ASCX ne sont jamais exploités dans le concepteur. C'est-à-dire, le code dans le fichier ASCX ou ASCX.CS n'est jamais compilé ou exécuté dans Visual Studio. Cela permet d'éviter les fuites de mémoire causées par le fait que dans le CLR, vous ne pouvez pas décharger les assemblys que vous avez chargés. Pour exécuter le code dans votre contrôle utilisateur, Visual Studio doit compiler votre ASCX dans une DLL, puis le charger et ensuite exécuter le code. Chaque fois que vous apportez une modification à l'ASCX, il doit effectuer à nouveau cette opération. Chaque fois que cette opération se produit, plus de mémoire sera consommée par la DLL supplémentaire générée à partir de votre ASCX.

En raison de cette limitation dans le CLR, le concepteur du contrôle utilisateur ne compile pas ou n'exécute pas le fichier ASCX. Au lieu de cela, il analyse le fichier ASCX et recherche les contrôles à l'intérieur et il charge ces contrôles à la place. Pour chaque contrôle trouvé dans le fichier ASCX, il créera le concepteur de contrôle associé et rendra le temps de conception HTML de ce contrôle.

Il y a deux façons de contourner ce problème:

1. Au lieu d'utiliser un contrôle utilisateur ASCX vous pouvez écrire un contrôle régulier personnalisé qui dérive de contrôle et le code est écrit dans un fichier CS ou VB .
2. Compilez l'ASCX dans une DLL. David Ebbo a écrit un blog post sur la façon de le faire.

La raison pour laquelle ces deux solutions devraient fonctionner est qu'elles impliquent que le code soit compilé dans une DLL. L'idée est que la DLL ne change pas très souvent, il est donc sûr que Visual Studio charge la DLL sans risque de devoir la recharger à chaque fois que la DLL change (et perd de la mémoire).

Answer 2

Je pensais que pour avoir une réponse pour cela, et écrit tout, mais quelque chose me casser les pieds à ce sujet donc j'ai fini de tester ceci pendant quelques heures.

se trouve que (tout comme Eilon dit), je ne pense pas que vous pouvez le faire.

contrôles ASCX ignorent complètement la DesignerAttribute, de sorte que vous ne pouvez pas spécifier le temps de conception personnalisée pour eux renderer. J'ai pensé "bien, je peux sous-classer le contrôle de Panel et spécifier un nouveau concepteur qui obtiendra des propriétés du contrôle parent". Devine quoi? Aucune chance. Si vous accédez au contrôle parent du Groupe spécial dans le concepteur, il ne sera pas jeté le type de usercontrol personnalisé. Je peux voir que c'est un UserControl, et il ne peut y avoir aucun autre UserControl excepté mon TestUserControl, mais la classe de concepteur jette une exception si j'essaye de la lancer!

Cela me pousse à être honnête. C'est exactement ce que dit Eilon - il y a une restriction intentionnelle sur les contrôles web en mode design.

Here's a vague post from Steven Cheng suggesting that design time support is just a no-go for web usercontrols.

Bien que ce fut une occasion d'apprentissage amusant pour moi, je suis désolé de vous annoncer que je ne pense pas .ascx sera coupé. Je suis à peu près sûr que même le compiler sur une DLL comme Eilon ne le fera même pas. Vous devrez probablement utiliser la route de contrôle personnalisé.