Cambio dimensiones gets FWH-24.09

[Cgallegoa]

Antonio, la versión FWH24-09 cambia las dimensiones de los gets.

El siguiente ejemplo está compilado con FWH-23.10 y con FWH-24.09. Obsérvese que el ancho y el alto de los gets es ligeramente diferente entre las dos versiones. En una ventana simple no hay problema, pero en una ventana compleja, con muchos gets y otros controles, se vuelve complicado reordenarlos. En principio no deberían cambiarse las dimemsiones.

Code: Select all  Expand view  RUN

#include "FiveWin.ch"

Function Inicio
   LOCAL oDlg, oGet[1], oFont[1], oBtn[1]
   LOCAL cText1 := "Campo de texto 01"
   LOCAL cText2 := "Campo de texto 02"
   DEFINE FONT oFont[1] NAME "Arial" SIZE 0,16 BOLD
   DEFINE DIALOG oDlg SIZE 280,140 PIXEL
       @ 10, 30 SAY "Versión:   " + FWVERSION OF oDlg PIXEL FONT oFont[1]
       @ 30, 10 GET oGet[1] VAR cText1 OF oDlg SIZE 100,11 PIXEL
       @ 30, 110 BTNBMP oBtn[1] PROMPT "+" OF oDlg SIZE 10,10 PIXEL FLAT
       @ 42, 10 GET oGet[1] VAR cText2 OF oDlg SIZE 100,11 PIXEL
   ACTIVATE DIALOG oDlg CENTERED
Return(NIL)

Ya hay algunos temas pendientes sin solución (TPrinter():lUseHaruPDF, Maria_Connect(), dimensiones gets) que nos impide la actualización de nuestros programas a la versión FWH-24.09. Agradezco tu invaluable ayuda al respecto.

[Antonio Linares]

Carlos,

vamos a revisarlo de inmediato,

muchas gracias por tu feedback!

[nageswaragunupudi]

dimensiones gets

We regret the inconvenience.

We will be grateful if you can apply a small fix in
\fwh\classes\cpntrol.prg
and provide your feedback.

Please locate the METHOD CalcSize(...) in control.prg

Code: Select all  Expand view  RUN

METHOD CalcSize( nTop, nLeft, nWidth, nHeight, lRelative, oWnd, nBottom, nRight ) CLASS TControl // 2024-05-21

   local aRect
   local lTruePixel := .t.

   DEFAULT oWnd := ::oWnd, lRelative := oWnd:lAutoSizeCtrls

   if .PCount() > 0

Please change the last line as:

Code: Select all  Expand view  RUN

METHOD CalcSize( nTop, nLeft, nWidth, nHeight, lRelative, oWnd, nBottom, nRight ) CLASS TControl // 2024-05-21

   local aRect
   local lTruePixel := .t.

   DEFAULT oWnd := ::oWnd, lRelative := oWnd:lAutoSizeCtrls

   if .f. //PCount() > 0

Can you please confirm if this fix solves the Get dimensions issue?
Thanks in advance.

[nageswaragunupudi]

Maria_Connect()

The problem is only with xHarbour 64 bits.


Continues to work perfectly with all other compiler versions
xHarbour bcc32 bits, Harbour bcc 32bits and 64 bits MSVC 32 and 64 bits.

This is an issue with xHarbour and not at all with FWH

PS: I am looking for xHarbour 64 bits built in year 2023 or before with versions prior to bcc77
Do you have by any chance?

[nageswaragunupudi]

TPrinter():lUseHaruPDF

The problem is only with the current version of xHarbour and that too 32 bits version only.

Works perfectly with
Harbour bcc 32/64 bit and MSVC 32/64 bits
and xHarbour 64 bits also.

Incidentally, this works perfectly even with older versions of xHarbour 32 bits also even with FWH2409.
The problem came up recently with upgraded versions of xHarbour.

[nageswaragunupudi]

We can prove to ourselves that with FWH2409 the sample pdfharu1.prg works perfectly if we build with an older version of xHarbour built with bcc7 (not with bcc77 recently)
Note: we need to include a workaround for __streams.

