La nueva apariencia de EasyReport

[lucasdebeltran]

Hola,

Yo lo dejaría por favor, porque al usuario hay que caparle ciertas opciones, para que no descalabre todo.

[mastintin]

Hola,

Yo lo dejaría por favor, porque al usuario hay que caparle ciertas opciones, para que no descalabre todo.

Ok. entonces paso a deshabilitar creación tambien en la barra ....
Gracias por tu valiosa opinion
--------------------- edito --------------------------
No entiendo muy bien el proceso ...

Cuando encendemos el programa las opciones de nuevo tienen que desaparecer .... luego ¿ para poder crear un reporte nuevo primero tenemos que abrir uno que tenga habilitado ser developer ? .
no entiendo cual debe ser el comportamiento .
Lucas por favor cuentanos algo ....

[cnavarro]

Manuel, deberíamos pasarla a DATA, como estás haciendo, pero iniciándola siempre con el valor para que la aplicación se comporte con el máximo nivel (es decir, entiendo que developer), para si alguno quiere usarlo en sus aplicaciones y limitar la creacion de reportes no tenga que cambiarlo.
Pero, si te produce algún problema, la quitamos.

[cnavarro]

Manuel, he implementado lo siguiente (además de dejar el código más claro, según mi punto de vista)
En la funcion ClickListTree( oTree ) he implementado la posibilidad de editar las areas o los items con dobleclick sobre el nombre, lo que nos daria la posibilidad de eliminar el item ( Area Properties o Item Properties ).
Para no "liar" a los compañeros que prefieran seguir usando el modo anterior, he creado una DATA que nos permite seleccionar el comportamiento del programa
Antes de eliminar el item ( Area Properties o Item Properties ), me gustaria saber tu opinion.
Para probarlo, en la linea 4290 de EReport.Prg, cambia

Code: Select all

  ::lDClkProperties   := .F.     // Comportamiento actual
 

por

Code: Select all

  ::lDClkProperties   := .T.    // Permite acceder a las propiedades con doble click
 

[mastintin]

Magnífico ... Cristobla muy bueno , era una cosa que mi mente pedía a gritos ,esto va a dejar los treeview mucho mas simples.
Yo este comportamiento lo pondría por defecto e incluso lo vincularía con el uso del antiguo formato , pues no deberiamos tener tantas variantes ...
Me explico ...
1.-Si tienes un fwh antiguo , comportamiento total a la antigua , sin los paneles .
2.-Si tienes un fwh moderno , tu decides si quieres el antiguo formato sin paneles o con paneles.
Si escoges el formato antiguo , nos vamos al punto 1.
Si escoges formato moderno ( con paneles ) tienes este nuevo comportamiento del treeview si o si .
Al que no le venga bien dado que dispone del código que lo modifique a su gusto .
¿ Como lo ves ?

[cnavarro]

Manuel, no tengo problema en implementar las variantes que comentas, pero creo que deberíamos implementar esa opcion en la configuracion del programa (ahora que el lReexec funciona de lujo ) y no tener que modificar el codigo
O, Sería muy complicado añadir al fichero de configuracion esa opcion?

Por otra parte, hoy, en cuanto tenga un ratillo, me pondré a "eliminar" los items de propiedades cuando se elije esa opcion y dejarlo listo

[mastintin]

Manuel, no tengo problema en implementar las variantes que comentas, pero creo que deberíamos implementar esa opcion en la configuracion del programa (ahora que el lReexec funciona de lujo ) y no tener que modificar el codigo
O, Sería muy complicado añadir al fichero de configuracion esa opcion?

Efectivamente , en el archivo de configuración del programa ponemos un nuevo valor donde podamos decidir como lo queremos .
Lo ponemos todo dependiendo de una data de TEreport por ejemplo lPanels , si esto se activa a no , formato viejo , si se activa a si .. comprobamos la version del fwh y decidimos el valor final de lPanels .... despues todo depende de esa data .
Miro la parte del ini para colocarlo todo .

