Recursos e Localização
Ted Pattison
Conteúdo
Embutindo Recursos
Arquivos de Recursos
Trabalhando com Arquivos de Recursos
Arquivos de Recursos no Visual Studio 2005
Arquivo de Recursos em Nível de Projeto
Configurações e Localização da Cultura
Assemblys Satélite
Carregando Recursos Localizados
Localizando Configurações de Form e de Control
Conclusão
Há duas maneiras de utilizarmos recursos tais como strings, imagens e arquivos texto em aplicações Microsoft® .NET Framework: podemos embuti-las diretamente na aplicação ou carregá-las de um arquivo externo. Quando escolhemos carregá-las de uma fonte externa em lugar de um recurso embutido, devemos distribuir os arquivos junto com o assembly. Devemos também verificar que o código da aplicação poderá determinar o caminho correto e carregar os arquivos de recursos em tempo de execução. Esta abordagem causará problemas caso o .exe estiver separado dos arquivos dos quais depende.
Adotando a opção embutida e compilando os recursos necessários diretamente nos assemblys que os utilizam, tornamos a distribuição mais confiável e menos sujeita a erros. Neste artigo discutiremos a utilização de recursos, e também como e porque podemos embutir um recurso e o papel dos arquivos de recursos no .NET.
Embutindo Recursos
Vamos começar com um exemplo simples para ver como embutir os recursos. Suponhamos que desejemos embutir na aplicação, uma imagem gráfica chamada LitwareLogo.png. Começamos adicionando o arquivo ao projeto Visual Studio®. A seguir, na folha de propriedades do arquivo, configuramos a Build Action para Embedded Resource, como mostrado na Figura 1. Fazendo assim, instruimos o Visual Studio a embutir o arquivo na imagem física do arquivo .exe do assembly de saída.
Figura 1- Configuração da Build Action
Uma vez que embutimos um arquivo como um recurso, veremos como acessá-lo em tempo de execução. Vamos examinar o seguinte fragmento de código, que obtém uma referência para o objeto assembly atual e a seguir chama o método GetManifestResourceStream para ganhar acesso stream ao arquivo de recursos embutido. Este código supõe que importamos os namespaces System.Reflection e System.IO:
' * * * obter o objeto assembly atual.
Dim asm As Assembly = Assembly.GetExecutingAssembly()
' * * * carregar no stream o recurso embutido
Dim ResourceName As String = "LitwareSmartClient.LitwareLogo.png"
Dim str As Stream = asm.GetManifestResourceStream(ResourceName)
' * * * converter o stream para imagem e carregá-lo em ' * * * picture box
Dim img As Image = Image.FromStream(str)
PictureBox1.Image = img
Como podemos ver, um objeto assembly expõe o método GetManifestResourceStream, que permite que passemos um nome string que identifica o recurso embutido. Notar que o nome de recursos é case-sensitive mesmo quando estivermos utilizando uma linguagem não case-sensitive como o Visual Basic®. No exemplo, o código chama o método Image.FromStream para converter o stream que contém o arquivo imagem em um objeto Image que pode ser carregado em um controle PictureBox.
Além de embutir arquivos de imagem, pode ser conveniente embutir arquivos texto que contenham XML, SQL ou JavaScript. Isto tornar nossa vida muito mais fácil, quando formos concatenar grandes fragmentos string XML, SQL ou JavaScript, utilizando o Visual Basic.
Por exemplo, digamos que a aplicação necessita grandes documentos XML, declarações SQL, ou funções JavaScript. Poderíamos mantê-los como arquivos .xml, .sql e .js independentes em um projeto Visual Studio. Com isto obtemos os benefícios da codificação colorida e da conclusão de declarações (statment completion) do Visual Studio. Podemos também tirar vantagem do IntelliSense do Visual Studio para arquivos XML. Apenas precisamos embutir estes arquivos fonte no assembly de saída e acessá-los utilizando a técnica já descrita. Por exemplo, se embutirmos um arquivo SQL e um arquivo XML na aplicação, podemos acessá-los utilizando código como o da Figura 2
Arquivos de Recursos
As técnicas até agora vistas envolvem embutir arquivos de recursos diretamente no assembly e carregá-los utilizando o método GetManifestResourceStream, fornecido pela classe Assembly. Existe, porém, outra alternativa nos arquivos de recursos do .NET, que pode tornar mais fácil a manipulação de recursos em muitos cenários. Além disto, como veremos, o Visual Studio 2005 fornece algumas facilidades quando tivermos que trabalhar com recursos e localização de aplicações.
Trabalhando com Arquivos de Recursos
No .NET, os arquivos de recursos podem ser utilizados para embutir recursos nos assemblys. Um dos benefícios importantes da utilização de arquivos de recursos, é que todos os elementos de idioma e locale específicos da aplicação ou da DLL de biblioteca de classes; tais como captions e mensagens do usuário; podem ser fatoradas do código da aplicação. Para fazermos isto, necessitarmos criar um arquivo de recursos separado para cada idioma falado que for necessário suportar. O arquivo de recursos real é um arquivo texto que contem XML com uma extensão .resx. A Figura 3 mostra um exemplo resumido dos dados XML encontrados dentro de um arquivo de recursos.
Mesmo não sendo um arquivo de recursos completo, o fragmento XML da figura nós dá uma idéia geral do que existe dentro do mesmo. Podemos compilar um arquivo de recursos em uma imagem binária, utilizando um chamado utilitário público .NET, o gerador de arquivos de recursos (resource file generator - Resgen.exe). Arquivos de recursos compilados, normalmente tem uma extensão .resources. Por exemplo, um desenvolvedor na companhia Litware, pode criar um arquivo de recursos chamado LitwareStrings.resx e compilá-lo em uma imagem binária chamada LitwareStrings.resources, executando o seguinte comando em um arquivo batch ou Command Prompt do Visual Studio 2005:
RESGEN.EXE LitwareStrings.resx LitwareStrings.resources
Depois que compilamos um arquivo texto .resx para um arquivo binário .resource, este ainda não está pronto para utilização. Teremos que compilar esta imagem binária em um assembly .NET, antes de utilizá-la em uma aplicação. Isto pode ser realizado utilizando uma outra ferramenta do .NET chamada Assembly Linker (Al.exe). Por exemplo, para compilar o LitwareStrings.resources no nosso próprio assembly da DLL, podemos rodar a seguinte instrução de linha de comando a partir de um arquivo batch ou do command prompt do Visual Studio 2005:
AL.EXE /t:library
/out:LitwareStrings.resources.dll
/link:LitwareStrings.resources
Uma vez compilado um arquivo de recursos em um .NET assembly, podemos acessar os seus recursos utilizando a classe ResourceManager definida no namespace System.Resources. O código a seguir, mostra um exemplo simples de acesso a um recurso string, utilizando o ResourceManager:
Dim asm As Assembly = Assembly.Load("LitwareStrings.resources")
Dim rm As New System.Resources.ResourceManager("LitwareStrings", asm)
Dim caption As String = rm.GetString("MainFormCaption")
O Resgen.exe pode também ser utilizado para gerar uma classe de recursos fortemente tipada, que expõe as propriedades que fornecem fácil acesso aos recursos. Por exemplo, para gerar uma classe de recursos fortemente tipada no Visual Basic, podemos adicionar o parâmetro /str e um valor "vb" à linha de comando ao chamar o Resgen.exe:
RESGEN.EXE LitwareStrings.resx LitwareStrings.resources /str:vb
Esta instrução de linha de comando gera um arquivo fonte Visual Basic chamado LitwareStrings.vb. Este arquivo fonte contem uma classe chamada LitwareStrings. Nesta classe, está contido o código que utiliza o ResourceManager para implementar as propriedades fortemente tipadas, tal como esta:
Shared ReadOnly Property MainFormCaption() As String
Get
Return ResourceManager.GetString("MainFormCaption", resourceCulture)
End Get
End Property
Esta é apenas uma explicação de alto nível a respeito de como os arquivos de recursos são compilados nos assemblys e como podem ser acessados utilizando o ResourceManager e as classes de recursos fortemente tipadas. Isto nos dá uma idéia melhor de como as diversas partes se encaixam.
Não vamos dedicar mais tempo nos detalhes de baixo nível dos arquivos de recursos, porque não precisaremos lidar com eles quando estivermos localizando aplicações e bibliotecas DLLs. Isto acontece porque nos bastidores, o Visual Studio 2005 e o Visual Basic fornecem muitas facilidades valiosas. No entanto, devemos ter em mente que podemos ter que trabalhar diretamente com o Resgen.exe, o Al.exe e alguns dos outros utilitários e classes do .NET, quando estivermos localizando projetos de desenvolvimento de grande porte.
Arquivos de recursos no Visual Studio 2005
Agora focalizaremos na utilização de arquivos de recursos em aplicações Windows Forms. A maior parte dos conceitos explicados aplicar-se-á à utilização de arquivos de recursos também em classes de bibliotecas DLL. O Visual Studio 2005 facilita o trabalho com arquivos de recursos via o editor visual. Podemos criar um novo arquivo de recursos utilizando o comando Add New Item e escolhendo o arquivo Resources, como mostrado na Figura 4.
Figura 4 - New Item Template para a Adição de Arquivos de Recursos
Uma vez adicionado um arquivo de recursos a um projeto, não teremos necessidade de trabalhar diretamente com o formato XML utilizado nos arquivos .resx. Ao invés disto, o Visual Studio fornece um projetista de recursos visual amigável que é mostrado na Figura 5. Este projetista de arquivo de recursos facilita a adição e manutenção de strings e outros tipos de recursos de arquivos gráficos e de documentos, tais como XML.
Figura 5 - Editor de Recursos do Visual Studio
Quando compilamos um projeto contendo um arquivo de recursos, o Visual Studio compila o arquivo .resx em um arquivo .resource e faz o link para a imagem física resultante da saída do assembly. Isto significa que todos os detalhes envolvidos na compilação do arquivo de recursos e em embutir a imagem no assembly de destino, são manipulados pelo Visual Studio.
O Visual Studio, faz também o build em uma classe de recursos fortemente tipada, e a expõe em projetos Visual Basic utilizando as características de namespace My, introduzidas no Visual Basic 2005 . Isto significa que a classe ResourceManager do .NET carregará os recursos e nunca teremos que programar diretamente esta classe. Por exemplo, se quisermos acessar recursos string adicionados a LitwareStrings.resx, podemos simplesmente escrever o seguinte código:
Sub Main_Load(sender As Object, e As EventArgs)
Handles MyBase.Load
Me.Text = _
My.Resources.LitwareStrings.MainFormCaption
Me.lblUserWelcome.Text = _
My.Resources.LitwareStrings.UserWelcome
End Sub
Arquivo de Recursos em Nível de Projeto
Apesar de podermos adicionar explicitamente um ou mais arquivos de recursos a um projeto do Visual Studio, isto é normalmente desnecessário, porque o Visual Studio inclui automaticamente um arquivo de recursos em nível de projeto, toda vez que criarmos um novo projeto. O arquivo de recursos em nível de projeto pode ser acessado via o diálogo Project Properties do Visual Studio.
Quando quisermos acessar recursos string ao arquivo de recursos em nível de projeto, podemos fazê-lo diretamente via a classe My.Resources:
Private Sub LoadResources()
'*** load project-levelresources
Me.Text = My.Resources.MainFormCaption
Me.lblWelcomeMessage.Text = My.Resources.UserWelcome
End Sub
Como podemos ver, acessar strings de um arquivo de recursos que utiliza uma classe de recursos fortemente tipada é consideravelmente mais fácil. Podemos ir mais adiante e fazer o mesmo tipo de acesso fortemente tipado para o arquivo de recursos, quando adicionarmos imagens gráficas e arquivos contendo código XML, SQL e JavaScript a um arquivo de recursos. Por exemplo, supondo que adicionamos um arquivo gráfico chamado LitwareLogo.png e um arquivo XML chamado Customers.xml ao arquivo de recursos em nível de projeto. Estes recursos serão embutidos automaticamente no assembly de saída do projeto e poderemos acessá-los de forma fortemente tipada utilizando o seguinte código:
Me.picLogo.Image = My.Resources.LitwareLogo
Dim xmlDoc As New Xml.XmlDocument
xmlDoc.LoadXml(My.Resources.Customers)
Podemos observar que a classe de recursos fortemente tipada, converte automaticamente o arquivo a.png em um objeto Image que pode ser diretamente carregado em um PictureBox. A classe de recursos fortemente tipada, converte também o arquivo embutido XML em um string que pode ser fàcilmente carregado em um objeto XmlDocument.
Configurações e Localização de cultura
É uma exigência normal que os projetos de software possam ser localizados, de modo que possam ser utilizados por povos falando idiomas diferentes. Por exemplo, imaginemos que estamos desenvolvendo a aplicação Litware Customer Manager com o Visual Basic e o Visual Studio 2005 e devemos escrever versões localizadas da aplicação para usuários que falam o Inglês e para os usuários que falam Francês. Felizmente, o Microsoft .NET Framework e o Visual Studio têm muitas características orientadas para a localização de aplicações e DLLs de bibliotecas de classes.
Quando iniciarmos o projeto e escrevermos o software em .NET com suporte a localização, teremos que familiarizar-nos com a classe CultureInfo definida no namespace System.Globalization. Um objeto CultureInfo registra um nome de cultura que identifica um idioma falado.
O nome de cultura para o inglês é "en" para o francês é "fr". O nome de cultura de um objeto CultureInfo pode também carregar informações adicionais que identificam uma região particular do mundo, tais como "en-US" para o Inglês dos EUA, "en-GB" para o Inglês da Inglaterra e "fr-BE" para o Francês da Bélgica. A seguir, temos um exemplo que cría e inicializa objetos CultureInfo com nomes válidos de culturas:
Dim culture1 As CultureInfo = New CultureInfo("en-US")
Dim culture2 As CultureInfo = New CultureInfo("en-GB")
Dim culture3 As CultureInfo = New CultureInfo("fr")
Dim culture4 As CultureInfo = New CultureInfo("fr-BE")
Existem, na verdade, dois objetos CultureInfo associados com a thread atual, que requerem a nossa atenção. O primeiro objeto CultureInfo listado representa a cultura atual, enquanto que o segundo objeto CultureInfo representa a cultura atual da UI. Podemos determinar os nomes de cultura para cada um destes dois objetos CultureInfo com o seguinte código:
' * * * determinar a cultura atual e a cultura atual da UI
Dim t As Thread = Thread.CurrentThread
Dim currentCulture As CultureInfo = t.CurrentCulture
Dim currentUICulture As CultureInfo = t.CurrentUICulture
' * * * exibir culturas na console
Console.WriteLine("Current Culture: " & currentCulture.Name)
Console.WriteLine("Current UI Culture: " & currentUICulture.Name)
O primeiro objeto CultureInfo; conhecido como o CurrentCulture; não é utilizado para localizar strings nas aplicações. Ao invés disto, afeta como o .NET Framework formata datas, números e a moeda corrente. Por exemplo, se modificarmos o objeto CurrentCulture alternadamente entre en-EU e en-GB, poderemos provocar efeitos colaterais estranhos tais como um único valor de moeda atual, alternando entre dólares americanos ($100. 00) e Libras Inglesas ($100. 00). Como podemos ver, comutar o formato da moeda atual em um valor da moeda atual poderá conduzir a resultados incorretos. Por este motivo, é prática comum manter a CurrentCulture estática, mesmo quando localizarmos a aplicação para utilização com idiomas diferentes.
Caso necessitemos mudar programaticamente a CurrentCulture, vale lembrar que deveremos utilizar nomes de cultura que incluam um identificador regional. Podemos utilizar um nome de cultura en-EU, en -GB ou fr-BE, no entanto, obteremos erros de tempo de execução, caso tentemos mudar o CurrentCulture de modo que tenha um nome de cultura en ou fr, porque faltarão informações regionais e a formatação se tornará demasiado ambígua.
O segundo objeto CultureInfo, é conhecido como CurrentUICulture e devemos analisá-lo com mais profundiade. Modificações realizadas no objeto CurrentUICulture associado com a thread atual, influenciam como as classes .NET Framework e ResourceManager carregam assemblys que contêm recursos embutidos. Particularmente, podem ter o efeito de carregar o conjunto dos recursos que foram localizados para a linguagem preferida pelo usuário.
Para iniciar a localização, fazemos cópias múltiplas da cópia única do arquivo de recursos para cada arquivo de recursos e para cada linguagem que desejamos suportar. Por exemplo, começamos fazendo uma cópia do arquivo de recursos amplo do projeto chamadoResources.resx. Podemos fazer isto com uma simples operação de cópia e colagem no Visual Studio Solution Explorer.
Uma vez que copiamos um arquivo de recursos tal como o Resources.resx, renomeamos a copia do arquivo de recursos adicionando o nome da cultura imediatamente antes da extensão .resx, como mostrado na Figura 6. Teremos, por exemplo, arquivos de recursos chamados Resources.fr.resx para strings locais franceses genéricos e um outro arquivo de recursos chamado Resources.fr-BE.resx para strings franceses locais específicos para a Bélgica.
Figura 6 - Arquivos de Recursos Diferentes para Cada Idioma
Assemblys Satélite
Quando compilamos o projeto com arquivos de recursos localizados; como o mostrado na Figura 6; o Visual Studio não compila todos os recursos em um único assembly de saída. Ao invés disto, compila cada um destes arquivos de recursos localizados no seu próprio assembly separado. Cada um destes assemblys localizados contem somente recursos e nenhum código. Este tipo de assembly localizado somente de recursos é conhecido como assembly satélite.
Cada satélite é associado a um assembly mestre conhecido como assembly neutro. O assembly neutro contem todo o código e carrega todos os assembly satélite necessários para recuperar os recursos localizados requeridos pelo usuário atual. No exemplo, o LitwareSmartClient.exe é o assembly neutro que contem todo o código da aplicação. Temos assim, diversos assemblys satélite associados ao LitwareSmartClient.exe. Cada um destes tem o mesmo nome de arquivo, LitwareSmartClient.resources.dll.
Quando os assemblys satélite são distribuídos junto com o assembly neutro no diretório AppBase, tem que ser distribuído de acordo com as regras do carregador de assembly .NET. Particularmente, cada assembly satélite deve ser distribuído em um diretório chamado após o seu nome de cultura local. Por exemplo, o diretório AppBase que contem o LitwareSmartClient.exe, deverá conter um subdiretório chamado fr-BE, que contém o assembly satélite local para o Francês Belga do LitwareSmartClient.resources.dll. Enquanto estas regras forem seguidas, o carregador de assembly do .NET Framework junto com o auxílio da classe ResourceManager, carregará o conjunto de recursos corretos quando necessário.
Felizmente, o Visual Studio sabe como nomear corretamente os assemblys satélite e distribuí-los com a estrutura correta de diretório esperada pelo carregador assembly do .NET. Para termos uma melhor compreensão de como isto funciona, podemos simplesmente compilar o projeto e examinar a estrutura do diretório AppBase resultante e os subdiretórios que contém os assemblys satélite.
Carregando os Recursos Localizados
Uma vez criados e editados todos os arquivos de recursos locais requeridos e compilado o projeto, é chegada a hora de concentrar-nos em como a aplicação irá carregar os conjunto correto de strings locais preferidos pelo usuário atual. Uma forma de realizarmos isto, é obter uma referência para a thread atual e atribuir um novo objeto CultureInfo criado à propriedade CurrentUICulture. Se estivermos escrevendo a aplicação no Visual Basic para o Windows Forms, podemos também utilizar o seguinte código:
My.Application.ChangeUICulture("fr-BE")
Na aplicação que acompanha este artigo, foi adicionado o suporte para que os usuários selecionem seu idioma preferido e para que as preferências sejam salvas pela aplicação quando a mesma for fechada e sejam restauradas quando for reiniciada. Embora seja possível manter estas preferências do usuário utilizando chaves do registro, o Visual Studio 2005 permite evitar o uso do registro adicionando uma configuração de aplicação que pode ser armazenada em nível de usuário. A aplicação de exemplo matem com esta finalidade, o registro de uma configuração em nível de usuário chamada UserLanguagePreference. A aplicação contém também um evento de partida da aplicação (ver Figura 7).
A aplicação de exemplo disponibiliza também para o usuário, um grupo de radio buttons para mudar de idioma. A Figura 8 mostra um fragmento de código do manipulador de eventos, que responde a uma solicitação do usuário para mudar o idioma.
Vimos até aqui, o código básico que permite ao usuário a troca de idiomas. O .NET Framework responde à chamada de My.Application.ChangeUICulture, carregando o assembly satélite correto, da próxima vez que o ResourceManager recupera strings dos recursos em nível de projeto. Depois da chamada a ChangeUICulture, a aplicação pode consultar novamente os strings de recursos em nível de aplicação e carregá-los em controles do formulário, usando exatamente o mesmo código visto anteriormente no método LoadResources personalizado:
Me.Text = My.Resources.MainFormCaption
Me.lblWelcomeMessage.Text = My.Resources.UserWelcome
Notar que o carregador assembly do .NET, tentará primeiramente encontrar um casamento exato com o idioma e a região entre o nome de cultura requisitado e o nome de cultura disponível no satélite. Caso o carregador do assembly do .NET não encontrar um casamento exato, procurará então um assembly satélite disponível com um casamento de idioma. Por exemplo, se o idioma solicitado for fr-CA para o Francês do Canadá, o .NET Framework procurará primeiramente um assembly satélite com esse idioma. Caso não encontre um assembly satélite com fr-CA, procurará então um assembly satélite com um nome de cultura fr. Caso o .NET Framework não encontre um assembly satélite com um nome de cultura fr, recorrerá então aos recursos contidos no assembly neutro, que contém um conjunto de recursos de cultura padrão. Como vimos, o .NET Framework poderá sempre apelar para os recursos de cultura padrão do assembly neutro, caso não encontre um assembly satélite mais específico.
Quando compilamos o assembly neutro, podemos marcá-lo com um atributo especial para informar ao .NET Framework que os recursos de cultura padrão são suficientes para os usuários que necessitam um idioma específico. Podemos adicionar, por exemplo, um atributo a nível de assembly ao arquivo AssemblyInfo.vb, a uma aplicação de um projeto Windows Forms, como mostrado na seguinte linha de código:
Da forma como foi utilizado, o atributo NeutralResourcesLanguage informa ao carregador assembly do .NET, que poderá utilizar os recursos de cultura padrão sempre que o usuário atual solicitar que a aplicação seja localizada para o Inglês.
Localizando Configurações de Form e de Control
Já vimos como localizar recursos string em nível de projeto. Esta técnica envolve cópia e manutenção de arquivos de recursos locais. O Visual Studio 2005 fornece algum auxílio extra quando necessitarmos localizar strings específicos para um formulário e para os controles que este contém.
Cada formulário tem uma propriedade Localizable que pode ser configurada como true ou false. Se configurarmos esta propriedade como true, como na Figura 9, o Visual Studio 2005 criará e manterá nos bastidores, um conjunto de arquivos de recursos localizados.
Quando configuramos a propriedade Localizable para true, a configuração inicial de Language é a padrão. À medida que adicionamos valores de propriedades na folha de propriedades do formulário e aos seus controles, o Visual Studio os mantêm nos bastidores em um arquivo de recursos que é compilado no assembly neutro. Quando alteramos a propriedade Language do formulário para um idioma específico, tal como "French (Belgium)", o Visual Studio cria um novo arquivo de recursos localizado, que será compilado em um assembly satélite. Nos bastidores, as coisas funcionam exatamente como com recursos em nível de projeto. O Visual Studio apenas elimina a necessidade de trabalhar diretamente com arquivos de recursos e permite que trabalhemos com uma folha de propriedade padrão, enquanto adicionamos valores de propriedade para as propriedades Text dos controles.
Figura 9 - Propriedades Localizable
O Visual Studio terá que adicionar nos bastidores, algum código extra ao formulário para suportar a localização do mesmo. Particularmente, o Visual Studio adiciona o código para carregar os recursos localizados corretos e para atribuir seus valores às propriedades do formulário e dos seus controles. Ao invés de utilizar o ResourceManager, o código gerado pelo Visual Studio 2005 utiliza uma classe mais especializada que deriva de ComponentResourceManager chamada ResourceManager, que é definida no namespace System.ComponentModel.
Quando um formulário localizado é carregado, tudo o que for necessário para carregar os recursos localizados será feito pelo código gerado pelo Visual Studio. Particularmente, o Visual Studio fornece o código para criar uma instância do ComponentResourceManager, que carrega o conjunto de recursos apropriados e atribui os valores necessários aos controles.
Entretanto, se um formulário for carregado e o usuário trocar o idioma, deveremos fornecem algum código adicional para atualizar o formulário com os recursos do idioma solicitado. A seguir, um exemplo de código que utiliza o ComponentResourceManager para realizar este objetivo:
Dim crm As ComponentResourceManager
crm = New ComponentResourceManager(GetType(Main>))
crm.ApplyResources(cmdAddCustomer, cmdAddCustomer.Name)
crm.ApplyResources(mnuFile, mnuFile.Name)
crm.ApplyResources(mnuFileAddCustomer, mnuFileAddCustomer.Name)
Como podemos ver, podemos criar e inicializar uma instância para o ComponentResourceManager, passando as informações de tipo sobre o formulário, que neste caso é chamado Main.
A aplicação de exemplo pronta, que demonstra todas as técnicas da localização discutidas neste artigo, é mostrada na Figura 10. A aplicação suporta agora o Inglês dos EUA, o Inglês da Inglaterra e o Francês Belga. Notar também que, do momento em que há um assembly satélite localizado para fr sem nenhuma região específica, a aplicação suporta também um formulário genérico do Francês, para todos os usuários ao redor do mundo que falam o francês.
Figura 10 – Suporte a Versões Localizadas
Se no futuro quisermos adicionar suporte para outros idiomas, isto não será muito complicado. É simplesmente uma questão de criar e manter arquivos de recursos adicionais. De fato, podemos adicionar o suporte para novos idiomas, sem ter que recompilar o assembly neutro que contem todo o código da aplicação. Esta estratégia de localização de aplicações e DLLs de bibliotecas de classe, é uma das características mais valiosas do .NET Framework.
Conclusão
Este artigo abordou os fundamentos dos recursos e da localização do .NET Framework, mostrando como localizar uma aplicação Windows Forms simples. No próximo artigo do BASIC Instincts, trabalharemos com o que vimos neste artigo e avançaremos na discussão de recursos e da localização no ASP .NET 2. 0, que possui algumas características valiosas e originais para utilização de recursos e localização de aplicações.
Perguntas e comentários para o Ted em instinct@microsoft.com.
Ted Pattison é autor e instrutor e ministra treinamento através de sua companhia, Ted Pattison Group. Ted está atualmente pesquisando e escrevendo um novo livro que focaliza as tecnologias Windows SharePoint Services"V3" e Office 12 servers.