[nageswaragunupudi]

I have an older version of xHarbour (built with bcc7 (not bcc77)) in the year 2023.
xHarbour 1.2.3 Intl. (SimpLex) (Build 20180818)
I have in folder c:\xharbour70
Now I will try to build fwh2409\samples\pdfharu1.prg using my older xharbour.

Step-1:
I edited pdfharu1.prg and added these 3 lines of code:
[code]#pragma BEGINDUMP

int _streams;

#pragma ENDDUMP]/code]

Now I set environment variable xhdir=c:\xharbour70 and tried to build and this is successful.
Problem is only with the present xHarbour.
No problem with FWH at all

[nageswaragunupudi]

HARUPDF : FIX

On testing I found that the problem is with "libharu.lib" that comes with the current version of xHarbour.
If we replace \xharbour\lib\libharu.lib with an older version of the lib, everything is working perfectly.
Or we can use the older libharu.lib in our link script.
I have tested this and is working perfectly.

You may please test and confirm.
We can treat this issue as resolved.

[Cgallegoa]

Mr. Rao thanks for your answer.

1.- Dimensiones gets:
Ok, your suggestion works well in the example, but in full app produce error.

Code: Select all  Expand view  RUN

Aplicación:
===========
   Path y nombre: D:\MSTVS\CG_VP.EXE
   Tam.: 8,605,184 bytes
   Máximo de ficheros abiertos: ( SetHandleCount() )   0
   Error ocurrido el día: 06-10-2024, a la hora: 18:45:24
   Nombre del error: Error BASE/1083  Error de argumento: *
   Args:
     [   1] = N   16
     [   2] = U   16

Llamadas a funciones
====================
   Llamado por TCONTROL:CTOCHAR(404)
   Llamado por (b)TGROUP:TGROUP(28)
   Llamado por TGROUP:CTOCHAR(0)
   Llamado por TDIALOG:CTOCHAR(725)
   Llamado por TDIALOG:ACTIVATE(309)
   Llamado por CGINI31(219)
   Llamado por (b)INICIAL(269)
   Llamado por TMDIFRAME:ACTIVATE(1106)
   Llamado por INICIAL(269)
   Llamado por INICIO(558)

Sistema
=======
   CPU tipo: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
   Memoria: 16935899904 (16538964 megas)

   Recursos libres .....: % 90
        GDI  recursos ..: % 90
        Usuarios recurs.: % 90

   Version de Windows y MS-Dos:  6. 2, **. 2
   Total de aplicaciones WIN ejecutandose:   0
      1 ,                                                                                                    

Variables en uso
================
   Programa      Tipo   Valor
   ==========================
   TCONTROL:CTOCHAR
     Param   1:    C    "BUTTON"
     Local   1:    O    Class: TGROUP
     Local   2:    N    1048584
     Local   3:    U    
     Local   4:    U    
     Local   5:    U    
     Local   6:    U    
     Local   7:    N    16
     Local   8:    U    
     Local   9:    U    
     Local  10:    U    
   (b)TGROUP:TGROUP
     Param   1:    O    Class: TGROUP
   TGROUP:CTOCHAR
   TDIALOG:CTOCHAR
     Param   1:    N    7736026
     Local   1:    O    Class: TDIALOG
     Local   2:    C    "

It is understandable, somewhere the call to the CalcSize() method needs to evaluate a numeric value with PCount and not a Boolean value.
The expression "if PCount() > 0" handles a different type compared to "if .F.".

In other way, I have a question: The file 'Control.prg' that comes in FWH-24.09 has:

Code: Select all  Expand view  RUN

METHOD CalcSize( nTop, nLeft, nWidth, nHeight, lRelative, oWnd, nBottom, nRight ) CLASS TControl // 2024-05-21

   local aRect

   DEFAULT oWnd := ::oWnd, lRelative := oWnd:lAutoSizeCtrls

   if .F. // PCount() > 0

Which is slightly different from yours:

Code: Select all  Expand view  RUN