[cnavarro]

Ya miro el repositorio cuando lo tengas implementado y me pongo a ello

[mastintin]

Creo que hasta ya lo tenemos , mira la data oEr:lShowPanel , ya esta en el ini ...

.................. editado .......................

Ahora por un lado determinamos con lshowpanel si enseña o no los paneles , y el fwh 10.08 para el folder o folderex .
Yo creo que tenemos que seguir 2 lineas solo , antiguo y viejo ,y esto nos eliminará limitaciones de desarrollo. lo viejo se queda como está y lo nuevo evoluciona.
¿ en que punto distinguimos en 10.08 y eliminamos la parte de folders ? . Y creo que 4 años es un tiempo "razonable" . ¿ en otro punto ? ....

[cnavarro]

Creo que hasta ya lo tenemos , mira la data oEr:lShowPanel , ya esta en el ini ...

.................. editado .......................

Ahora por un lado determinamos con lshowpanel si enseña o no los paneles , y el fwh 10.08 para el folder o folderex .
Yo creo que tenemos que seguir 2 lineas solo , antiguo y viejo ,y esto nos eliminará limitaciones de desarrollo. lo viejo se queda como está y lo nuevo evoluciona.
¿ en que punto distinguimos en 10.08 y eliminamos la parte de folders ? . Y creo que 4 años es un tiempo "razonable" . ¿ en otro punto ? ....

Manuel, hoy he tenido un dia complicadillo
Acabo de echarle un vistazo a todos _ que has hecho ( te ha cundido eh! )
Voy a ver lo que puedo avanzar

Quizás Antonio nos puede sacar de dudas de la version a partir de la que podemos realizar esa consideracion de "antiguo" o "nuevo"

A mi particularmente me parece bien lo que propones, aunque quizás sea prematuro decidir eso sin saber lo que el resto del desarrollo en otras facetas nos podría provocar, y que, nos condicionaría a la hora de desarrollar paralelamente dos versiones porque quizás, lo que menos puede provocar incompatibilidades en el tema de las versiones sea el aspecto estético.
Pero como te he dicho, de momento, tomamos esa fecha como punto de partida.

-------------------- EDITADO ----------------------------
Quizás habria que cambiar en el dialogo de Preferences (recursos)
- Show Tree Panel

por

- Show Panels

[mastintin]

Ok. De momento mantenemos las cosas como están en cuanto a versiones.
Hoy cuando estaba pasando Variable publicas a Static o Data me encontré con una muy concreta ....oCurdlg
Se usa en todos los dialogos de propiedades, quizás en su momento pretendiendo crear un dialogo no modal para todas las pantallas y que se refrescase dinámicamente según el objeto seleccionado .Como el desarrollo no estaba completo yo pasé los dialogas a estáticos .

Yo creo que esos diálogos para las versiones "viejas" los dejamos como están en dialogo modal , eso si cambiando estas variables a locales de cada dialogo , pero para las versiones "modernas" ¿tienes pensado algo ? . lo dejamos igual o ponemos una pestaña de folder a derecha donde colocamos los diálogos y enseñamos el del elemento que está seleccionado ? .

[mastintin]

Tenemos un par de bugs.
1.- Si añadimos un nuevo elemento al reporte el treeview del panel no se refresca . // edito ---- ya esta solucionado para añadir y borrar falta cambio de nombre .
2.- no consigo cazarlo ... pero me da un error :
Error occurred at: 01.10.2014, 23:17:18
Error description: Error BASE/1004 No exported method: NTOP
Args:
[ 1] = U

