Traduciendo un custom control de Windows Forms de VB.NET a C#

No es tan fácil como tirar el código en un traductor, copiar y pegar. Hay ciertos detalles a tener en cuenta, a saber:

  1. Una vez creado el nuevo proyecto C#, en vez de crear el .cs y el .Designer.cs a mano, es mejor hacer click derecho al proyecto->Add->User Control. De esta forma, el .cs y el .Designer.cs ya quedan vinculados.
  2. Antes de largarse a editar el .cs y el .Designer.cs, abrir el control en vista diseño. Abrir la ventana de Toolbox, agregar un control cualquiera (un Label, por ejemplo) y salvar. Esto generará el .resx del control. Hecho eso, se puede eliminar el control que habíamos agregado.
  3. Si el proyecto original usa recursos, o sea que también hay un .resx a nivel proyecto, hay que generar uno. Esto se hace yendo a las propiedades del proyecto, sección Resources. Lo único que veremos será un link que dirá "This project does not contain a default resources file. Click here to create one.". Click allí y listo.
  4. Si el proyecto original usa recursos, también será necesario implementar en Resources.Designer.cs las propiedades para accederlos. Respecto a esto, dichas propiedades se acceden en VB.NET a través de My.Resources; en C#, se hace con Properties.Resources.
  5. Replicados y vinculados todos estos archivos, todo lo que resta es copiar código traducido. En cuanto a los .resx, ni siquiera es necesario traducir porque el formato es el mismo.

Comments

  1. UnknownAugust 5, 2015 at 10:56 AM

    Para un manejo más profesional de los archivos .resx para la localización, le recomiendo que utilice https://poeditor.com/
    Es una herramienta de traducción colaborativa muy útil.

    ReplyDelete
    Replies
    1. Dario Eduardo RamosAugust 5, 2015 at 11:20 AM

      Muchas gracias por el dato Sonia, luego lo miraré y tal vez haga un post al respecto :)

      Delete

Post a Comment

Popular posts from this blog

Upgrading Lodash from 3.x to 4.x

Spanish version / Versión en Español There are many breaking changes from version 3.x to 4.x; all changes are detailed in the Lodash changelog . There is also a list of deprecated functions , with a regex you can use to detect usages in your code. However, since it is not an exhaustive list, I will list the changes I encountered when performing my own migration, to help anyone undergoing the same process. Direct renames This section includes functions in which only the name changed, i.e. the arguments and return value are the same. 3.x 4.x contains includes first head rest tail invoke invokeMap padLeft padStart padRight padEnd Direct renames if not using thisArg This section includes functions in which the only change is dropping "thisArg". If you are not using it, you can just rename. If you are using thisArg in 3.x, it can be dropped if you are using iteratee to acce...
Keep reading

C++/CLI: Trigger events from C++ native code and handle them in Managed code, Part I

Spanish version / Versión en Español Imagine we want to trigger an event from a native class which has a C++/CLI wrapper as an interface to managed code (C#, VB.NET). And let's deal with the general case in which we desire to pass extra information along with the event, and said information is not inside a CLR basic type, that is one which both native and managed C++ understand (int, float, char, and so on). In the native class, declare, just for convenience, a pointer to function type: typedef <nativeReturnType> ( __stdcall * PFOnEventCallback )( <nativeParameters> ); Still in the native class, declare a field of the type declared in 1): PFOnEventCallback m_fireEvent; In the place in the native class where we want to trigger the event: if( m_fireEvent ) m_fireEvent( <nativeParameters> ); (This suggests you to initialize m_fireEvent to 0, or NULL if you prefer) Now we need a setter for m_...
Keep reading