RichEditBox handling of Unicode text files now fixed

HMG Unicode versions 3.1.x related

Moderator: Rathinagiri

User avatar
kcarmody
Posts: 152
Joined: Tue Oct 07, 2014 11:13 am
Contact:

RichEditBox handling of Unicode text files now fixed

Post by kcarmody »

I've made the changes to the RichEditBox control that I proposed in http://hmgforum.com/viewtopic.php?f=43&t=4034. These changes mean that the methods for loading and saving of Unicode text files now handle byte order marks (BOMs) correctly. There seemed to be no concern from other users that such changes would break existing code.

The changes I'm proposing are described in more detail at http://hmgforum.com/viewtopic.php?f=8&t=4070. The changes themselves are at http://kevincarmody.com/hmg/.

Kevin
User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil

RichEditBox handling of Unicode text files now fixed

Post by Pablo César »

Thanks you Kevin for your contribs ! Always very goog welcome !

Just to advice to others member, you attached .ch/.prg (source files) and I do not know if you corrected in based of last patch of Claudio. I have to install my WinMerge in this my PC just to compare and advise to all of you. My concern, is because if is not from last Claudio file, users probably will overwrite the Claudio patch. Sorry if I am wrong, please confirm.

For everybody: Any way, when install this, please check up ch/prg versions before.
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein
User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil

RichEditBox handling of Unicode text files now fixed

Post by Pablo César »

What I found at begining is some differences from last patch of Claudio which is missing in Carmody version. It's in case T == "TREE" of C:\hmg.3.3.1\SOURCE\h_controlmisc.prg. In Carmody version is missing a cargo values. And there are some more differences.

I do not know how Claudio/Rathinagiri (development team) will proceed with Carmody contributions. But I fouynd some differences and missing code regarding last Claudio version.

Dear Carmody, I really found very good procedure, very complete work of yours. I loved the DOC your modifying engine (ModifyChm.bat), very clever ! Nice job man ! Thank you very much for your sharing. Now I understand your main concern about DOC, ver very clever ! Nice one, impeccable work !

My advise to all:

- In view of these different versions, before applying this changes of RishEditBox, please make a backup of your existing HMG source files.
- Open a subfolder called C:\hmg.3.3.1\PATCHES (in case there is not already created). There you can can download all Claudio, Carmody pacthes.
- After C:\hmg.3.3.1\PATCHES, you can open a ne other subfolder called C:\hmg.3.3.1\PATCHES\Carmody. Then you can download Carmody patches. I suggest to download the http://kevincarmody.com/hmg/HMG.zip which contains all files regarding RichEditBox handling of Unicode of his last verson and be saved at C:\hmg.3.3.1\PATCHES\Carmody then you can extract it at HMG subfolder.
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein
User avatar
srvet_claudio
Posts: 2193
Joined: Thu Feb 25, 2010 8:43 pm
Location: Uruguay
Contact:

Re: RichEditBox handling of Unicode text files now fixed

Post by srvet_claudio »

kcarmody wrote:I've made the changes to the RichEditBox control that I proposed in http://hmgforum.com/viewtopic.php?f=43&t=4034. These changes mean that the methods for loading and saving of Unicode text files now handle byte order marks (BOMs) correctly. There seemed to be no concern from other users that such changes would break existing code.

The changes I'm proposing are described in more detail at http://hmgforum.com/viewtopic.php?f=8&t=4070. The changes themselves are at http://kevincarmody.com/hmg/.

Kevin
Hi Kevin and for everyone:

The best way to contribute code is not modifying source files and place them so that users install it as a patch because we are continually making changes in the source files for trying to improve HMG and thus would be chaos (mixture of changes official with changes in contributions).

The best way to contribute is posted only the modified functions and commenting on the changes made and a small demo with the changes.
Best regards.
Dr. Claudio Soto
(from Uruguay)
http://srvet.blogspot.com
User avatar
kcarmody
Posts: 152
Joined: Tue Oct 07, 2014 11:13 am
Contact:

Re: RichEditBox handling of Unicode text files now fixed

Post by kcarmody »