Stack Calls
===========
Called from: => NTOP( 0 )
Called from: source\eritems.prg => MSGBARITEM( 1526 )
Called from: source\eritems.prg => (b)ELEMENTACTIONS( 56 )
Called from: .\source\classes\WINDOW.PRG => TWINDOW:MOUSEMOVE( 3020 )
Called from: .\source\classes\CONTROL.PRG => TSAY:MOUSEMOVE( 732 )
Called from: => TWINDOW:HANDLEEVENT( 0 )
Called from: .\source\classes\CONTROL.PRG => TCONTROL:HANDLEEVENT( 1733 )
Called from: .\source\classes\SAY.PRG => TSAY:HANDLEEVENT( 227 )
Called from: .\source\classes\WINDOW.PRG => _FWH( 3291 )
Called from: => WINRUN( 0 )
Called from: .\source\classes\WINDOW.PRG => TMDIFRAME:ACTIVATE( 1015 )
Called from: source\ereport.prg => MAIN( 235 )

[cnavarro]

Ok. De momento mantenemos las cosas como están en cuanto a versiones.
Hoy cuando estaba pasando Variable publicas a Static o Data me encontré con una muy concreta ....oCurdlg
Se usa en todos los dialogos de propiedades, quizás en su momento pretendiendo crear un dialogo no modal para todas las pantallas y que se refrescase dinámicamente según el objeto seleccionado .Como el desarrollo no estaba completo yo pasé los dialogas a estáticos .

Yo creo que esos diálogos para las versiones "viejas" los dejamos como están en dialogo modal , eso si cambiando estas variables a locales de cada dialogo , pero para las versiones "modernas" ¿tienes pensado algo ? . lo dejamos igual o ponemos una pestaña de folder a derecha donde colocamos los diálogos y enseñamos el del elemento que está seleccionado ? .

En eso estoy
Haciendo unas pruebas
Es que lo de las pestañas para este tema no me acaba de convencer

[mastintin]

del mensaje anterior funciona seleccionando desde el treeview , pero si seleccionamos con dblclick en el elemento y cambiamos el nombre ese cambio en el treeview no se refleja .

[mastintin]

Cristobal localizada la manera de reproducir el bug arriba mencionado . Si editamos un Area con doble click en el treeview ( ojo un Area ) y luego volvemos al reporte y pasamos el raton por encima de un elemento rompe por que aItems[nArea,nItem] en vez de ser un objeto tiene valor nil .

Code: Select all

function MsgBarItem( nItem, nArea, cAreaIni, nRow, nCol, lResize )

   local nTop, nLeft
   local cItemDef := AllTrim( GetPvProfString( "Items", AllTrim(STR(nItem,5)) , "", cAreaIni ) )
   local cItemID  := AllTrim(  GetField( cItemDef, 3 ) )

   DEFAULT lResize := .F.

   if lResize .AND. LEN( aItemPosition ) <> 0

      oER:oMsgInfo:SetText( GL("ID") + ": " + cItemID + "  " + ;
                        GL("Top:")    + " " + AllTrim( aItemPosition[1] ) + "  " + ;
                        GL("Left:")   + " " + AllTrim( aItemPosition[2] ) + "  " + ;
                        GL("Width:")  + " " + AllTrim( aItemPosition[3] ) + "  " + ;
                        GL("Height:") + " " + AllTrim( aItemPosition[4] ) )

   ELSE
      nInfoRow := 0; nInfoCol := 0 // oEr:nRulerTop := 0; oER:nRuler := 0 // FiveTech
      msginfo( aItems[nArea,nItem]   )  // aqui esta  aItems[nArea,nItem] tiene valor nil 

      nTop  := aItems[nArea,nItem]:nTop  + ;
                  ( nLoWord( aItems[nArea,nItem]:nPoint ) - nInfoRow ) - oEr:nRulerTop
      nLeft := aItems[nArea,nItem]:nLeft + ;
                  ( nHiWord( aItems[nArea,nItem]:nPoint ) - nInfoCol ) - oER:nRuler

  endif

return .T.


 

................... edito ....................

El bug se produce al editar un area desde cualquier sitio .