Duda y problema Tamaños ResEdit

[jmartial]

Hola,

Tengo un problema diseñando con ResEdit y no he encontrado que explicación tiene. El tema es el siguiente:

¿ Como diseño un DIALOGO de 800 x 600 pixels por ejemplo ?

Los tamaños que muestra abajo a la derecha no coinciden con pixeles, y además si cambio el tamaño del FONT los números son iguales, pero
el diálogo cambia de tamaño en pantalla.

¿Alguien sabe como diseñar en pixeles? ¿Hay alguna información de como se convierte de unidades de diálogos a pixeles?

Otra cuestión es que ResEdit tiene diálogos estilos DIALOG y DIALOGEX, ¿Cual hay que usar y que diferencia existen entre ellos?

Gracias,

[cnavarro]

Joaquin, puedes consultar la funcion GetDialogBaseUnits(), quizas te ayude

[jmartial]

Gracias Cristobal,

Ya lo conocía, pero anoche estuve repasando la teoría. El problema es que no puedo diseñar los recursos en pixeles.

Mi pregunta es si es posible diseñar los recursos en pixeles, porque con las resoluciones de hoy en día, hay que partir de unos
diseños en píxeles de referencia y para una resolución mínima de pantalla, y a partir de ahí hacer un zoom para adaptarse a resoluciones
mayores.

[Antonio Linares]

Joaquín,

Las cajas de diálogo de Windows estan diseñadas para usar "unidades" (asi le llaman ellos) y no pixeles.

Si necesitas un tamaño exacto en pixeles desde la claúsula ON INIT establece el tamaño deseado con oDlg:SetSize( nWidth, nHeight ) ó simplemente oDlg:nWidth = ... y oDlg:nHeight = ...

[jmartial]

Sí Antonio,

Eso sé hacerlo, pero tendría que hacer eso con los fonts usados y resto de controles.

Es un lío diseñar con resedit "A ojo" y luego querer que ocupe 480x325 pixeles por ejemplo.

Por eso era lo de Diseñar en píxeles.

Creo que algún día habría que desarrollar un editor de pantallas con controles en FW, y que genere el código en un fichero
que luego añadieramos como un include. Además se conseguiría multiplataforma, no depender de un editor de recursos
de terceros, que sobre todo hay que numerar y acordarse de todos los ID´s.
Creo que se aceleraría muchísimo la creación de aplicaciones.

Bueno, es sólo una opinión para mejorar esta estupenda herramienta, FWH.

[hmpaquito]

Display.prg
viewtopic.php?f=6&t=29291&hilit=resolucion&start=15#p165494

[Antonio Linares]

Joaquín,

Hay un editor de recursos en desarrollo para FiveWin, está en la carpeta samples\re.prg

A ver si tengo tiempo y le doy un empujón y lo termino...

[karinha]

Joaquín,

Hay un editor de recursos en desarrollo para FiveWin, está en la carpeta samples\re.prg

A ver si tengo tiempo y le doy un empujón y lo termino...

Master, porfa és posible mantener el estilo del Borland Resources Workshop?

Me gusta mucho el Workshop.exe, No gusto del Pellesc.exe. jejejejejejeje - kkkkkkkkkkkkkkkkkkk.

Esta noticia llega en muy buen momento.

Saludos.

[jmartial]

Antonio,

¿ Por qué no lo pones en bitbucket.org gestionas tú el proyecto, explicando que pautas seguir y entre los que quieran lo terminamos y convertimos
en el editor de recursos más potente y fácil para FWH?

Sería Multiplataforma y podría tener exportación a .RC para compatibilidad.

Mi idea sería empezar por algo fácil con controles básicos y un custom para los demás, y que genere código en un fichero include sin Comandos, sólo
con WITH OBJECT definiendo valores a los DATAS.

[Antonio Linares]

João,

Ahora estoy centrado en la implementación de unicode para FWH 14.09 que no lo vamos a poder terminar y lo publicaremos tal cual está para que así los usuarios interesados en soporte de unicode puedan ayudarme

Una vez completado el soporte de unicode, no tengo inconveniente en seguir con ese editor de recursos. De hecho el código que publiqué hace poco que generaba PRG a partir de los RCs está parcialmente implementado en re.prg, y de paso lo suyo seria renombrarlo como FiveRes.prg

No hay problema en simular la apariencia del resources workshop

[Antonio Linares]

Joaquín,

Está todo el código fuente en samples\re.prg

Como le he dicho a João, yo propongo renombrarlo como FiveRes.prg

Y tampoco habría problema en alojarlo en bitbucket y asi hacer un desarrollo conjunto. Como prefiera la mayoria

[jmartial]

Antonio,

Si lo planteas así como easyreport, yo me apuntaría con el tiempo que me quede disponible. Si logramos juntarnos unos cuantos interesados, creo
que en poco tiempo tendríamos algo usable y a la larga acortaríamos bastante el tiempo dedicado a lo visual en nuestras aplicaciones.

En este tiempo, he gastado más de un 40-50% del tiempo en recompilar contínuamente para ver como va quedando la pantalla, aparte de los fallos
de no encuentro el ID y volverme loco para buscarlo. Creo que es mucho tiempo perdido.