Pablo César wrote:you attached .ch/.prg (source files) and I do not know if you corrected in based of last patch of Claudio. I have to install my WinMerge in this my PC just to compare and advise to all of you. My concern, is because if is not from last Claudio file, users probably will overwrite the Claudio patch. Sorry if I am wrong, please confirm.
Sorry, I'm new here and did not know your customary procedure for submitting new changes. Now it seems that you would like for new files I submit to include the modifications in Claudio's latest patch. I've now modified my files so that they include Claudio's patch. http://kevincarmody.com/hmg/

Kevin
User avatar
kcarmody
Posts: 152
Joined: Tue Oct 07, 2014 11:13 am
Contact:

Re: RichEditBox handling of Unicode text files now fixed

Post by kcarmody »

srvet_claudio wrote:The best way to contribute is posted only the modified functions and commenting on the changes made and a small demo with the changes.
Several functions that I had modified were also modified in the patch. For testing, I find it quite tedious to patch functions or parts of functions into files, and I would not want to ask beta testers to do this. So I think it is better to create updated files which are based on some current beta, and then let whoever is in charge of the beta merge them into the beta. Does someone do this, or is each developer expected to maintain the beta?

Kevin
User avatar
srvet_claudio
Posts: 2193
Joined: Thu Feb 25, 2010 8:43 pm
Location: Uruguay
Contact:

Re: RichEditBox handling of Unicode text files now fixed

Post by srvet_claudio »

kcarmody wrote:
srvet_claudio wrote:The best way to contribute is posted only the modified functions and commenting on the changes made and a small demo with the changes.
Several functions that I had modified were also modified in the patch. For testing, I find it quite tedious to patch functions or parts of functions into files, and I would not want to ask beta testers to do this. So I think it is better to create updated files which are based on some current beta, and then let whoever is in charge of the beta merge them into the beta. Does someone do this, or is each developer expected to maintain the beta?

Kevin
Yes, I am primarily responsible for the development of HMG, is very tedious and causes me great waste of time compare whole files and then have to adapt the code to make it functional to the line current development of HMG.

For that reason Roberto Lopez wrote a while back:
What about user contributions?

I've noticed about comments like "Roberto does not accept code contributions
anymore".

This is true, but need some clarification.

In 2005 I've decided to change the way I work on HMG.

From that moment I do all modifications personally, but I still receiving comments, suggestions ideas and wishes from the users.

The reason for this, is that I want to keep the control of the code included in HMG, to assure that it remains compact, fast, stable, reliable and backwards compatible, keeping and eye on general project goals (enumerated in the previous message).

An example of this, is the recent Activex addition.

I've noticed that this feature was incorporated to the Freewin project.

I've analyzed the code, learned how it works ant then rewrote it
from the scratch to suit HMG needs.

This way, I'm not incorporating a 'black box' to the library that
could be difficult or impossible to fix or modify. I'm incorporating
code that is simple and easy to maintain.

I can make mistakes and write buggy code (of course) but there is a big possibility that I'm be able to fix it, since I've wrote it.

So, You can send to me (to HMG wish area on this forum) sample code with your proposed addition. I'll take a look at it.
I repeat, please:
the best way to contribute is posted only the modified functions and commenting on the changes made and a small demo with the changes.
Best regards.
Dr. Claudio Soto
(from Uruguay)
http://srvet.blogspot.com
User avatar
kcarmody
Posts: 152
Joined: Tue Oct 07, 2014 11:13 am
Contact:

Re: RichEditBox handling of Unicode text files now fixed

Post by kcarmody »

srvet_claudio wrote:I repeat, please:
the best way to contribute is posted only the modified functions and commenting on the changes made and a small demo with the changes.
OK thanks, but this raises several other questions.

Sometimes a function that I have modified has also been modified in your beta version. An example is GetFile(). Should the modified function that I submit include the changes in your beta and indicate which changes are mine? Or should it not include the changes in your beta?

i have modified several dozen functions. In what form should I submit each modified function? Should I submit each modified function in a separate file? Or can all the modified functions go into one file? Or should make a file for each source code file that indicates the changes I made to the corresponding source code file? Should the file(s) themselves indicate the changes? Or should the description of changes be somewhere else?

