Announcing DrXlsx 1.0 by Charles Kwon

[Antonio Linares]

A great contribution to Harbour/xHarbour from Master Charles Kwon:

http://www.charleskwon.com/?page_id=956

Don't miss it!

[Joaquim Ferrer]

* No Excel installation is required at all
* No XLSX ADO installation is needed either
* No special DLL installation is required to create XLSX files
* XLSX creation is self-contained, no external files needed

Many Thanks, great job master Charles Kwon !

[mauri.menabue]

Hi Charles Know
Really thank you, it's a really missing tool !!!.
i already downloaded it and it worked without problems Fwh 23.07 BBC 7.0.
Today I continue with the tests

Tia Maurizio Menabue

[mgsoft]

Thank you!!

Is source code available?

Will fwh use it for preview and xBrowse?

[CharlesKwon]

mgsoft,
The distribution file contains sample source code. Additionally, there is a manual available at the link above.

Regards,
Charles KWON

Thank you!!

Is source code available?

Will fwh use it for preview and xBrowse?

[mauri.menabue]

Hi Charles,
the program has just been presented and I immediately ask if you have in mind
the possibility of adding two methods, one to manage the height of the lines,
the other to be able to modify the method : sayimage in order to possibly resize
the image to be printed.

TIA
Maurizio Menabue

[mgsoft]

Thank you. Will you sell the full source code?

I do not use external libs without its full sources.

[CharlesKwon]

mgsoft,

I have no intention of revealing the internal code. So, I prefer using the iPhone and Windows, which don't have their internal code disclosed. This is human free will
Please, by your own free will, find and use another 'OPEN' SOURCE.

Regards,
Charles KWON

Thank you. Will you sell the full source code?

I do not use external libs without its full sources.

[CharlesKwon]

Maurizio,

DrXlsx supports many versions of harbour(32/64)/xHarbour(32/64) and VC/BCC/Clang under the same protocol.
It's a time-consuming task and some versions can cause unexpected issues due to their unique characteristics.
I am also testing the desired features for each version, and I will announce them once it is complete.
Thank you.

Regards,
Charles KWON

Hi Charles,
the program has just been presented and I immediately ask if you have in mind
the possibility of adding two methods, one to manage the height of the lines,
the other to be able to modify the method : sayimage in order to possibly resize
the image to be printed.

TIA
Maurizio Menabue

[Jimmy]

hi,

i open OEM DBF and try to use oXlsx:Say() or oXlsx:WriteString()
but i have Problem with DrXlsx32.lib and German Umlaute ( äöüÄÖÜß )

have try FW_SetUnicode( .T./.F. ) and hb_cdpSelect( "DE850" / "DEWIN" )
need a Tip what else i can try

[nageswaragunupudi]

Code: Select all  Expand view  RUN

#include "fivewin.ch"

function Main()

   local oXlsx, cFile, cUmlaut

   FW_SetUnicode( .F. )

   cFile    := "uml.xlsx"
   cUmlaut := "üüüüü"
   ? cUmlaut

   oXlsx    := TDrXlsx():New()
   WITH OBJECT oXlsx
      :CreateFile( cFile )
      :Say( 1, 0, "UMLAUT" )
      :Say( 1, 1, cUmlaut )
      :Close()
   END

   ShellExecute( 0, "Open", cFile )

return nil
 

[nageswaragunupudi]

In continuation:

German Umlauts (also all accented characters of West European languages) are encoded differently in ANSI and UTF8. I posted more details in your other posting.

All English characters and also all non-accented characters of other languages are encoded as same single byte both in ANSI and UTF8, so there is no problem there.

I noticed that this library requires utf8 encoding. If our string containing Umlauts is encoded in ANSI, we need to convert into UTF8.

I propose this approach which is working satisfactory in all my tests:
It does not matter if the string is ANSI encoded or UTF8 encoded, this approach works.

Code: Select all  Expand view  RUN

#include "fivewin.ch"

function Main()

   local oXlsx, cFile, cUmlaut

   FW_SetUnicode( .F. )

   cFile    := "uml.xlsx"

   cUmlaut  := Space( 10 )
   MsgGet( "Enter:", "UMLAUT", @cUmlaut )
   cUmlaut  := Trim( cUmlaut )

   oXlsx    := TDrXlsx():New()
   WITH OBJECT oXlsx
      :CreateFile( cFile )
      :Say( 1, 0, "UMLAUT" )
      :Say( 1, 1, strToUtf8( cUmlaut ) )
      :Close()
   END

   ShellExecute( 0, "Open", cFile )

return nil
//-------------
static function StrToUtf8( c ); return UTF16TOUTF8( strToWide( c ) )
 

Please test by entering different strings and this should work well.

[Jimmy]

hi,

thx for Answer.

your Sample work like expect, but i talk about "old" existing OEM DBF

i have try to explain it in this Thread
https://forums.fivetechsupport.com/viewtopic.php?f=3&t=43651

