Programate algo - Programming Blog/Blog de Programación

Versión en inglés / English version 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: 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. 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. 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.

Spanish version / Versión en Español In .NET, the Dispose Pattern... MUST be implemented if our class has references to unmanaged resources. For instance, references to C++/CLI objects which wrap native objects, native memory, etc. MUST be implemented if our class accesses limited resources, even if accessed through managed objects. For example, database connections. MUST be implemented if you wish to use RAII semantics for your class. SHOULD be implemented if your class contains big objects (a Dictionary with lots of keys, for example), and instances are created dynamically and relatively frequently. In this case, the objective is reclaiming memory as soon as possible, to avoid Out of Memory Scenarios due to memory fragmentation. Once we decide to apply the pattern to a class, there are two possibilites. First, if the class is sealed AND it doesn't reference unmanaged resources , we can just override the Dispose Method:: public sealed class A :

Versión en inglés / English version En .NET, el patrón Dispose... DEBE implementarse si nuestra clase manejada mantiene referencias a recursos no manejados. Por ejemplo, clases C++/CLI que funcionan como wrappers de objetos C++ nativos, memoria nativa, etc. DEBE implementarse si nuestra clase debe liberar recursos limitados, incluso si son accedidos a través de objetos manejados. Por ejemplo, conexiones a Bases de Datos. DEBE implementarse si se quiere implementar RAII PUEDE, y DEBERÍA ser implementado si la clase contiene objetos manejados grandes (un Dictionary con muchas claves, por ejemplo), y sus instancias son creadas dinámicamente. En ese caso, implementar IDisposable nos permite usar la instrucción using de C# para acceder con semántica RAII. De esta forma, no sólo se libera la memoria lo antes posible, sino que si ocurre una excepción, la memoria es liberada en el acto. Una vez que decidimos aplicar el pat

Spanish version / Versión en Español This error is of the "unresolved external symbol" kind, which can lead us to believe that we misdeclared or forgot to define some function, or we are not linking correctly to some dll. In my particular case, I was using the MFC CString class, which is actually a template class. I was not aware of that. Moreover, its definition changes according to some project options: ATL usage, Character Set, and there might be more. More concretely, I was calling a function from another dll, which had Multi-Byte (ANSI) as its character set, and the calling dll was configured to use Unicode. Therefore, the CString definitions did not match and the error ensued. So the solution consisted of going to the called dll's project Properties, General section, Project Defaults subsection, Character Set combo box, and setting it to Unicode.

Versión en inglés / English version Este error se manifiesta como "unresolved external symbol", lo cual nos puede llevar a pensar que nos falta definir una función, o que no linkeamos correctamente. Lo que ocurría en mi caso era que estaba usando la clase CString, que es un template, cosa que no sabía. Aún más: su definición depende de si se usa ATL o no, o si el proyecto está configurado para usar caracteres Unicode o ANSI. En mi caso particular, estaba llamando a un método de otra dll, configurada con ANSI, desde una configurada con Unicode. Por ende, las definiciones de CString no coincidían, para el compilador eran dos tipos diferentes. Por lo tanto, la solución fue ir a mi proyecto desde el Solution Explorer del Visual Studio, click derecho->Properties->General->Project Defaults->Character Set, y en ese combo box, setear Unicode.