sugerencia BTNBMP look 2010

[lucasdebeltran]

Hola,

Por favor, implementar el estilo 2010, añadiendo la cláusula 2010, pues el 2007 ya está algo desfasado.

Gracias.

[lucasdebeltran]

Hola,

¿Algún comentario por parte de Fivetech?.

Gracias.

[lucasdebeltran]

up

[Daniel Garcia-Gil]

Lucas

como seria ese look? tienes una imagen que nos muestre como seria?
puedes crear un ejemplo que tenga los colores que dices y ver si los podemos añadir como parte del default

[lucasdebeltran]

Daniel,

Muchas gracias por responder.

Pues en lugar del azul del look 2007 debe ser como los botones de la Ribbon con la cláusula 2010.

[Daniel Garcia-Gil]

Lucas

Los botones ribbon (clase TRBTN) solo se pintan diferentes cuando se usa la clausula 2010 en la ribbonbar, de forma nativa no tienen la clausula 2010, de hecho el comando ADD BUTTON para agregar el boton al grupo tampoco tiene la clausula 2010

la clausula 2007 de la clase BTNBMP es para poder usar colores degragados en los botones, esos colores son totalmente configurables desde nuestros PRGs, agregar una clausula 2010 seria hacer exactamente los mismo q la clausula 2007 solo que con colores diferentes, lo que solo nos traeria un simple esfuerzo de agregar un par de lineas de codigo a nuestros PRG para tener el look deseado a nuestra conveniencia

[lucasdebeltran]

Daniel,

Creo que es bastante factible que la propia clase BTNBMP soporte ese estilo, al fin y al cabo es cortar y pegar el código de 2007 cambiando los colores a 2010.

Parece que desde Fivetech no se presta demasiada atención al interface gráfico, que es lo que vende una aplicación. Y tener botones en 2012 con look 2007 no es muy avanzado .

[Daniel Garcia-Gil]

Lucas

Lamento no haberme explicado claramente, pues por tu comentario difiero totalmente de lo que que expresas

Parece que desde Fivetech no se presta demasiada atención al interface gráfico

justamente por estar pendientes de eso es que funciona de forma parametrizable para no restringir al programador a usar colores preestablecidos, hasta el punto que el usuario final pueda cambiar los colores de los botones que usa si lo desea...

la clausula 2007 solo abre la posibilidad de usar degradados, los valores por default son azules, pero facilmente configurables
al agregar la clausula 2010 a la btnbmp solo se cambiarian las datas que manejan los colores, ahora imagina si windows determina este año sacar un look nuevo? entonces tambien habria que agregar la clausula 2012??, me parece totalmente infucnional hacer validaciuones innecesarias a nivel de clase solo para cambiar un color, cuando tenemos pleno control del objeto, en nuestros PRGs solo involucra una linea de codigo adicional y q aparte no nos limita a usar los colores que queramos..

el hecho que no estes de acuerdo en la forma como esta diseñado un control no significa que "Fivetech no se presta demasiada atención al interface gráfico", puedo nombrarte otras clases pensando exactamente en eso, que no son nativas de windows, y que se han diseñado para ofrecer una mejor interfaz grafica y manipulacion de datos, como esta xbrowse, folderex, meterex, controles ribbon(ribbonbar, rbbtn, rbgroup), buttonbar, tselex, explorerlist, vistamenu, etc...

te dejo un ejemplo funcional de como hacer tu propio skin usando la clausula GRADIENT sin necesidad de cambiar la clase

Code: Select all | Expand

#include "FiveWin.ch"

static oWnd
    
//----------------------------------------------------------------//

