FiveTech Software tech support forums

... * nPrecio oDlg:UPDATE()  Lo he descubierto de casualidad, pero comentando el oDlg:Update() se soluciona el tema. No se si es un bug, pero estareis conmigo que es un comportamiento extraño del metodo UPDATE del DIALOG. Antonio, Mr. Rao, que les parece ? Saludos a todos. Jose.

Hola amigos: Se podría tratar de un bug o algo hago mal, estoy usando la version 2409(ultima) en 64 bits. Pero en 32 bits con esta version obtengo el mismo comportamiento, en mi anterior version 19.06 32 bits funciona bien y ahora siempre se ...

... Pd: The SourceEdit function does not return the editor object (this is a bug) That is why I have to use the SourceEditor() function to get the Scintilla object To fix this, edit memoedit.prg, and in the SourceEdit function, ...

... Pd: The SourceEdit function does not return the editor object (this is a bug) That is why I have to use the SourceEditor() function to get the Scintilla object To fix this, edit memoedit.prg, and in the SourceEdit function, ...

... need, but running on a local network makes it entirely possible. I have built an autoupdating system that works quickly and if we ever found a bug, the repair can be done, and disseminated, within minutes. If someone wants to work remotely, there are multiple options, and they never have an ...

1) when the F2 key is pressed the cell is edited even if :bEditWhen is FALSE Yes. This is a bug in xbrowse.prg, which has been overlooked for many years. Thanks for pointing this out. Can you apply this fix in xbrowse.prg and confirm if this working well. Please locate ...

I'm not aware of any pending bug. Please show a sample of each problem, so I can investigate.

I'm not aware of any pending bug. Please show samples to reproduce them.

They are related to FWH and we are addressing them.

... Rao and Mr. Enrico, thank you very much. TPrinter():lUseHaruPDF works very well with the latest version of xHarbour. Unfortunately not. The real bug is just hidden. I'm waiting for Rao to apply the correct fix. Rao, first remember to reactivate the destructor for xHarbour. Pending items: 1.- ...

I am extremely sorry. The error is due to a bug in our TMonitor class. And also thanks for bringing it to our notice. Can you please apply the fix I am going to provide here and try it again? \fwh\source\function\getsysin.prg Please locate these ...

... (new ) default .f. To use GDI+ or classic GDI * function FW_ReadImage() crashing with xhb.com. Fixed. * Enhancement: samples\FiveDbu.prg had a bug when deleting a field from a DBF structure, now it is ok. https://fivetechsupport.com/forums/viewtopic.php?p=273041#p273041 * FWMarialib: oRs := ...

Yes, I think so. But the question is: why do you need an explicit destructor?

At the top of the module

Code: Select all  Expand view  RUN

#ifdef __XHARBOUR__
#ifdef __64__
#define __XHARBOUR64__
#endif
#endif

Code: Select all  Expand view  RUN

#ifndef __XHARBOUR64__
   DESTRUCTOR fwmariarowset_Destroy()
#endif

Next apply the same condition to the entire body of the Procedure

Do you think this should be ok?

Yes, we can.

Can we restrict the destructor method not to work with xHarbour 64 bits only?
Let me try