Error en Browse

[Daniel Pechir]

Hola Equipo

Quisiera saber donde está mi error al editar un browse
El Código es :

METHOD BrowseColumn4PostEdit( oSender, Value, lCanceled, nKey ) CLASS DepuraInve

WITH OBJECT ::oMovi
:Refresh()
:Refresh()
:FastEdit()
:Ajus := Value - :Princi
:FastUpdate()
:FastEdit()
:Importe := Round(:Costo * Value,0)
:FastUpdate()
END

El mensaje es:

En la versión 6.2 al segundo intento acepta el dato.
En la versión 7.2 falla totalmente

Gracias por su apoyo

Daniel Pechir Tager

[ignacio]

Código: Seleccionar todo

WITH OBJECT ::oMovi
 :FastEdit()
 :Ajus := Value - :Princi
 :Importe := Round(:Costo * Value,0)
 :FastUpdate()
END WITH

[Daniel Pechir]

Gracias Ignacio

Ya cambié el código y ahora muestra 2 errores y ya no cambia el valor del campo ni con la versión 6.2

Saludos

[ignacio]

Hola,

Mande un pequeño ejemplo que reproduzca el error. Le ruego no mande su propio código. Ha de ser un ejemplo realizado específicamente para mostrar el error con el menor número de líneas de código. Gracias de antemano.

Un saludo

[Daniel Pechir]

Estimado Ignacio

Como lo comenté desde que se lanzó la versión 7, nunca se me presentó éste problema en mi código
Es curioso que no sucede en todos los TBrowses de mi ERP aunque tengan las mismas propiedades y operaciones similares

Lo estoy resolviendo con comandos directos a MySQL como el siguiente

METHOD RegActualClick( oSender ) CLASS Ajusaldos

cCmdQuery := "update "+cArch+" set tven = 1 where nucuenta = '"+cThis+"'"
AppData:oMySqlDS:Execute( cCmdQuery )

WITH OBJECT ::oAjustes
:Refresh()
:Skip()
END

RETURN Nil

Pero insisto que algo cambió de la versión 6 a la 7

¿ Le suena que haya habido algún cambio en las nuevas versiones ?
Quisiera ya poder migrar ahasta la versión 8, ya que me estoy quedando atrás

Saludo afectuoso

[ignacio]

Buenos días,

Es usted la única persona que se ha quejado de este problema. Le insisto, que nos mandé un pequeño ejemplo que muestre el error. Eso es todo lo que le puedo decir. Lo siento.

Un saludo

[Daniel Pechir]

Hola Ignacio
Muchas gracias po sus atenciones y perdón por mi necedad pero:

Exactamente el mismo código compilado con versión 6 funciona y con versión 7 falla
Quiero probar si con la versión 8 desaparece el problema pero ahora tengo problemas
con el Setup de la versión 8 que ya reporté en otro Post

Saludo afectuoso

Daniel Pechir Tager

[ignacio]

Ya respondido.

En cualquier caso, su código no es correcto, No tienen sentido esas llamadas a Refresh(), ni tampoco la operación de Update() en dos pasos.

Insisto, mande un ejemplo. Sin él, nada podemos hacer para ayudarle.

Saludos

[Daniel Pechir]

Gracias Ignacio por sus atenciones

Ya cambié código y funcionó.
Ahora el Browse no está respetando el ancho de las columnas, las abre y las hace mas anchas y hay que reducirlas manualmente

Ya revisé todas las propiedades y no encuentro como evitar dicho comportamiento

Saludos cordiales

Daniel Pechir Tager

[mcastabaron]

Buenos días Daniel,
Prueba a desmarcar Soporte de pantallas de alta resolución (HRD) en Herramientas-opciones generales-interfaz.
Saludos.
Miguel.

[Daniel Pechir]

Muchas gracias Miguel

Dios te Bendice

Daniel

[jfgimenez]

Hola a todos,

con respecto a esto:

Prueba a desmarcar Soporte de pantallas de alta resolución (HRD) en Herramientas-opciones generales-interfaz.

me gustaría aclarar una cosa. La opción de soporte HRD se añadió para que el IDE sea "DPI aware". Es decir, con esto marcado, el IDE "reconoce" la verdadera resolución del monitor y escala los formularios y controles a lo que se haya definido en el panel de control de windows. Sin esto marcado, windows oculta al IDE la verdadera resolución del monitor, y es el propio windows el que se encarga de escalarlo todo. Esto tiene dos lecturas:

1) El escalado que hace windows es más preciso, en el sentido de que todo lo ajusta exactamente al tamaño que tenía originalmente pero escalado a lo que tengamos definido. P.ej., si tenemos una escala de 125%, un formulario que tenga el tamaño de 800x600 pixels originalmente, Windows lo mostrará en un tamaño de 1000x750, para que se vea más grande en pantalla, de acuerdo con la escala que tenemos configurada. Pero el método para escalarlo es simplemente proyectar cada pixel del formulario original al espacio que ocupa con la nueva escala. En el caso de una escala del 125% cada 4 píxeles originales se tienen que convertir en 5 píxeles, y windows hace "lo que puede". El resultado es bastante bueno, pero esto produce que tanto las imágenes como, sobretodo, los textos se vean borrosos, incluido el editor de código. Aquí tenéis un ejemplo de cómo se ve (lo he ampliado al 200% para que ve aprecie mejor):

1.jpg (61.62 KiB) Visto 1215 veces

2) Cuando se marca la opción HRD y es el propio IDE el que hace el escalado, no es tan preciso como el de windows, en términos de píxeles. Si usamos una escala del 125%, significa que un formulario de 800x600 píxeles se va a mostrar a un tamaño de 1000x750, sin proyectar nada, simplemente ocupando ese espacio realmente. Por supuesto, esto tiene algunos problemas, como que al volver a guardar el formulario el IDE tiene que "desescalar" todo, y teniendo en cuenta que los píxeles son valores enteros, no decimales, se pierde siempre algo de precisión. Claro que no son solamente las coordenadas las que hay que escalar y desescalar; también hay que hacerlo con algunas propiedades, como el tamaño de las columnas de un browse. Y seguramente este es el problema que estáis detectando, que esa propiedad no se está escalando bien. Por otro lado, al hacerse el pintado sobre los píxeles reales y no sobre una proyección, tanto las imágenes como los textos son perfectamente nítidos. Aquí tenéis la misma captura pero con la opción HRD marcada:

2.jpg (74.71 KiB) Visto 1215 veces

Como podéis ver, cada opción tiene sus ventajas e inconvenientes, y por eso no lo impusimos sin más, sino que lo dejamos configurable para que cada usuario optara por lo que prefiera. Si a alguien no le importa que todo se vea borroso a cambio de que no se desajuste nada, pues perfecto. En cambio si otro usuario prefiere verlo todo nítido aún a costa de que puede haber ajustes en las posiciones y tamaños de los controles, pues también está bien.

Y finalmente, esos desajustes que se pueden producir pueden ser intrínsecos (p.ej., dividir 18 entre 125% da como resultado 14.4, y se convierte a 14). Estas conversiones producen desajustes mínimos, y no nos deben preocupar. Pero estos desajustes también pueden deberse a algún error u omisión por nuestra parte. Si miráis los fuentes de las clases de Xailer, podréis ver que algunas propiedades tienen como "editor de propiedades" PE_Scale, que es el que se encarga de hacer estas transformaciones. Si alguna propiedad necesita ser escalada y no hemos puesto PE_Scale se va a producir este desajuste. Por eso, os ruego que nos comuniquéis cualquier error de este tipo que podáis detectar para corregirlo lo antes posible.

Eso es todo, y disculpad por la chapa, pero creo que este tema merecía una explicación.