METHOD CalcSize( nTop, nLeft, nWidth, nHeight, lRelative, oWnd, nBottom, nRight ) CLASS TControl // 2024-05-21


   local aRect
   local lTruePixel := .t.

   DEFAULT oWnd := ::oWnd, lRelative := oWnd:lAutoSizeCtrls

   if .f. //PCount() > 0

The version I have does not include local lTruePixel := .t., why ?, Is it important ?

2.- Maria_Connect():
Yes, the issue is specific to xHarbour 64-bit.
I only have 'xhb10269_bcc73064.zip', could it be useful for you ?
I looked online, but I couldn't find another.

3.- TPrinter():lUseHaruPDF:
Using lUseHaruPDF (like pdfharu1.prg and others) fails in 32-bit xHarbour and Harbour, but works as expected in 64-bit versions of both.

I don't have a version of xHarbour bcc7, only bcc7.3 and bcc7.7, and neither of them work. Could you send me "libharu.lib" compiled with bcc7 to test? While I believe mixing different compiler versions could cause headaches in future updates, it would be fine for testing. Hopefully, the xHarbour experts will find definitive solutions.

I tried including libharu.lib version bcc7.3, but it didn't work.

Reflection:
Are the difficulties we're encountering with the most recent xHarbour version a sign that we're reaching the end of the road for xHarbour ?

Does this mean we are forced to migrate to Harbour?

Best regards,

[nageswaragunupudi]

Ok, your suggestion works well in the example, but in full app produce error.

Thanks for the feed-back.
I will do extensive testing and fix the size issue.
For sure we will handle the issue in next one or two days.
I will also be thankful if you keep helping me with testing.

I only have 'xhb10269_bcc73064.zip', could it be useful for you ?

I don't know. Let me try with this version and see.
For now I am thinking of totally commenting out the Rowset destructor method for xharbour 64 bits only.

I tried including libharu.lib version bcc7.3, but it didn't work.

I will send you the lib that worked for me and try with that.

Are the difficulties we're encountering with the most recent xHarbour version a sign that we're reaching the end of the road for xHarbour ?

Does this mean we are forced to migrate to Harbour?

Not at all. Once in a while, we may get into some problems, but for sure xHarbour is great..

Once I fix the first two issues, I will request Mr. Antonio to release a revised build of FWH2409

Can you please write to my email:
nageswaragunupudi[at]gmail[dot]com

[nageswaragunupudi]

Using lUseHaruPDF (like pdfharu1.prg and others) fails in 32-bit xHarbour and Harbour,

No please.
Works perfectly with Harbour bcc 32bits also.
Fails only with xHarbour and that too we can now overcome by using an older libharu.lib

[Enrico Maria Giordano]

Maria_Connect()

The problem is only with xHarbour 64 bits.


Continues to work perfectly with all other compiler versions
xHarbour bcc32 bits, Harbour bcc 32bits and 64 bits MSVC 32 and 64 bits.

This is an issue with xHarbour and not at all with FWH

PS: I am looking for xHarbour 64 bits built in year 2023 or before with versions prior to bcc77
Do you have by any chance?

You can browse the old commits in the FWH repository. But please, answer to this question: why do you need an explicit destructor? FWH never used explicit destructors for any classes before.

[Enrico Maria Giordano]

HARUPDF : FIX

On testing I found that the problem is with "libharu.lib" that comes with the current version of xHarbour.
If we replace \xharbour\lib\libharu.lib with an older version of the lib, everything is working perfectly.
Or we can use the older libharu.lib in our link script.
I have tested this and is working perfectly.

You may please test and confirm.
We can treat this issue as resolved.

Works fine here using xHarbour/MSC32. So the problem can''t be xHarbour or libharu.lib.

[nageswaragunupudi]

Works fine here using xHarbour/MSC32.

Is it working for you with xHarbour bcc77 32 bits for you there please?

[Enrico Maria Giordano]

No, but xHarbour source code is the same for both BCC32 and MSC32, so the problem is not with xHarbour, right?