[Jimmy]

hi,

i have try to make some Sample to "test" Speed

using a 32 Bit Apps

ADO

Records = 59780 Time = 41.74 1432.23 Rec/Sec

XLSwriter

Records = 59780 Time = 8.20+ 7285.80 Rec/Sec

so XLSwriter is 500 % faster

---

now use XLSwriter with > 350000 Record using 32 Bit App ...

32 Bit Aoo using XLSwriter "crash" > 109000 Record while "memory exhaust"
32 Bit App using ADO does create a 20 MB *.XLSB with all 351287 Record

ADO

Records = 351287 Time = 288.54  1217.47 Rec/Sec

XLSwriter

RECNO() = 109571 MEMORY( 3 ) = 31044 // have set Limit at 32 Kb

it is just before available Memory "crash" so leave loop

i "think" it have to do that ADO "read/write" while XLSwriter "read" all to RAM before "write"
when "break" ADO there is a *.XLSB but nothing when XLSwriter "crash"

---

using a 64 Bit Apps

ADO
it is funny that my 64 Bit MSVC App work slower that 32 Bit BCC7 App ?

cIn = "records in dbf: 351287"
cIn = "imported recs: 351287"
cIn = "Std 00:06:13"
cIn = "Rec/Sec 940.51"

XLSwriter

nReccount = 351287 nRecLast = 351288 % = 100 nTime = 71.06 4943.40 Rec/Sec
nOEM = 107712 nANSI = 17642 nELSE = 5821450

this was 32 Bit App

nReccount = 351287 nRecLast = 109571 % = 31 nTime = 50.96 2150.14 Rec/Sec
nOEM = 39715 nANSI = 4747 nELSE = 1811139

btw. when RAM decrease also APP Speed decrease using 32 Bit App

so also XLSwriter 64 Bit is 500 % faster

---

Epilogue :
Benefit ADO : work under 32 Bit App. no "Umlaute" Problem using OEM DBF
Limitation : Speed like ActiveX

Benefit XLSwriter : SPEED
Limitation : need UFT8 else it "crash"

not sure : XLSwriter 32 Bit App get "slower" when use many Times include "edit"/Recompile
from 2150.14 Rec/Sec it goes < 2000 Rec/Sec ... after re-boot it start at 2300 Rec/Sec

[CharlesKwon]

Jimmy,

1.
The issue occurring in 32bit is less a problem of DrXlsx and more fundamentally about the memory size limitations of 32bit. It might be more beneficial to explore other solutions than spending time trying to resolve this.
2.
If DrXlsx operates correctly in 64bit, I would recommend creating the xlsx export program in 64bit and using it as a utility.

Regards,
Chalres KWON

hi,

i have try to make some Sample to "test" Speed

using a 32 Bit Apps

ADO

Records = 59780 Time = 41.74 1432.23 Rec/Sec

XLSwriter

Records = 59780 Time = 8.20+ 7285.80 Rec/Sec

so XLSwriter is 500 % faster

---

now use XLSwriter with > 350000 Record using 32 Bit App ...

32 Bit Aoo using XLSwriter "crash" > 109000 Record while "memory exhaust"
32 Bit App using ADO does create a 20 MB *.XLSB with all 351287 Record

ADO

Records = 351287 Time = 288.54  1217.47 Rec/Sec

XLSwriter

RECNO() = 109571 MEMORY( 3 ) = 31044 // have set Limit at 32 Kb

it is just before available Memory "crash" so leave loop

i "think" it have to do that ADO "read/write" while XLSwriter "read" all to RAM before "write"
when "break" ADO there is a *.XLSB but nothing when XLSwriter "crash"

---

using a 64 Bit Apps

ADO
it is funny that my 64 Bit MSVC App work slower that 32 Bit BCC7 App ?

cIn = "records in dbf: 351287"
cIn = "imported recs: 351287"
cIn = "Std 00:06:13"
cIn = "Rec/Sec 940.51"

XLSwriter

nReccount = 351287 nRecLast = 351288 % = 100 nTime = 71.06 4943.40 Rec/Sec
nOEM = 107712 nANSI = 17642 nELSE = 5821450

this was 32 Bit App

nReccount = 351287 nRecLast = 109571 % = 31 nTime = 50.96 2150.14 Rec/Sec
nOEM = 39715 nANSI = 4747 nELSE = 1811139

btw. when RAM decrease also APP Speed decrease using 32 Bit App

so also XLSwriter 64 Bit is 500 % faster

---

Epilogue :
Benefit ADO : work under 32 Bit App. no "Umlaute" Problem using OEM DBF
Limitation : Speed like ActiveX

Benefit XLSwriter : SPEED
Limitation : need UFT8 else it "crash"

not sure : XLSwriter 32 Bit App get "slower" when use many Times include "edit"/Recompile
from 2150.14 Rec/Sec it goes < 2000 Rec/Sec ... after re-boot it start at 2300 Rec/Sec