¿alguien a logrado correr un proyecto windows form creado con .net por defecto con mono? a mi me da un error en el autoscale de windows form y por consiguiente un nullpointer exception
Que yo sepa, Mono todavía no soporta las WinForms.
Si no soporta las winforms como diablos han hecho todas las ventanas en las aplicaciones existentes sobre Mono?
Con gtk# o wxwindows#
si te obligan a usar su entorno y sus librerias, ¿entonces lo unico que han hecho es copiar la sintaxis del c-sharp y unas pocas clases de microsoft (concretamente todas las System.* menos las System.Windows.Form)?
saludos
CitarMono 1.4
A refresh update on the Mono 1.2 release containing the missing components from the previous release and complete any under performing pieces. Updates to System.Xml, ASP.NET and Windows.Forms to match the .NET 1.2 API.
Release target: Q2/2005.
Paciencia hermano
El soporte Windows Forms de Mono funciona, pero aun le faltan algunos controles, y eliminar fallos etc.
Yo he conseguido compilar un Hello World con Mono + Windows Forms en Mac OS X, y ejecutarlo en Windows :rolleyes: . Requiere pasarle unos cuantos parámetros al compilador(mcs), pero funciona.
Por curiosidad que yo aun no lo he probado... ¿como es el look de las aplicaciones con winforms en linux? Supongo que imitara a Windows. Lo ideal seria que transformara las llamadas a gtk+ aunque supongo que es demasiado dificil al ser tan diferentes.
ZaelSiuS te importaria poner el proyecto y los parametros que le pasaste al mcs, es que me gustaria tener algo para poder probarlo, tengo mono de probarlo en varias plataformas :D
Cita de: "samsaga2"Por curiosidad que yo aun no lo he probado... ¿como es el look de las aplicaciones con winforms en linux? Supongo que imitara a Windows. Lo ideal seria que transformara las llamadas a gtk+ aunque supongo que es demasiado dificil al ser tan diferentes.
Las winforms de mono se basan en gtk, aunque creo que tal y como esta escrita la implementacion se podrian mapear sobre otras api's como wxwidgets# o qt#
Yo siento curiosidad por saber como funcionan esos wrappers que hay como por ejemplo TAO para OpenGL. Lo que no acabo de entender es cómo dicha DLL puede ser multiplataforma si dependiendo del sistema deberá atacar una librería (opengl.dll) u otra (opengl.o?). No me refiero al uso de código interpretado, CLI ni leches, sino simplemente al hecho de que la misma implementación sirva para dos sistemas cuando esta librería ataca a algo que NO es codigo interpretado (la implementación nativa de la libreria OGL).
De ser C++ pues podría pensar en algo así como "#ifdef windows" pero eso sería en tiempo de compilación y algo me dice que es en tiempo de ejecución cuando resuelve qué wrappear. Aunque ahora que pienso yo he tenido que compilar TAO para generarme las DLLs, y ahora se me plantea la duda de si al compilarlas sobre linux se generaría una DLL diferente (y no me refiero por las diferencias entre compiladores, sino realmente diferentes).
Todo esto porque me gustaría saber si al finalizar mi aplicación que usa OGL me bastaría meter todas las DLLs que tengo para migrarla de sistema operativo o me tocará hacer algunos pasos intermedios.
Pq los detalles de carga de dll's se encarga el S.O. o el entorno y en ambas plataformas el interfaz presentado por las dll's es identico.
Creo que lo entiendo, es el framework quien gestiona el acceso a las librerias así que el wrapper no se tiene que preocupar de ello, es coherente. Gracias.