How should I handle a small number of changes to a large procedure? For example, DoMethod() is 549 lines long, but I changed only 3 lines. In such a case, is it OK to submit changed lines only?

For changes to include files, is it OK to submit only the #defines that I have modified?

Do you handle changes to documentation? It seems that Pablo César handles these.

Does this policy apply to samples? I have completely overhauled the rich edit demo (SAMPLES\Controls\RichEditBox\demo.prg). It includes 59 functions and is 2009 lines long. Every function is rewritten. I think the only practical way to submit this is as a whole file. Is that OK?

Since I have modified several dozen source functions, it will take me weeks to develop small demos for each change. However, the rich edit demo uses all these changes. It is not exactly small, but it does demonstrate all the changes. Will it be OK to comment on each place in the demo where a source modification affects the behavior of the demo and indicate how to test this behavior in the demo?

TIA for your help on all these questions.

Kevin
User avatar
srvet_claudio
Posts: 2193
Joined: Thu Feb 25, 2010 8:43 pm
Location: Uruguay
Contact:

Re: RichEditBox handling of Unicode text files now fixed

Post by srvet_claudio »

kcarmody wrote:
srvet_claudio wrote:I repeat, please:
the best way to contribute is posted only the modified functions and commenting on the changes made and a small demo with the changes.
OK thanks, but this raises several other questions.

Sometimes a function that I have modified has also been modified in your beta version. An example is GetFile(). Should the modified function that I submit include the changes in your beta and indicate which changes are mine? Or should it not include the changes in your beta?

i have modified several dozen functions. In what form should I submit each modified function? Should I submit each modified function in a separate file? Or can all the modified functions go into one file? Or should make a file for each source code file that indicates the changes I made to the corresponding source code file? Should the file(s) themselves indicate the changes? Or should the description of changes be somewhere else?

How should I handle a small number of changes to a large procedure? For example, DoMethod() is 549 lines long, but I changed only 3 lines. In such a case, is it OK to submit changed lines only?

For changes to include files, is it OK to submit only the #defines that I have modified?

Do you handle changes to documentation? It seems that Pablo César handles these.

Does this policy apply to samples? I have completely overhauled the rich edit demo (SAMPLES\Controls\RichEditBox\demo.prg). It includes 59 functions and is 2009 lines long. Every function is rewritten. I think the only practical way to submit this is as a whole file. Is that OK?

Since I have modified several dozen source functions, it will take me weeks to develop small demos for each change. However, the rich edit demo uses all these changes. It is not exactly small, but it does demonstrate all the changes. Will it be OK to comment on each place in the demo where a source modification affects the behavior of the demo and indicate how to test this behavior in the demo?

TIA for your help on all these questions.

Kevin
Hi Kevin,
An example is worth a thousand words.
In this case Rathinagiri (the other person responsible for the development of HMG together with me) sent me the following function where the code added is clearly marked with a small attached explanation (which of course was eliminated from the code) of how works the code.

Code: Select all

Function _HMG_PRINTER_SavePages ( lSaveAs )
Local i, nFiles, cFileEMF, cTempFolder, cPrintFileName, aFiles := {}

LOCAL g := {".PDF", ".BMP",".JPG",".GIF",".TIF",".PNG",".EMF"}
LOCAL nTypePicture := { Nil , BT_FILEFORMAT_BMP, BT_FILEFORMAT_JPG, BT_FILEFORMAT_GIF, BT_FILEFORMAT_TIF, BT_FILEFORMAT_PNG, Nil }
LOCAL acFilter := { {"PDF", "*.pdf"}, {"BMP", "*.bmp"}, {"JPG", "*.jpg"}, {"GIF", "*.gif"}, {"TIF", "*.tif"}, {"PNG", "*.png"}, {"EMF", "*.emf"} }
LOCAL cFullName, cPath, cName, cExt, cExtFile := ""
LOCAL cFileName := "HMG_PrintFile"
LOCAL cFolder   := GetCurrentFolder()