function Main()

   local oBtn,oFont
   local cVer := FWVERSION
   local bGrad := { | lInvert | If( ! lInvert, ;
                  { { 1, nRGB( 255, 255, 255 ), nRGB( 230, 234, 239 ) } }, ;
                  { { 1/3, nRGB( 255, 253, 222 ), nRGB( 255, 231, 151 ) }, ;
                    { 2/3, nRGB( 255, 215,  84 ), nRGB( 255, 233, 162 ) }  ;
                  } ) }
   
   DEFINE FONT  oFont  NAME "MS SANS SERIF"  SIZE 0,-12

   DEFINE dialog oWnd TITLE "Rounded Buttons in " + cVer size 500, 300 PIXEL
   
    @ 5, 10 BTNBMP oBtn OF oWnd  ;
       SIZE 60, 70 ;
       PROMPT cVer 2007 ;                
       FONT oFont CENTER;
       ACTION MsgInfo("Hello") ;
       GRADIENT bGrad

    @ 10, 75 BTNBMP oBtn OF oWnd  ;
        SIZE 60, 60 ;
        PROMPT "&" + cVer 2007 ;                
        FONT oFont CENTER;
        ACTION MsgInfo( "Yes" ) ;
       GRADIENT bGrad

    @ 70, 165 BTNBMP oBtn OF oWnd  ;
        SIZE 80, 60 ;
        PROMPT cVer + CRLF + "FIVEWIN" 2007 ;                
        FONT oFont CENTER ;
        ACTION MsgInfo("Hello") ;
       GRADIENT bGrad
   
                      
   ACTIVATE DIALOG oWnd CENTER

return nil

 

[lucasdebeltran]

Daniel,

Quizás yo debo de ser muy tonto. Si lo que tu me dices es cierto, entonces sobra el estilo 2007.

En todo caso, creo que es mucho más fácil definir un botón con la cláusula 2010 que montar todo ese tinglado que me acabas de indicar muy amablemente.

Y en la clase únicamente hay que tocar:

Code: Select all | Expand

   if l2007
      DEFAULT ::bClrGrad := { | lInvert | If( lInvert, ;
         { { 1/3, nRGB( 255, 253, 222 ), nRGB( 255, 231, 151 ) }, ;
           { 2/3, nRGB( 255, 215,  84 ), nRGB( 255, 233, 162 ) }  ;
         }, ;
         { { 1/2, nRGB( 219, 230, 244 ), nRGB( 207-50, 221-25, 255 ) }, ;
           { 1/2, nRGB( 201-50, 217-25, 255 ), nRGB( 231, 242, 255 ) }  ;
         } ) }
   endif

Añadiendo l2010 con los nRGBs que no se exactamente cuales son, pero vamos, sería cuestión de ir probando.


Además, curiosamente veo que en brnbmp.prg ya se prevé en parte el estilo 2010, pues hay comprobaciones del mismo !!!.


Algo me debo perder lo siento. Vamos, que si Fivetech no añade una cláusula 2010 lo puedo hacer yo naturalmente en el prg, ahora bien, en cada update tengo que estar modificando los fuentes de las clases. Y resulta que ni FW 11.12 ni 12.01 son utilizables pues tienen bugs reportados ampliamente y no resueltos. Luego son unas cuantas modificaciones que no me paga el cliente!!!.

[Daniel Garcia-Gil]

no tienes porque modificar la clase...

te muestro nuevamente el ejemplo, te recalco esta parte sin necesidad de cambiar la clase

si facilmente puedes escribir 2010 y en vez de cambiar el 2007 por el 2010, puedes agregar esta linea GRADIENT bGrad, amigo es muy simple y no tocas la clase y puedes hasta ofrecer un modulo de configuracion de colores en tu sistema, lo que propones es innesesario (a mi punto de vista)

te dejo un ejemplo funcional de como hacer tu propio skin usando la clausula GRADIENT sin necesidad de cambiar la clase

CODE: SELECT ALL  COLLAPSE VIEW

#include "FiveWin.ch"

static oWnd
   
//----------------------------------------------------------------//

