Oferecer suporte e converter tipos de campo do SharePoint em aplicativos do Windows Phone
Implemente a lógica de conversão de dados para dar suporte a tipos de campo do SharePoint em aplicativos do Windows Phone.
Em projetos com base no modelo de aplicativo para Windows Phone SharePoint lista, os dados de vários tipos de campo do SharePoint são processados e coordenados pelo lógica de conversão padrão seja adequada para exibição e manipulação na interface de usuário do Silverlight de um Windows Phone, mas os desenvolvedores também podem implementar suas próprias rotinas de manipulação de dados personalizados.
Importante
Se você estiver desenvolvendo um aplicativo para Windows Phone 8, deverá usar Visual Studio Express 2012 em vez do Visual Studio 2010 Express. Com exceção do ambiente de desenvolvimento, todas as informações neste artigo se aplicam à criação de aplicativos para Windows Phone 8 e Windows Phone 7. > Para obter mais informações, consulte Como configurar um ambiente para desenvolver aplicativos móveis para o SharePoint.
Tipos de campo do SharePoint em aplicativos do Windows Phone
Listas do SharePoint são constituídas por campos de dados (organizados em colunas) e um determinado campo é designado para conter dados de um determinado tipo (ou seja, dados estruturados de uma determinada maneira). Esses tipos são chamados de tipos de campo. (Esses tipos também podem ser considerados tipos de coluna, como quando você adiciona uma coluna a uma lista do SharePoint, você está adicionando uma coluna de campos associados a um determinado tipo de dados.) Esses campos são definidos por um esquema XML. O esquema de um campo chamado "Data de ordem" com um tipo de dados de DateTime (representado como um campo de data e hora na interface de usuário de um Microsoft SharePoint Server ) pode parecer com o seguinte.
<Field Type="DateTime" DisplayName="Order Date" Required="FALSE"
EnforceUniqueValues="FALSE" Indexed="FALSE" Format="DateOnly"
FriendlyDisplayFormat="Disabled" Name="Order_x0020_Date">
<Default>[today]</Default>
<DefaultFormulaValue>2012-01-10T00:00:00Z</DefaultFormulaValue>
</Field>
Observe, em particular, o valor do atributo Type do elemento Field neste esquema especificado aqui como "DateTime". Campos de lista criados para conter dados estruturados de outras formas podem ser designados com um valor de Type de, digamos, "Opção" ou "Text" ou "Booleano".
Tipos de campo do SharePoint não podem ser vinculados diretamente para os controles do Silverlight em um aplicativo do Windows Phone. Os dados como está na lista do SharePoint devem ser preparados ou processados de forma específica (ou, em terminologia padrão de vinculação de dados do Silverlight, convertido) para ser vinculado aos controles do aplicativo e preparação e a coordenação é manipulado pela ViewModels em projetos criados usando o modelo de aplicativo para Windows Phone SharePoint lista. Projetos com base nesse modelo foram projetados para incluir lógica de conversão padrão para oferecer suporte a vinculação e a exibição de dados do SharePoint em um aplicativo do Windows Phone para um número de tipos de campo padrão do SharePoint (ou para os campos personalizados criados com base em um desses tipos de standard). Os tipos de campo compatíveis com lógica de conversão padrão são listados na tabela 1.
Tabela 1. Tipos de campo com provisionamentos para conversão padrão
| Tipo de campo do SharePoint | Tipo de dados do Silverlight |
|---|---|
| Anexos | File |
| Booliano | Boolean |
| Calculado (somente para exibição) | String |
| Opção | String |
| Moeda | Numérico |
| DateTime | Data de (representada de acordo com a localidade do telefone) |
| URL | Links |
| Inteiro | Numeric |
| Local | Geocoordinate |
| Pesquisa | Sequência |
| Multichoice | String |
| Observação | String |
| Número | Numeric |
| OutcomeChoice | Cadeia de caracteres |
| Imagem | Links |
| Texto | Cadeia de caracteres |
| User | Cadeia de caracteres |
Outros tipos de campo do SharePoint, como campos de Guid, podem ser usados em aplicativos do Windows Phone, mas os desenvolvedores precisam fornecer a lógica de conversão personalizados para oferecer suporte a vinculação e exibindo os valores para esses tipos de campo para o qual não padrão foi fornecida a lógica de conversão. (Consulte a Lógica de conversão personalizado para provisionar os tipos de campo não suportado neste artigo).
Para ilustrar como o modelo fornece conversão padrão e suporte para determinados tipos de campo, pressupõem um SharePoint lista inclui uma coluna de campos chamado "Categoria de produto" designada com um tipo de Choice e associado a várias opções, como "Recriação" e "Culinary". O esquema de tal campo no servidor pode se parecer com a seguinte marcação.
<Field Type="Choice" DisplayName="Product Category" Required="FALSE"
EnforceUniqueValues="FALSE" Indexed="FALSE" Format="Dropdown"
FillInChoice="TRUE"
Name="Product_x0020_Category">
<Default>Recreation</Default>
<CHOICES>
<CHOICE>Culinary</CHOICE>
<CHOICE>Recreation</CHOICE>
<CHOICE>Sartorial</CHOICE>
<CHOICE>Travel</CHOICE>
<CHOICE>Other</CHOICE>
</CHOICES>
</Field>
Este campo Choice tem a serem processados para poder ser adequada para exibição na interface do Windows Phone. Nesse caso, os dados no campo são representados como uma cadeia de caracteres (por exemplo, "recriação") dentro de uma coleção de valores de cadeia de caracteres (especificamente, como um dos valores da propriedade FieldValuesAsText de um objeto ListItem ). A lógica de conversão para campos de Choice extrai esta cadeia de caracteres para exibi-la na interface de usuário do telefone. A cadeia de caracteres pode ser vinculada ao e exibida em um controle TextBlock em um formulário. Se o valor é apresentado para edição, a lógica de conversão padrão para campos de Choice extrai as opções disponíveis para o campo ("Culinárias", "Recriação", "Sartorial", etc.) do esquema XML que define o campo e representa os disponíveis opções de uma coleção (especificamente, como um tipo de coleção baseada na classe ObservableCollection(T) ) de objetos sozinhos incluem a opção específica (por exemplo "Culinárias") e se essa opção foi selecionada. Essas operações são tratadas na camada ViewModel do aplicativo. Na camada ver (ou apresentação) (isto é, no arquivo XAML gerada para o formulário Editar pelo modelo de aplicativo para Windows Phone SharePoint lista), essas opções são processadas por padrão como controles do Silverlight RadioButton dentro de um controle ListBox.
Conversão personalizada para tipos de campo do SharePoint
Em projetos de Visual Studio que baseiam-se no modelo de aplicativo para Windows Phone SharePoint lista, o mecanismo de tratamento de coordenação e conversão de dados entre o SharePoint e a interface de usuário do Silverlight para Windows Phone foi projetado para ser flexível e extensível.
Dependendo a intenção de design para o seu aplicativo específico, talvez você queira fornecer a lógica de conversão para dar suporte a vinculação e exibindo os tipos de campo do SharePoint que não são fornecidos com lógica de conversão, por padrão, ou talvez você queira exibir dados de um campo com suporte de forma que difere da implementação do padrão.
Projetos com base no modelo de aplicativo para Windows Phone SharePoint lista implementam uma classe de estática Converter que inclui rotinas para registrar os métodos para manipular tipos de dados específicos para um determinado de operações de conversão de dados. O projeto inclui e registra as rotinas de conversão de dados para determinados tipos de dados por padrão. O mecanismo de registro usa representantes para permitir a extensibilidade. Os desenvolvedores, portanto, podem gravar suas próprias funções para fornecer a lógica de conversões de dados e essas funções personalizadas podem ser chamadas quando os delegados são invocados em vez das funções padrão. Para organizar as funções personalizadas a ser chamado para operações de conversão de dados, registre suas funções com a classe de Converter usando os métodos de registro da classe. O registro métodos são específicos para cada ViewModel, para acomodar a possibilidade de que você talvez queira implementar e registrar as diferentes funções para processar dados de forma diferente dependendo da, por exemplo, se os dados serão apresentados para edição ou para exibição somente (sem edição).
Dica
[!DICA] O símbolo de moeda mostrado no formulário exibição é de localidade do SharePoint, mesmo se a localidade do Windows Phone é diferente. Os desenvolvedores podem personalizar esse comportamento usando objetos Converter.
Para registrar as funções de conversão de dados para o formulário de exibição (DisplayForm.xaml), use o método RegisterDisplayFieldValueConverter da classe Converter. Para registrar as funções para o formulário de edição (EditForm.xaml), use o método RegisterEditFieldValueConverter e para o novo formulário (NewForm.xaml), use o método RegisterNewFieldValueConverter.
Você pode registrar as funções de conversão que processam os dados como se trata da lista para ser apresentado na interface do usuário (ou seja, as funções que determinam como obter dados) e você pode registrar as funções que processam dados da interface do usuário, como seu salvo à lista no servidor (funções que determinam como o conjunto de dados).
As funções de obter devem corresponder à assinatura do representante seguinte declaração na classe Converter.
public delegate object GetConvertedFieldValue(string fieldName,
ListItem item, ConversionContext context);
As funções de Definir devem corresponder à assinatura da seguinte declaração de representante.
public delegate void SetConvertedFieldValue(string fieldName,
object fieldValue, ListItem item, ConversionContext context);
O método RegisterDisplayFieldValueConverter aceita uma função de obter apenas, porque a classe DisplayItemViewModel, conforme planejado, destina-se para exibir, mas não editar dados. O RegisterEditFieldValueConverter e os métodos de RegisterNewFieldValueConverter estão sobrecarregados para aceitar uma função get, a função set ou ambos.
Em Como implementar a lógica de negócios e a validação de dados em um aplicativo Windows Phone para o SharePoint, foi desenvolvida uma rotina de validação para verificar o formato ou os números de telefone fornecidos pelo usuário de um aplicativo Windows Phone. Para demonstrar a conversão de dados personalizados, no exemplo de código a seguir, podemos implementará obter e Definir funções para manipular dados de número de telefone de uma forma específica e registrar essas funções a ser usado nos novos formulários com a classe Converter e editar.
Suponha para fins do seguinte exemplo de código que você tenha criado um aplicativo de lista do SharePoint de telefone do Windows com base em uma lista de ordens de produto criada usando o modelo de lista personalizada no servidor. Pressupõem que a lista tem um campo chamado "Contato Number" e que esse campo é designado como um campo Text na lista. Na configuração padrão de um campo de lista designado como um tipo de Text em um SharePoint Server, um usuário pode inserir quaisquer caracteres de texto (até 255 caracteres). O modelo fornece a lógica de conversão padrão para a exibição e edição de dados de campos de Text no SharePoint, mas um campo Text (por padrão) não está estruturada para impor ou exibir qualquer formatação específica, como podem ser convencionalmente aplicado aos números de telefone. No seu aplicativo do Windows Phone, você talvez prefira números de telefone a ser exibida aos usuários de maneira consistente e, quando salvo no servidor, na lista formatada de uma forma específica, mesmo que o tipo de campo subjacente ( Text) não está associado com as regras de formatação específicas. Para aplicar suas regras de formatação específicas, você pode implementar sua própria lógica de conversão de dados personalizados no lugar a lógica de padrão para um tipo de campo suportadas.
Para implementar a conversão de dados personalizados
Supondo que você tenha criado uma lista em um SharePoint Server que inclua um campo de texto chamado "Número de Contato" (como a lista de exemplos de Pedidos de Produto usada em Como implementar lógica comercial e validação de dados em um aplicativo Windows Phone para SharePoint), crie um aplicativo Windows Phone usando o Windows Phone Modelo de aplicativo de lista do SharePoint no Visual Studio seguindo as etapas detalhadas em Como: Criar um aplicativo de lista do SharePoint Windows Phone.
No Solution Explorer, escolha o nó que representa o projeto (chamado, por exemplo, ContosoSPListApp).
No menu projeto em Visual Studio (ou Visual Studio Express para o Windows Phone), escolha Adicionar classe. A caixa de diálogo Adicionar Novo Item é aberto com o modelo de classe c# já foi escolhido.
Especifique um nome para o arquivo de classe (por exemplo, ContosoConverter.cs) e escolha Adicionar. O arquivo de classe é adicionado ao projeto e aberto para edição.
Substitua o conteúdo do arquivo com o código a seguir.
using System; using Microsoft.SharePoint.Client; // Added for ListItem. using Microsoft.SharePoint.Phone.Application; // Added for ConversionContext. using System.Text.RegularExpressions; // Specify a namespace appropriate for your particular project. namespace ContosoSPListApp { public static class ContosoConverter { static Regex StandardNumberFormat = new Regex(@"^\\(?([0-9]{3})\\)?[-. ]?([0-9]{3})[-. ]?([0-9]{4})$", RegexOptions.Compiled); public static object GetConvertedTextFieldValue(string fieldName, ListItem item, ConversionContext context) { if (item == null) return null; if (fieldName == "Contact_x0020_Number") { string contactNumber = string.Empty; try { contactNumber = item.FieldValuesAsText[fieldName]; } catch (PropertyOrFieldNotInitializedException) { object itemValue = item[fieldName]; if (itemValue != null) { contactNumber = itemValue.ToString(); } } // Regularize the formatting of phone number for display in UI. if (StandardNumberFormat.IsMatch(contactNumber)) { // Phone number is in an acceptable format, but formatting it // in a specific way for visual consistency in the UI. string properlyFormattedNumber = StandardNumberFormat.Replace(contactNumber, "($1) $2-$3"); return properlyFormattedNumber; } else { // Return a representation of the data adorned in such a way // as to designate its invalidity. if (!contactNumber.Contains("Invalid Number")) { return string.Format("Invalid Number: {0}", contactNumber); } else { // Assume data is already adorned with an invalidity designation. return contactNumber; } } } else { return item[fieldName]; } } public static void SetConvertedTextFieldValue(string fieldName, object fieldValue, ListItem item, ConversionContext context) { if (fieldValue == null) return; if (fieldName == "Contact_x0020_Number") { // Conventional formats (e.g., 555-555-5555) are acceptable, // but formatting phone numbers consistently here for storage in list on Server. string contactNumber = (string)fieldValue; if (StandardNumberFormat.IsMatch(contactNumber)) { string properlyFormattedNumber = StandardNumberFormat.Replace (contactNumber, "($1) $2-$3"); item[fieldName] = properlyFormattedNumber; } else { if (!contactNumber.Contains("Invalid Number")) { item[fieldName] = string.Format("Invalid Number: {0}", contactNumber); } else { // Assume data is already adorned with an invalidity designation. item[fieldName] = contactNumber; } } } else { // Allow values for other Text fields to be passed on to list without modification. item[fieldName] = fieldValue; } } } }Salve o arquivo.
A função GetConvertedTextFieldValue aqui determina se os dados de um campo devem conter um número de telefone (chamado "Number Contact", neste exemplo) de cadeia de caracteres é formatada de acordo com as convenções de padrão para números de telefone (América do Norte) e, em caso afirmativo, converte o número em um formato específico para exibição, "XXX-XXXX (XXX)". Se os dados não estiver formatados como um número de telefone padrão, ela é prefixada com um designador. Essa função na verdade não altera os dados na lista. A função SetConvertedTextFieldValue, por outro lado, prossegue na direção oposta. Verifica o valor dos dados fornecidos para um campo por um usuário para determinar se os dados fornecidos correspondem ao padrão para números de telefone padrão ou não. Nesse caso, o valor fornecido é convertido em um formato específico a ser salvo à lista no servidor. Se o valor fornecido não estiver em um formato padrão, o valor é prefixado com um designador e que o valor de prefixo é então salvas no servidor.
Agora permanece registrar essas funções de conversão de dados com a classe do Conversor para uso nos formulários editar e em novo. Você pode registrar os conversores em vários lugares. No procedimento a seguir, os conversores registrados no evento OnNavigatedTo do formulário de lista (List.xaml). O formulário de lista é criado e navegado antes que os formulários de edição e New são instanciados no aplicativo, para que os conversores registrados nesse evento no formulário List entrarão em vigor para campos de texto em todos os formulários.
Para registrar as funções de conversão de dados
No Solution Explorer para o mesmo projeto no qual você criou a classe no procedimento anterior, escolha o arquivo de List.xaml sob o nó exibições.
PressioneF7Para abrir o arquivo code-behind associado, List.xaml.cs, para edição.
Adicione a seguinte declaração de variável privada à parte superior do bloco de código que implementa a classe parcial ListForm, após a abertura no bloco de código e antes do construtor de
ListForm().private bool _isConversionRegistered;Adicione o seguinte método, RegisterTextFieldValueConverters, para o arquivo, dentro do bloco de código (delimitado abrindo e fechando chaves) que implementa a classe de ListForm parcial.
private void RegisterTextFieldValueConverters() { Converter.RegisterEditFieldValueConverter(FieldType.Text, ContosoConverter.GetConvertedTextFieldValue, ContosoConverter.SetConvertedTextFieldValue); Converter.RegisterNewFieldValueConverter(FieldType.Text, ContosoConverter.GetConvertedTextFieldValue, ContosoConverter.SetConvertedTextFieldValue); }Este método simplesmente chama os métodos de registro apropriado da classe Converter. É assumido para este código que a classe personalizada que contém as funções de obter e Definir criadas no procedimento anterior é chamada "ContosoConverter". Se você especificou um nome diferente para sua classe, altere o código aqui adequadamente.
Modifica a implementação do manipulador de eventos OnNavigatedTo no arquivo, adicionando uma verificação para o valor do sinalizador de _isConversionRegistered e uma chamada para a função RegisterTextFieldValueConverters adicionada na etapa anterior. O manipulador modificado deve ser o seguinte.
protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e) { base.OnNavigatedTo(e); App.MainViewModel.ViewDataLoaded += new EventHandler<ViewDataLoadedEventArgs>(OnViewDataLoaded); App.MainViewModel.InitializationCompleted += new EventHandler<InitializationCompletedEventArgs>(OnViewModelInitialization); // The OnNavigatedTo event can fire more than once, but the converters only need // to be registered once, so checking the conversion flag first. if (_isConversionRegistered == false) { // Register converters. RegisterTextFieldValueConverters(); _isConversionRegistered = true; } }Salve o arquivo.
Observe que as funções de conversão de dados estiver registradas para todos os campos associados a um tipo de dados Text nos formulários de edição e New. É por esse motivo que as funções de obter e Definir implementadas para a classe ContosoConverter criada no procedimento anterior incluem verificações condicionais para processar os dados para um determinado campo (chamado, neste caso, "Contact_x0020_Number"), permitindo que os dados para "passar por" para outros campos Text.
Lógica de conversão personalizado para provisionar os tipos de campo não suportado
Mesmo se você não fornecer a lógica de conversão no seu aplicativo para campos de Text, tais campos podem ainda ser exibidos e editados. Fornecendo sua própria lógica de conversão para campos que já são fornecidos com lógica de conversão padrão proporciona um maior grau de controle sobre o formato ou a estrutura dos dados aos campos se a lógica de padrão não é adequada para sua intenção de design. Para campos com certos outros tipos de dados, como os campos de Guid, lógica de conversão não for fornecida por padrão, mas se você entende o mecanismo (descrito na seção anterior) pelos quais a lógica de conversão é fornecida para campos, talvez seja razoavelmente simple fornecer sua própria lógica de conversão para oferecer suporte a tipos de campo em seu aplicativo que não são compatíveis com lógica padrão com o modelo de aplicativo para Windows Phone SharePoint lista.
Suponha que você estiver criando um aplicativo do Windows Phone com base em uma lista do SharePoint denominada identificadores de produto, que inclui um campo com um tipo de dados Guid. Para fins de exemplo de código a seguir, suponha que a lista possui um campo de produto (ou título) (do tipo Text) e um campo de identificador (do tipo Guid).
Observação
[!OBSERVAçãO] Listas do SharePoint com Guid campos devem ser criadas programaticamente ou de um modelo de lista que inclui campos de Guid.
Em um aplicativo do Windows Phone criados usando o modelo e com base nesta lista simple, os dados nos campos Guid não são exibidos por padrão. (No lugar de dados, será exibida uma mensagem semelhante ao seguinte: "Nenhum conversor para o tipo de campo 'Guid' está registrado.") O procedimento a seguir, você incluirá a lógica de conversão para oferecer suporte a campos de Guid para um aplicativo do Windows Phone. Você adicionar uma classe que contém os métodos para registrar os conversores de valor do campo para exibir os GUIDs e gerar novos valores GUID para itens de lista adicionado.
Fornecer a lógica de conversão para um tipo de campo não suportado
Em um projeto (chamado, por exemplo, SPListAppGuidConversion) criados a partir do SharePoint lista aplicativo para Windows Phone e com base na lista de identificadores de produto mencionada acima, escolha o nó que representa o projeto no Solution Explorer.
No menu projeto, escolha Adicionar classe. A caixa de diálogo Adicionar Novo Item aparece com o modelo de c# classe que já está selecionado.
Especifique GuidConversion.cs como o nome do arquivo e escolha Adicionar. O arquivo de classe é adicionado à solução e aberto para edição
Substitua o conteúdo do arquivo com o código a seguir.
using System; using Microsoft.SharePoint.Phone.Application; using Microsoft.SharePoint.Client; namespace SPListAppGuidConversion { public class GuidConversion { /// <summary> /// Registers a GET converter to prepare GUID values for display. /// </summary> static public void RegisterDisplayFieldGuidConverter() { // Register GET converter to display GUID values. Converter.RegisterDisplayFieldValueConverter(FieldType.Guid, getConvertedFieldValue: (string fieldName, ListItem item, ConversionContext context) => { string guidValue = string.Empty; try { guidValue = item.FieldValuesAsText[fieldName]; } catch (PropertyOrFieldNotInitializedException) { object itemValue = item[fieldName]; if (itemValue != null) { guidValue = itemValue.ToString(); } } if (string.IsNullOrWhiteSpace(guidValue)) { return string.Format("{{{0}}}", Guid.Empty); } else { Guid g = new Guid(); if (Guid.TryParse(guidValue, out g)) { guidValue = string.Format("{{{0}}}", g.ToString().ToUpper()); return guidValue; } else { return "Invalid Identifier (GUID)"; } } }); } /// <summary> /// Registers GET and SET converters for GUID value of new (i.e., added) list items. /// </summary> public static void RegisterNewFieldGuidConverter() { Converter.RegisterNewFieldValueConverter(FieldType.Guid, getConvertedFieldValue: (string fieldName, ListItem item, ConversionContext context) => Guid.NewGuid().ToString(), setConvertedFieldValue: (string fieldName, object fieldValue, ListItem item, ConversionContext context) => { if (fieldValue == null) { item[fieldName] = Guid.Empty.ToString(); } else { item[fieldName] = fieldValue; } }); } } }Nesta classe personalizada, o RegisterDisplayFieldValueConverter e os métodos de RegisterNewFieldValueConverter da classe Converter são chamados usando funções anônimas (definidas pelas lambda instrução) para implementar as rotinas de obter e Definir para os representantes necessários para os métodos de registro. O argumento opcional aqui etiquetas (por exemplo, "getConvertedFieldValue:") estão incluídos neste código apenas para esclarecer quais representantes são definidos.)
Essa abordagem, envolvendo expressões lambda, é uma alternativa para passar funções nomeadas como parâmetros para as funções de registro do conversor, o que foi demonstrado em um procedimento anterior descrito neste tópico (na seção Para registrar as funções de conversão de dados).
Salve o arquivo.
No Solution Explorer, escolha o arquivo de App.
PressioneF7Para abrir o arquivo code-behind associado, App.xaml.cs, para edição.
Localize a implementação do manipulador de eventos Application_Launching (que estará vazia em um novo projeto criado usando o modelo de aplicativo para Windows Phone SharePoint lista) e substituí-lo com o código a seguir.
private void Application_Launching(object sender, LaunchingEventArgs e) { // Register converters for GUID fields. Converters can be // registered just once for the app. GuidConversion.RegisterDisplayFieldGuidConverter(); GuidConversion.RegisterNewFieldGuidConverter(); }Para a lógica do conversor funcionar para novos itens de lista (ou seja gerar o GUID valores quando itens são adicionados à lista), você precisará garantir que o campo identificador do NewItemViewModel está vinculado ao novo formulário. Uma maneira de fazer isso é adicionando um controle oculto TextBlock para NewForm.xaml com uma declaração de Binding para sua propriedade Text definida para o campo identificador. Você pode adicionar o controle TextBlock para o controle de contêiner StackPanel que inclui o controle TextBox para o campo título, como na seção a seguir da marcação no arquivo NewForm.xaml.
<Grid x:Name="LayoutRoot" Background="Transparent" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:controls="clr-namespace:Microsoft.Phone.Controls; assembly=Microsoft.Phone.Controls"> <StackPanel> <ProgressBar Background="Red" x:Name="progressBar" Opacity="1" HorizontalAlignment="Center" VerticalAlignment="Top" Height="15" Width="470" IsIndeterminate="{Binding IsBusy}" Visibility="{Binding ShowIfBusy}" /> <ScrollViewer HorizontalScrollBarVisibility="Auto" Height="700"> <Grid x:Name="ContentPanel" Width="470"> <StackPanel Margin="0,5,0,5"> <StackPanel Orientation="Vertical" Margin="0,5,0,5"> <TextBlock TextWrapping="Wrap" HorizontalAlignment="Left" Style="{StaticResource PhoneTextNormalStyle}"> Title*</TextBlock> <TextBox Style="{StaticResource TextValidationTemplate}" FontSize="{StaticResource PhoneFontSizeNormal}" Width="470" HorizontalAlignment="Left" Name="txtTitle" Text="{Binding [Title], Mode=TwoWay, ValidatesOnNotifyDataErrors=True, NotifyOnValidationError=True}" TextWrapping="Wrap" /> <TextBlock Name="txtIdentifier" Text="{Binding [Identifier]}" Visibility="Collapsed"/> </StackPanel> </StackPanel> </Grid> </ScrollViewer> </StackPanel> </Grid>Salve o arquivo.
Se você inicia o projeto e implantar o aplicativo para o emulador do Windows Phone para executá-la, os dados no campo identificador são exibidos no formato de lista (List.xaml) se o campo correspondente na lista do SharePoint contiver um valor GUID. (Consulte a Figura 1.)
Figura 1. Displaying Guid fields
Em projetos com base no modelo de aplicativo para Windows Phone SharePoint lista, controles do Silverlight não podem ser adicionados a formulários e vinculados a tipos de campo que não são compatíveis com lógica de conversão padrão no modelo. Para o campo de identificadores da lista de identificadores de produto usado no procedimento anterior, você poderia adicionar marcação ao arquivo DisplayForm.xaml para definir controles adicionais para exibir valores de GUID, um controle TextBlock e um controle de TextBox em um controle StackPanel, que também é contida no Grid o controle da interface do usuário. A marcação do controle adicionado StackPanel poderia ter a seguinte aparência.
<StackPanel HorizontalAlignment="Left" Orientation="Horizontal"
Margin="0,5,0,5">
<TextBlock TextWrapping="Wrap" Width="150" HorizontalAlignment="Left"
Style="{StaticResource PhoneTextNormalStyle}">Identifier:</TextBlock>
<TextBlock Width="310" HorizontalAlignment="Left" Name="txtIdentifier"
Text="{Binding [Identifier]}" TextWrapping="Wrap" Style="
{StaticResource PhoneTextSubtleStyle}" />
</StackPanel>
Agora, o campo identificador é mostrado no formulário exibição, bem como o formulário de lista.