Local hBitmap, nType
Local flag_PDF := .F.
local nWidth, nHeight, nDPI

   IF ValType (_HMG_SYSDATA [ 506 ]) == "C"
      hb_FNameSplit( _HMG_SYSDATA [ 506 ], @cFolder, @cFileName, NIL, NIL )
   ENDIF

   // by Dr. Claudio Soto, September 2014

   IF ValType (lSaveAs) == "L" .AND. lSaveAs == .T.
      IF ValType (_HMG_SYSDATA [ 507 ]) == "C"
         cFullName := _HMG_SYSDATA [ 507 ]   // SaveAs cFullFileName
      ELSE
         MsgStop ("SaveAs: Invalid File Name", "ERROR")
         RETURN NIL
      ENDIF
   ELSE
      cFullName := PutFile ( acFilter, NIL, cFolder, .F., cFileName, @cExtFile )   // Dialog cFileName
   ENDIF
   
   HB_FNameSplit (cFullName, @cPath, @cName, @cExt, NIL)
   cExt := HMG_UPPER (AllTrim (cExt))

   i := ASCAN (g, cExt)
   If i == 0
      MsgStop ("Invalid File Extension: "+cExt, "ERROR")
      Return Nil
   endif

   nType := nTypePicture [ i ]

   IF HMG_UPPER (cExt) == ".PDF"
      flag_PDF := .T.
   ENDIF


cTempFolder := GetTempFolder () 

nFiles := ADIR ( cTempFolder + _HMG_SYSDATA [ 379 ] + "_hmg_print_preview_*.Emf")

ASIZE ( aFiles , nFiles )

ADIR ( cTempFolder + _HMG_SYSDATA [ 379 ]  + "_hmg_print_preview_*.Emf" , aFiles )


For i := 1 To nFiles
    cFileEMF := cTempFolder + aFiles [i]
    cPrintFileName := cPath + cName + "_" + StrZero ( i , 4 )

    IF HMG_UPPER (cExt) == ".EMF"
       COPY FILE (cFileEMF) TO (cPrintFileName + cExt)
    ELSE 
          

      // by Dr. Claudio Soto, April 2014
       hBitmap = BT_BitmapLoadEMF ( cFileEMF, WHITE )
       
       IF hBitmap <> 0 .AND. flag_PDF == .F.
          BT_BitmapSaveFile (hBitmap, cPrintFileName + cExt, nType)
          BT_BitmapRelease (hBitmap)
       ENDIF

       IF hBitmap <> 0 .AND. flag_PDF == .T.   // by Rathinagiri (May 2014)
         if i == 1 
            nDPI    := 300
            nWidth  := ( BT_BitmapWidth ( hBitmap ) / nDPI * 25.4 )  
            nHeight := ( BT_BitmapHeight( hBitmap ) / nDPI * 25.4 )
            _HMG_HPDF_INIT ( cPath + cName + ".PDF", 1, 256, nHeight, nWidth, .f. )
            _hmg_hpdf_startdoc()
            _HMG_HPDF_SetCompression( 'ALL' )
         endif

         _hmg_hpdf_startpage()
         BT_BitmapSaveFile (hBitmap, cPrintFileName + ".JPG", BT_FILEFORMAT_JPG)
         BT_BitmapRelease (hBitmap)
         _HMG_HPDF_IMAGE ( cPrintFileName + ".JPG", 0, 0, nHeight, nWidth, .t. , "JPG" )
         _hmg_hpdf_endpage()
         FERASE ( cPrintFileName + ".JPG" )

         if i == nFiles
            _hmg_hpdf_enddoc()
         endif

       ENDIF

    ENDIF
Next i
Return Nil
Best regards.
Dr. Claudio Soto
(from Uruguay)
http://srvet.blogspot.com
User avatar
kcarmody
Posts: 152
Joined: Tue Oct 07, 2014 11:13 am
Contact:

Re: RichEditBox handling of Unicode text files now fixed

Post by kcarmody »

srvet_claudio wrote:An example is worth a thousand words.
Thank you, Claudio. I will put together a posting like this with my changes. There are several dozen changes, so it will be a big posting and will take a while to put together.

Kevin
Post Reply