function Main()

   local oBtn,oFont
   local cVer := FWVERSION
   local bGrad := { | lInvert | If( ! lInvert, ;
                  { { 1, nRGB( 255, 255, 255 ), nRGB( 230, 234, 239 ) } }, ;
                  { { 1/3, nRGB( 255, 253, 222 ), nRGB( 255, 231, 151 ) }, ;
                    { 2/3, nRGB( 255, 215,  84 ), nRGB( 255, 233, 162 ) }  ;
                  } ) }
   
   DEFINE FONT  oFont  NAME "MS SANS SERIF"  SIZE 0,-12

   DEFINE dialog oWnd TITLE "Rounded Buttons in " + cVer size 500, 300 PIXEL
   
    @ 5, 10 BTNBMP oBtn OF oWnd  ;
       SIZE 60, 70 ;
       PROMPT cVer 2007 ;                
       FONT oFont CENTER;
       ACTION MsgInfo("Hello") ;
       GRADIENT bGrad

    @ 10, 75 BTNBMP oBtn OF oWnd  ;
        SIZE 60, 60 ;
        PROMPT "&" + cVer 2007 ;                
        FONT oFont CENTER;
        ACTION MsgInfo( "Yes" ) ;
       GRADIENT bGrad

    @ 70, 165 BTNBMP oBtn OF oWnd  ;
        SIZE 80, 60 ;
        PROMPT cVer + CRLF + "FIVEWIN" 2007 ;                
        FONT oFont CENTER ;
        ACTION MsgInfo("Hello") ;
       GRADIENT bGrad
   
                     
   ACTIVATE DIALOG oWnd CENTER

return nil

 

nota adicional: la clausula GRADIENT se agrego exactamente para evitar crear "estilos"

[Antonio Linares]

Lucas,

Y resulta que ni FW 11.12 ni 12.01 son utilizables pues tienen bugs reportados ampliamente y no resueltos

Puedes indicar cuales son esos bugs ? FWH 12.01 funciona realmente bien en todas nuestras pruebas.

Antes de hacer una afirmación asi, te ruego que medites un poco lo que dices...

[lucasdebeltran]

Antonio,

viewtopic.php?f=3&t=23395

viewtopic.php?f=3&t=23392

viewtopic.php?f=3&t=23389

viewtopic.php?f=3&t=23387

viewtopic.php?f=3&t=23358

viewtopic.php?f=3&t=23336

viewtopic.php?f=3&t=23316


En todo caso, muchas gracias por vuestra atención y excelente soporte. Siempre todos los inconvenientes se solucionan de forma rápida y eficaz, cosa que no pasa con todos los productos.

[Antonio Linares]

Lucas,

Todos esos temas que comentas estan tratados, contestados y con soluciones propuestas. Son pequeños detalles, no bugs que no permitan usar un producto.

De ahi a decir que la versión 12.01 no es utilizable hay un abismo.

Por favor, un poco de cordura, porque lo que se dice aqui lo lee mucha gente y decir algo asi es hacernos daños a nosotros mismos innecesariamente.

[carlos vargas]

muchos de los problemas con group, vienen de la forma como ordenamos los controles en un dialogo,
normalmente nosotros los programadores estamos constantemente insertando controles aqui, alla, aca.
y en determinado momento el control se pinta antes del group, luego cuando se pinta el group este oculta los controles que estan por debajo
del group, yo he experimentado este problema, y tengo que recurrir al ordenamiento y numeracion correcta de los items.

si se que cuando el dialogo esta trasparente dan problemas algunas cosas, pero me falta encontrar la situacion correcta para poner un ejemplo
facilmente compilable por AL o D y que ellos ubiquen el problema.

muchos de los problemas reportados no pueden ser facilmente rasteables por fivetech de ahi que ellos pidan que en lo posible
se cree un prg que muestre el error, pero son pocos los que reportan problemas en fwh y que se tomen el tiempo para crear un ejemplo que
reprodusca la falla.

yo en la medida de lo posible, cuando encuentro un problema, creo un ejemplo que lo contenga, y ahora ya primero trato de corregirlo
por mi mismo, ya cuando no puedo o llego a un nivel que no tengo, solicito ayuda a los gurus. esto ha provocado que de aca a un tiempo sepa un poco mas que antes. , claro yo soy programador por hobby mas que todo y me puedo dar ese lujo de estar contantemente tratando de aprender, se que otros programadores por motivos de trabajo (tiempos de entrega, etc) no pueden darse ese lujo. pero corremos con el riegos de estancarnos si no nos damos tiempo para profundizar en las herramientas que usamos. (hay que conocer el compilador y hasta donde llega su poder, y de fwh como libreria gui)

eso que tu pides (efecto 2010 en btnbmp) lo puedes hacer ya sea alterando la clase como tu mismo piensas, o como te sugirio Daniel mediante parametros que la misma clase tiene, o mi via que es usar los methodos extendidos de xharbour, ahora harbour los soporta tambien con la lib xhb.lib, los cuales permiten alterar las datas y methods de una clase particular ya sea de fwh o cualqueir otra, sin afectar el codigo original. aca pongo un ejemplo.

Code: Select all | Expand

/*procedimiento para reemplazar methodos o agregar nuevos a clases de fwh*/
PROCEDURE OverrideAndExtend()

   EXTEND CLASS TFOLDER    WITH METHOD RefreshPages
   EXTEND CLASS TFOLDER    WITH METHOD GoFirstControl

   EXTEND CLASS TDIALOG    WITH METHOD RefreshDialog
   EXTEND CLASS TDIALOG    WITH METHOD MySetFocus
   EXTEND CLASS TDIALOG    WITH METHOD MyCountControl

   EXTEND CLASS TCONTROL   WITH METHOD MyDisable

   EXTEND CLASS TXBROWSE   WITH METHOD MyConfig
   EXTEND CLASS TXBROWSE   WITH METHOD SetMyBmpSort

   EXTEND CLASS TPRINTER   WITH METHOD Cm2PixX
   EXTEND CLASS TPRINTER   WITH METHOD Cm2PixY
   EXTEND CLASS TPRINTER   WITH METHOD SayText
   EXTEND CLASS TPRINTER   WITH DATA   nPxL
   EXTEND CLASS TPRINTER   WITH DATA   nPxC

   OVERRIDE METHOD GetDlgCode IN CLASS TButton WITH KGetDlgCode

RETURN
...

FUNCTION KGetDlgCode( nLastKey )
   LOCAL Self := HB_QSelf()

   ::oWnd:nLastKey := nLastKey

   DO CASE
   CASE ::oWnd:oWnd != NIL .and. ( ::oWnd:oWnd:IsKindOf( "TFOLDER"   ) .or. ::oWnd:oWnd:IsKindOf( "TFOLDEREX" )      )
      RETURN DLGC_WANTALLKEYS
   CASE nLastKey == VK_ESCAPE .and. ::oWnd:oWnd != NIL .and. ( ::oWnd:oWnd:IsKindOf( "TWINDOW"   ) .and. ::oWnd:IsKindOf( "TDIALOG" ) )
      RETURN DLGC_WANTALLKEYS
   ENDCASE

RETURN NIL

/*-------------------------------------------------------------------------------------------------*/
/*funcion nueva para method de tget*/
FUNCTION MyDisable( aNameCtrl )
   LOCAL Self := HB_QSelf()

   IF ( ::ClassName() IN aNameCtrl )
      ::bWhen := NIL
      ::Disable()
   ENDIF

RETURN NIL

FUNCTION SetMyBmpSort()
   LOCAL Self := HB_QSelf()
   LOCAL oBmp, hBmp

   ::aSortBmp := {}

   DEFINE BITMAP oBmp NAME "BMS_ARROWDOWN"
   hBmp  := oBmp:hBitmap
   AAdd( ::aSortBmp, { hBmp, 0, nBmpWidth( hBmp ), nBmpHeight( hBmp ), NIL, FALSE } )

   DEFINE BITMAP oBmp NAME "BMS_ARROWUP"
   hBmp  := oBmp:hBitmap
   AAdd( ::aSortBmp, { hBmp, 0, nBmpWidth( hBmp ), nBmpHeight( hBmp ), NIL, FALSE } )

RETURN NIL
...
 

yo soy de los que piensa, que en fwh por estar poniendo nuevos aspectos y corrigiendo estas florituras (trasparencias/gradients/skins), no se optimiza su timpo en efocarse en aspectos basicos del core (saltos de focos) que a estas alturas deberia estar al 100%, pero lamentablemente todos sabemos que lo que muestres en pantalla influye mucho en el cliente, y a la mayoria de los clientes no le gusta aspectos espartanos.

pero aca estamos, este es el barco y todos debemos apoyarnos para que llegue a buen puerto.

salu2

[lucasdebeltran]

Reitero nuevamente el agradecimiento al equipo de Fivetech, especialmente a Daniel por su siempre tan pronta y eficaz ayuda.